Execution Boundary
Manifest-Declared State
A manifest tells the runtime what a cell intends to read, write, commute, and bind to external data before execution. This is the scheduling surface that allows conflict-aware execution instead of blind runtime discovery.
01 Manifest Fields
| Field | Meaning |
|---|---|
| declared_reads | Storage slots the cell may read. |
| declared_writes | Storage slots the cell may write or delete. |
| commutative_keys | Keys whose updates can be merged by operation semantics rather than serialized as ordinary writes. |
| storage_key_specs | Dynamic key ranges or calldata-derived keys used when static keys are not enough. |
| oracle_schema_ids | External data schemas a cell is allowed to request or read through Accord. |
| manifest_hash | Hash binding bytecode and manifest surfaces into one deployable contract of behavior. |
02 Static Analysis
TruthLinked scans Axiom bytecode for storage opcodes. When a storage key is loaded from a known 32-byte constant, the analyzer can extract a static read or write slot. When a storage access depends on dynamic input, the manifest must describe that dynamic key space.
bytecode
->storage op scan
static keys
->declared read/write sets
dynamic keys
->storage key specs
03 Why It Matters
- Schedulers can separate transactions that do not conflict.
- Validators can reject execution that escapes declared boundaries.
- Auditors can inspect state access without reverse-engineering every runtime path.
- Cells can bind external data requirements to explicit oracle schemas.
04 CLI Flow
axiom compile ./counter.cell axiom deploy --from ~/.truthlinked/default.keys --bytecode ./counter.axiom --manifest ./counter.manifest.json
The compile path emits bytecode and manifest output. Deploy binds the manifest to the cell creation transaction.