# API-002: No Async/IO/Storage Dependencies

> **Authoritative requirement:** [API-002](../NORMATIVE.md#API-002)
> **Verification:** [VERIFICATION.md](../VERIFICATION.md)
> **Tracking:** [TRACKING.yaml](../TRACKING.yaml)
> **Spec reference:** [SPEC.md](../../../../resources/SPEC.md) — Section 4.2

---

## Summary

`dig-clvm` is a pure computation crate. It MUST NOT depend on any asynchronous runtime, I/O framework, serialization library for external formats, database engine, or HTTP client. This ensures the crate can be embedded in any context -- validators, CLI tools, WASM targets, test harnesses -- without dragging in heavy runtime dependencies or imposing architectural constraints on the caller.

The specific banned crates are `tokio` (async runtime), `serde_json` (JSON serialization implies external I/O formats), `rocksdb` (database), and `reqwest` (HTTP client). This list is representative, not exhaustive: the principle extends to any crate that introduces async execution, network access, filesystem access, or database connectivity. The crate's [Cargo.toml dependencies](../../../../resources/SPEC.md) (Section 4.2) enumerate the complete allowed dependency set.

This constraint is foundational to the crate's design as a consensus-grade library. Chia L1 follows the same pattern: the Rust crates (`chia_rs`, `clvmr`, `chia-consensus`) are pure computation libraries, with I/O concerns handled in the Python orchestration layer. DIG mirrors this separation: `dig-clvm` computes, the caller manages I/O.

---

## Specification

### Banned Direct Dependencies

The following crates MUST NOT appear in `[dependencies]` of `dig-clvm/Cargo.toml`:

| Crate | Category | Reason |
|---|---|---|
| `tokio` | Async runtime | Forces async architecture on callers |
| `async-std` | Async runtime | Same as tokio |
| `serde_json` | JSON serialization | Implies external I/O format handling |
| `rocksdb` | Database | Storage concern |
| `sled` | Database | Storage concern |
| `reqwest` | HTTP client | Network I/O |
| `hyper` | HTTP framework | Network I/O |
| `tonic` | gRPC framework | Network I/O |
| `sqlx` | Database | Storage concern |
| `rusqlite` | Database | Storage concern |

### Banned Transitive Dependencies

The crate MUST NOT transitively pull in `tokio`, `reqwest`, `rocksdb`, or other async/IO runtimes through its direct dependencies. This is primarily controlled by:

- Using individual `chia-sdk-*` crates instead of `chia-wallet-sdk` (see [API-003](API-003.md))
- Not enabling features that pull in network/storage dependencies

### Allowed Dependencies

The complete allowed dependency set from SPEC.md Section 4.2:

```toml
[dependencies]
clvmr = "0.14"
clvm-traits = "0.26"
clvm-utils = "0.26"
chia-protocol = "0.26"
chia-consensus = "0.26"
chia-bls = "0.26"
chia-traits = "0.26"
chia-sdk-types = "0.30"
chia-sdk-driver = { version = "0.30", features = ["action-layer"] }
chia-sdk-coinset = "0.30"
chia-puzzles = "0.20"
dig-constants = { path = "../dig-constants" }
thiserror = "2"
hex = "0.4"

[dev-dependencies]
chia-sdk-test = "0.30"
hex-literal = "0.4"
rand = "0.8"
```

Dev-dependencies (`[dev-dependencies]`) are exempt from this restriction since they do not affect the published crate.

---

## Acceptance Criteria

- [ ] `dig-clvm/Cargo.toml` does not list `tokio`, `serde_json`, `rocksdb`, or `reqwest` in `[dependencies]`
- [ ] `cargo tree -p dig-clvm` output does not include `tokio`, `reqwest`, or `rocksdb` as transitive dependencies
- [ ] No source file in `dig-clvm/src/` imports from banned crates
- [ ] The crate compiles and passes tests without any async runtime in scope
- [ ] All external state is passed into functions via parameters, never fetched internally

---

## Implementation Notes

- The `chia-sdk-driver` crate with the `action-layer` feature does not pull in async or network dependencies. If a future version adds such transitive deps, the feature set must be re-evaluated.
- `serde` itself (without `serde_json`) is acceptable as a transitive dependency since many Chia types derive `Serialize`/`Deserialize`. The ban is on `serde_json` specifically because it implies parsing external JSON input, which is an I/O concern.
- If future requirements demand JSON parsing (e.g., for test fixtures), it should be confined to `[dev-dependencies]`.

---

## Verification

### Test Plan

1. **Cargo.toml inspection**:
   - Parse `dig-clvm/Cargo.toml` and verify the `[dependencies]` section matches the allowed set above.
   - Confirm none of the banned crates appear.

2. **Dependency tree analysis**:
   ```bash
   cargo tree -p dig-clvm --depth 10 | grep -iE "tokio|reqwest|rocksdb|sled|hyper|tonic|sqlx|rusqlite|async-std"
   ```
   - This command MUST produce no output.

3. **Source code scan**:
   ```bash
   grep -rn "use tokio\|use reqwest\|use rocksdb\|use serde_json\|use hyper\|use async_std" dig-clvm/src/
   ```
   - This command MUST produce no output.

4. **Compilation without async**:
   - Verify `cargo build -p dig-clvm` succeeds without any async runtime feature flags.
   - Verify `cargo test -p dig-clvm` succeeds in a synchronous test harness.

---

## Source Citations

- [SPEC.md Section 4.2](../../../../resources/SPEC.md) — Dependencies listing and rationale
- [SPEC.md Section 1](../../../../resources/SPEC.md) — Non-goals: no networking or storage concerns

---

## References

- [API-003](API-003.md) — Individual chia-sdk-* crates (avoids transitive async deps)
- [API-004](API-004.md) — No storage access (complementary constraint)
- [API-001](API-001.md) — Re-exports define the full dependency surface
