> ## Documentation Index > Fetch the complete documentation index at: https://gradiences.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Capability Registry > Status: Draft spec (Phase 1) Status: **Draft spec (Phase 1)** Canonical capability ids for target profiles, artifact metadata, and compile-time rejection. Semantic meanings align with the matrix in [RFC 0002](/rfcs/0002-target-implementation-design). Legend: **Y** supported (planned or implemented), **P** partial/spike only, **N** not supported, **—** not applicable. ## Relationship to target ids * Target ids are recorded in `docs/decisions.md` and summarized by `docs/rfcs/0002-target-implementation-design.md`. * This registry owns capability ids, not target lifecycle stages. * Docs must not invent alternate ids for the same semantics. ## Relationship to Contract Intent and Target Extensions Capability ids are the lower-level protocol used after target selection, not the default user-facing SDK. Portable contracts should normally call the chain-neutral Contract Intent API. The selected target adapter resolves those intents into a capability plan, then checks this registry before lowering. Target Extension SDKs may expose target-specific operations such as Solana PDA/CPI/runtime allocator configuration, Move resources, or UTXO covenant primitives. Those extensions still route through capability ids and target metadata so diagnostics, artifact metadata, and cross-target support checks remain uniform. ## Core Capabilities > The **Solana** column reflects the canonical `solana-sbpf-asm` route (D-026): > direct sBPF assembly codegen. Solana uses `crosscall.cpi` (not > `crosscall.invoke`) and `storage.pda` — these are Solana-specific per D-027. > The **CF Workers** column is the off-chain `wasm-cloudflare-workers` host > (D-033); it reinterprets capabilities without consensus or on-chain state. | Capability id | Portable meaning | EVM | NEAR | CosmWasm | Solana | Aptos | Sui | Psy DPN | CF Workers | | ----------------------- | ----------------------------------------------------------------------------- | :-: | :--: | :------: | :----: | :---: | :-: | :-----: | :--------: | | `storage.scalar` | Single persistent scalar | Y | Y | Y | Y | Y | Y | Y | Y | | `storage.map` | Key-value or mapping storage | Y | Y | Y | P | P | P | P | Y | | `storage.array` | Fixed-size indexed storage array | P | N | N | Y | N | N | P | P | | `caller.sender` | Transaction signer/caller | Y | Y | Y | Y | Y | Y | P | Y | | `value.native` | Native token attached to call | Y | Y | Y | Y | Y | Y | P | N | | `events.emit` | Structured log/event output | Y | Y | Y | Y | Y | Y | Y | Y | | `crosscall.invoke` | Call another contract/program | Y | N | Y | N | Y | Y | P | Y | | `env.block` | Block height/time/chain id reads | Y | Y | P | P | P | P | P | P | | `control.conditional` | Statement-level conditional branches with target-supported boolean predicates | P | N | N | Y | N | N | P | Y | | `control.bounded_loop` | Static bounded loops that can be flattened or unrolled by the target | N | N | N | P | N | N | P | Y | | `data.fixed_array` | Fixed-size array value type, literals, and index expressions | P | N | N | Y | N | N | P | Y | | `data.struct` | Struct value type, literals, and field access | P | N | N | Y | N | N | P | Y | | `crypto.hash` | Host or library hashing | Y | Y | Y | Y | Y | Y | Y | Y | | `assertions.check` | Runtime or circuit assertions emitted from portable IR statements | Y | Y | N | Y | N | N | P | Y | | `account.explicit` | Named account/object/resource binding | P | Y | N | Y | Y | Y | P | P | | `storage.pda` | Program-derived address state | N | N | N | Y | N | N | N | N | | `runtime.allocator` | Target runtime heap allocator contract | N | Y | P | Y | P | P | P | N | | `runtime.memory` | Target runtime memory operations | N | N | N | Y | N | N | N | N | | `runtime.return_data` | Target runtime return-data buffer operations | N | N | N | Y | N | N | N | N | | `runtime.compute_units` | Target runtime compute-budget introspection | N | N | N | P | N | N | N | N | | `crosscall.cpi` | Solana CPI with account metas | N | N | N | Y | N | N | N | N | | `zk.circuit` | Compile entrypoints into target circuit definitions | N | N | N | N | N | N | Y | N | | `zk.proof` | Target proof generation or verification flow | N | N | N | N | N | N | P | N | ## Id Naming Rules * Format: `.` or `.` (lowercase, dot-separated). * Domains: `storage`, `caller`, `value`, `events`, `crosscall`, `env`, `control`, `data`, `crypto`, `assertions`, `account`, `runtime`, `zk`. * Artifact metadata lists the ids used by a build (see RFC 0002 artifact schema). * Diagnostics must cite capability id and target id on rejection. ## Candidate Capabilities Not Yet Registered These candidates are documented for target research only. Do not add them to `ProofForge.Target.Capability` until a target profile and lowering rules are accepted. ### Kaspa Toccata See [Kaspa Toccata target](/targets/kaspa-toccata). | Candidate id | Portable meaning | Why it is separate | | ------------------- | ------------------------------------------------------------- | -------------------------------------------------------------- | | `storage.utxo` | State lives in covenant-controlled UTXOs or state commitments | Not account/object storage and not EVM-style slots | | `covenant.lineage` | Successor outputs remain in an authorized covenant family | Needed for transaction/output validation, not ordinary storage | | `tx.v1` | Target uses Kaspa transaction v1 semantics | Transaction projection and payload rules affect correctness | | `tx.compute_budget` | Per-input script compute budget is explicit | Budgeting is part of transaction design, not just gas metering | | `lane.user` | App operations can use user lanes | Needed for based-app ordering and proof anchoring | | `zk.verify` | Script verifies an L1-supported proof | Different from compiling the target itself into a circuit | `zk.circuit` remains reserved for targets whose primary artifact is a circuit or circuit-oriented source package. Toccata may use proofs, but its base target is a Kaspa covenant package. ### Stellar Soroban See [Stellar Soroban target](/targets/stellar-soroban). Most Soroban behavior can start from the existing Wasm-host capability set, but several target semantics are not covered by the current registry. | Candidate id | Portable meaning | Why it is separate | | ------------------------ | ----------------------------------------------------------------------------------- | --------------------------------------------------------- | | `auth.require` | A contract requires an address-level authorization payload | Stronger and more structured than reading a caller/sender | | `auth.account_contract` | A contract account validates authorization through target-native account logic | Needed for Soroban account-contract flows | | `storage.ttl` | State entries have TTL extension, archival, and restoration behavior | Not captured by scalar/map storage alone | | `artifact.contract_spec` | Build output includes contract interface/spec metadata used by tooling and bindings | Artifact-level requirement, not runtime storage | | `asset.stellar` | Contract uses Stellar Asset Contract or token-interface integration | Native asset surface differs from generic `value.native` | ### Internet Computer See [Internet Computer target](/targets/internet-computer). ICP canisters overlap with the Wasm-host family, but several canister semantics need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | -------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------- | | `abi.candid` | Build emits and validates a Candid service interface | Public ABI is not only exported Wasm symbols | | `canister.method_mode` | Entry points distinguish update, query, and composite query methods | Call mode affects persistence, consensus, and call restrictions | | `storage.stable_memory` | State uses stable memory or stable structures across upgrades | Not captured by scalar/map storage alone | | `storage.orthogonal_persistence` | State follows Motoko-style orthogonal persistence semantics | Different from explicit key-value stores | | `principal.id` | Caller/canister/user identity is a Principal | Not an EVM address or generic account id | | `cycles.manage` | Target can inspect, accept, send, or account for cycles | Cycles are resource accounting, not ordinary `value.native` | | `crosscall.async` | Cross-canister calls are asynchronous message flows | Different from synchronous contract calls | | `canister.lifecycle` | Target supports install, upgrade, stop/start, and lifecycle hooks | Lifecycle is part of deployment and state safety | | `certified.data` | Target exposes certified variables or certified data responses | Needed for IC certification patterns | | `management.canister` | Target can call the virtual management canister | System lifecycle APIs are target-native | ### Algorand AVM See [Algorand AVM target](/targets/algorand-avm). Algorand overlaps with generic contract capabilities, but AVM programs, storage classes, transaction groups, and explicit resource references need separate representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | ------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------ | | `avm.application` | Target emits stateful application approval and clear-state programs | Application artifacts have two AVM programs and app lifecycle semantics | | `avm.logicsig` | Target emits a stateless LogicSig program | LogicSig is a separate stateless authorization artifact, not an app call | | `abi.arc4` | Build emits or validates ARC-4 ABI/app-spec metadata | Public method shape is tooling-visible metadata, not only exported code | | `storage.global` | Contract uses application global state | Different limits and access rules from local or box state | | `storage.local` | Contract uses account-local application state | State is keyed by account and app, not by a global contract map | | `storage.box` | Contract uses box storage with explicit box references | Box access requires resource references and budget planning | | `tx.group` | Contract depends on atomic transaction group ordering or inspection | Group semantics are target-native transaction context | | `tx.resource_refs` | App call requires explicit accounts, assets, apps, or boxes references | Resource availability affects whether AVM execution can access data | | `itxn.submit` | Application submits inner transactions | Inner effects are transaction-level, not synchronous method calls | | `asset.asa` | Contract handles Algorand Standard Assets | Native asset model differs from generic `value.native` | | `gas.avm_budget` | Lowering tracks AVM opcode budget, costs, and program limits | AVM budget constraints are not EVM gas or Wasm host fuel | | `artifact.algokit` | Build emits AlgoKit/Puya app artifacts and validation metadata | Target tooling requires app spec and bytecode package metadata | ### Cardano Plutus/Aiken See [Cardano Plutus/Aiken target](/targets/cardano-plutus-aiken). Cardano overlaps with UTXO covenant targets, but eUTXO validator roles, datum, redeemer, script context, execution units, and Plutus blueprint metadata need separate representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | --------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------- | | `storage.eutxo` | State and value live in eUTXO outputs | Not account/object storage or global contract state | | `validator.spend` | Target emits a spending validator | Spending validators have datum/redeemer/script-context semantics | | `validator.mint` | Target emits a minting policy | Minting policy semantics differ from spending validation | | `validator.withdraw` | Target emits a withdrawal validator | Withdrawal validation has a distinct Cardano role | | `datum.inline` | Contract depends on inline datum encoding | Datum placement affects transaction construction and validation | | `redeemer.input` | Entrypoint arguments are redeemers | Arguments arrive as transaction redeemers, not method calldata | | `tx.script_context` | Validator reads Cardano script context | Context is central to validation correctness | | `tx.validity_range` | Validator constrains slot/time validity | Validity ranges differ from generic block reads | | `tx.balancing` | Validation includes transaction balancing and fee handling | Off-chain transaction construction is part of practical correctness | | `asset.native_token` | Contract handles Cardano native multi-assets | Native asset model differs from generic `value.native` | | `budget.exunits` | Artifact records Plutus execution units | Execution-unit budgeting is target-specific | | `artifact.plutus_blueprint` | Build emits CIP-57 blueprint metadata | Blueprint metadata is part of the Cardano tooling surface | ### Tezos Michelson/LIGO See [Tezos Michelson/LIGO target](/targets/tezos-michelson-ligo). Tezos overlaps with generic contract storage and entrypoints, but Michelson's typed data, operation-list effects, views, events, tickets, and gas/storage-burn semantics need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | ------------------- | --------------------------------------------------- | -------------------------------------------------------------- | | `vm.michelson` | Target emits or validates Michelson code | Michelson is a typed stack VM with target-specific constraints | | `abi.entrypoint` | Build emits entrypoint/parameter schema metadata | Public entrypoint shape is target-visible metadata | | `storage.micheline` | Storage is encoded as typed Micheline data | Not EVM slots or generic JSON | | `storage.big_map` | Contract uses Tezos `big_map` storage | `big_map` persistence/indexing differs from ordinary maps | | `operation.list` | Entrypoint returns a list of Tezos operations | Effects are returned data, not direct synchronous calls | | `view.contract` | Contract exposes Tezos views | Views are a separate public read surface | | `events.tezos` | Contract emits Tezos events | Event payload and indexing semantics are target-native | | `ticket.handle` | Contract creates, transfers, or consumes tickets | Tickets are native linear assets, not generic tokens | | `privacy.sapling` | Contract uses Sapling state or transactions | Privacy state is target-native and non-generic | | `delegate.set` | Contract can change or clear delegation | Delegation is a Tezos-specific operation | | `gas.tezos` | Artifact records Tezos gas/storage-burn constraints | Fee model differs from EVM gas and Wasm fuel | | `artifact.ligo` | Build emits LIGO and compiled Michelson metadata | Target tooling requirement | ### Starknet Cairo See [Starknet Cairo target](/targets/starknet-cairo). Starknet overlaps with contract storage, events, and calls, but Cairo/Sierra/CASM artifacts, class hashes, account abstraction, syscalls, and L1/L2 messaging need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | --------------------- | ----------------------------------------------------- | ------------------------------------------------------------------- | | `vm.cairo` | Target emits Cairo source for Starknet | Cairo is the source language and execution model boundary | | `artifact.sierra` | Build emits Sierra contract class artifacts | Sierra is required intermediate contract class metadata | | `artifact.casm` | Build emits CASM artifacts | CASM is a target artifact distinct from source and ABI | | `class.declare` | Deployment flow includes class declaration | Starknet separates declaring a class from deploying an instance | | `class.hash` | Artifact records class hash and class identity | Class hash is part of deployment and upgrade semantics | | `abi.starknet` | Build emits Starknet ABI and selector metadata | ABI shape is not EVM ABI | | `storage.starknet` | Contract uses Starknet storage paths/maps/components | Storage paths and components are target-native | | `account.abstraction` | Target depends on Starknet account-contract semantics | Accounts are contract-level protocol participants | | `syscall.starknet` | Contract uses Starknet syscalls | Calls, deploys, events, storage, and messaging use syscall surfaces | | `message.l1_l2` | Contract sends or consumes L1/L2 messages | Messaging differs from ordinary contract calls | | `fee.starknet` | Artifact records Starknet fee/resource constraints | Fee/resource model is target-specific | | `test.snforge` | Validation uses Starknet Foundry or devnet | Local smoke tooling is part of target validation | ### Aleo Leo See [Aleo Leo target](/targets/aleo-leo) and [docs/superpowers/specs/2026-07-01-aleo-leo-design.md](https://github.com/DaviRain-Su/proof_forge/blob/main/docs/superpowers/specs/2026-07-01-aleo-leo-design.md). Aleo overlaps with source-generation and ZK targets, but its contract model has an explicit proof/finalization split. Private execution creates transitions and proofs; public finalization updates mappings or storage on-chain. Records, program ids, imports, Aleo Instructions, Aleo VM bytecode, ABI, prover/verifier artifacts, fees, and devnet validation need explicit representation before a target profile is added. #### Canonical capabilities (Road 1 spike) These capabilities are accepted for the first `aleo-leo` spike and are listed in Aleo artifact metadata produced by `scripts/aleo/counter-smoke.sh`. They are **not** added to `ProofForge.Target.Capability` until the target profile and proof/finalization split are reviewed. | Capability id | Portable meaning | Why it is separate | | -------------------- | ---------------------------------------------- | ------------------------------------------------ | | `lang.leo` | Target emits Leo source packages | Leo is the first stable sourcegen boundary | | `vm.aleo_avm` | Target runs on the Aleo VM | Avoids ambiguity with Algorand AVM | | `artifact.avm` | Build emits Aleo VM bytecode | Deployment artifact is target-native | | `artifact.aleo_abi` | Build emits Aleo ABI metadata | ABI shape follows Aleo program interfaces | | `execution.finalize` | Program has public on-chain finalization logic | Finalization is public and validator-executed | | `state.mapping` | Public state is held in mappings | Mappings are on-chain public key-value state | | `input.public` | Function input is public data | Public inputs are visible in transaction context | | `output.public` | Function output is public | Public outputs need explicit metadata | | `test.leo` | Validation uses Leo tests | Local validation is target tooling | #### Research candidate capabilities (future spikes) These remain candidates until private records, transitions, proofs, imports, deployment, or devnet validation are scoped. | Candidate id | Portable meaning | Why it is separate | | ---------------------- | --------------------------------------------------------- | ------------------------------------------------------------- | | `ir.aleo_instructions` | Build emits or consumes Aleo Instructions | Lower-level Aleo compiler target distinct from Leo | | `proof.prover_key` | Build or execute flow produces prover artifacts | Proof generation has target-owned artifacts | | `proof.verifier_key` | Build or deploy flow records verifier artifacts | Verification keys are part of deployment/execution metadata | | `execution.transition` | Entry execution produces a transition and proof | Transition is the Aleo function-call unit | | `state.record` | Private state is held in encrypted records | Records are UTXO-like and not EVM storage | | `state.storage` | Public state may use storage variables or storage vectors | Aleo storage differs from mappings and private records | | `input.private` | Function input is private proof-context data | Privacy is part of the function signature | | `output.private` | Function output is private by default | Output visibility is target semantics | | `program.import` | Program imports and calls another Aleo program | Cross-program calls produce composed transitions/finalization | | `program.upgrade` | Deployment may support explicit program upgrades | Upgrade rules are program/deploy metadata | | `transaction.execute` | Validation can produce an execute transaction | Execute transactions carry transitions and proofs | | `transaction.deploy` | Validation can produce or inspect a deploy transaction | Deploy publishes program code and verification metadata | | `fee.credits` | Fees are paid in Aleo Credits, publicly or privately | Fee visibility and source affect privacy and validation | | `test.aleo_devnet` | Validation uses Leo devnet or devnode-backed flows | Network-backed smoke differs from local compile/test | The existing `zk.circuit` capability is not enough for Aleo. It may describe part of the proof surface, but Aleo also needs program, transaction, state-record, finalization, and artifact capabilities. ### TON TVM See [TON TVM target](/targets/ton-tvm). TON overlaps with generic contract capabilities, but TVM cells, messages, and actions need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | ---------------- | ------------------------------------------------------------ | ------------------------------------------------- | | `storage.cell` | Contract state is encoded as TVM cells, slices, and builders | Not EVM slot storage or host KV | | `abi.tlb` | Build emits or validates TL-B/cell layout metadata | Public data shape is cell-oriented | | `message.recv` | Contract handles internal or external inbound messages | Entrypoint shape is message-driven | | `message.send` | Contract emits outbound messages through action semantics | Not synchronous cross-contract calls | | `method.get` | Contract exposes off-chain get methods | Different from state-changing message handlers | | `action.list` | Target effects are accumulated in TVM action lists | Needed for send/deploy/reserve effects | | `state.init` | Deployment requires code/data `StateInit` handling | Deployment artifact is target-native | | `account.status` | Account lifecycle/status affects behavior | Needed for uninit/active/frozen/deleted handling | | `gas.tvm` | TVM gas and fee model is explicit | Not generic EVM gas or host fee metering | | `asset.jetton` | Contract integrates TON jetton/token standards | Native token standards differ from `value.native` | ### Bitcoin Script/Miniscript See [Bitcoin Script/Miniscript target](/targets/bitcoin-script-miniscript). Bitcoin overlaps with UTXO script targets, but base-layer Script is best modeled as spending policy rather than general contract execution. Miniscript, descriptors, Taproot/Tapscript, PSBT flows, standardness, and weight/fee checks need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | --------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------- | | `script.bitcoin` | Target emits Bitcoin Script or script fragments | Bitcoin Script has distinct consensus and standardness rules | | `script.miniscript` | Target emits analyzable Miniscript policy | Safer first artifact than raw Script for spending policies | | `descriptor.output` | Target emits Bitcoin Core output descriptors | Descriptors drive wallet/address/script workflows | | `script.segwit` | Target emits SegWit v0 script paths such as P2WPKH/P2WSH | SegWit witness semantics differ from legacy script paths | | `script.taproot` | Target emits Taproot key-path or script-path outputs | Taproot changes address, commitment, and spend semantics | | `script.tapscript` | Target emits or validates Tapscript semantics | Tapscript changes opcode and signature behavior | | `witness.stack` | Artifact declares required witness stack items | Unlocking data is part of spend validation | | `sighash.mode` | Signature semantics depend on explicit sighash flags | Sighash choice affects what the signature commits to | | `hashlock.preimage` | Spending policy depends on revealing hash preimages | Common Bitcoin contract primitive | | `multisig.threshold` | Spending policy uses threshold signatures or multisig structure | Not equivalent to account-level authorization | | `psbt.flow` | Validation uses PSBT creation, signing, and finalization | Practical Bitcoin workflows are transaction-construction heavy | | `policy.standardness` | Artifact checks relay/mining standardness policy | Consensus-valid scripts may still be non-standard | | `fee.weight` | Artifact records transaction weight, vbytes, fee, and dust constraints | Fee and relay viability are part of practical correctness | | `test.bitcoin_core` | Validation uses Bitcoin Core regtest or RPC checks | Target validation depends on Bitcoin Core behavior | Bitcoin should reuse existing UTXO candidate ids where the semantics match, including `storage.utxo`, `script.p2sh`, `script.unlocker`, `timelock.locktime`, `signature.checksig`, and `tx.builder`. ### Zcash Shielded See [Zcash Shielded target](/targets/zcash-shielded). Zcash overlaps with Bitcoin-derived UTXO flows, but its shielded pools are not ordinary Bitcoin Script or a generic ZK circuit target. Sapling/Orchard notes, nullifiers, commitment tree anchors, value-balance constraints, viewing-key disclosure, and protocol-defined proofs need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | ------------------------ | -------------------------------------------------------- | -------------------------------------------------------------------------------- | | `privacy.shielded` | Target uses a shielded value pool | Privacy is a transaction construction property, not only a proof flag | | `privacy.transparent` | Target also handles transparent Zcash inputs or outputs | Transparent and shielded pools leak different information | | `pool.sapling` | Target uses Sapling shielded semantics | Sapling has distinct notes, keys, and proof semantics | | `pool.orchard` | Target uses Orchard shielded semantics | Orchard has action bundles and Halo 2 proof semantics | | `note.shielded` | State/value unit is a shielded note | Not EVM storage, account state, or plain UTXO script data | | `note.commitment` | Artifact records note commitment semantics | Needed for tree membership and output construction | | `nullifier.reveal` | Spend reveals a nullifier as the double-spend guard | Public nullifiers are core to shielded spend validity | | `anchor.commitment_tree` | Spend proves membership against a commitment tree anchor | Membership anchor is part of the public proof statement | | `zk.zcash_proof` | Transaction carries a Zcash protocol proof | The circuit is protocol-defined, not arbitrary application code | | `zk.witness` | Build requires private witness data for proving | Witness data must stay off-chain and auditable as a boundary | | `value.balance` | Artifact records shielded value-balance constraints | Conservation across shielded pools and transparent turnstiles is target-specific | | `key.viewing` | Validation/disclosure can use viewing keys | Off-chain observability is not contract state | | `address.unified` | Target handles unified addresses and receiver selection | Address semantics affect pool choice and recipient leakage | | `privacy.policy` | Artifact records allowed information leakage | zcashd exposes privacy-policy choices during transaction construction | | `test.zcashd` | Validation uses zcashd RPC or a compatible local library | Target validation depends on Zcash tooling, not Bitcoin Core alone | Zcash should reuse existing UTXO candidate ids for transparent flows where the semantics match, including `storage.utxo`, `tx.builder`, `signature.checksig`, and `fee.weight`. The existing `zk.circuit` capability is not the right first abstraction for ordinary Zcash shielded transfers; it only fits future auxiliary proof-program work outside the Zcash consensus proof system. ### Bitcoin Cash CashScript See [Bitcoin Cash CashScript target](/targets/bitcoin-cash-cashscript). BCH/CashScript overlaps with UTXO covenant targets, but its CashVM, transaction-introspection, CashTokens, and transaction-builder semantics need explicit representation before a target profile is added. | Candidate id | Portable meaning | Why it is separate | | ------------------------ | ---------------------------------------------------------------------------------- | ----------------------------------------------------------- | | `storage.utxo` | State and value live in spendable UTXOs | Not account/object storage or global contract state | | `script.p2sh` | Contract deployment/addressing uses P2SH locking scripts | Deployment/address surface is target-native | | `script.unlocker` | Contract calls are unlocking scripts for selected UTXOs | Not ordinary method dispatch | | `tx.introspection` | Contract reads current transaction inputs/outputs and active input data | Core covenant mechanism in BCH CashVM | | `covenant.introspection` | Contract constrains successor outputs through introspection | Needed for covenant-style state transitions | | `storage.local_state` | Local state is simulated through script data or CashTokens commitments | Not persistent global storage | | `asset.cashtoken` | Contract handles CashTokens category, capability, NFT commitment, and token amount | Native asset model differs from generic `value.native` | | `timelock.locktime` | Contract depends on locktime, sequence, or age checks | Separate from ordinary block reads | | `signature.checksig` | Contract verifies signatures as spend conditions | UTXO spend authorization is script-level | | `artifact.cashscript` | Build emits a CashScript artifact JSON and bytecode metadata | Target tooling requirement | | `tx.builder` | Validation includes building and evaluating a spend transaction | Practical target semantics require transaction construction | ## EVM Mapping (baseline) | Capability id | EVM lowering | | ------------------ | --------------------------------------------------------- | | `storage.scalar` | `Storage.load` / `Storage.store` (sload/sstore) | | `storage.map` | `Storage.mapLoad` / `Storage.mapStore` | | `caller.sender` | `Env.sender` | | `value.native` | `Env.value` | | `events.emit` | `log0`–`log4` | | `crosscall.invoke` | `call`, `staticcall`, `delegatecall`, `create`, `create2` | | `env.block` | `Env.blockNumber`, etc. | Implemented today via `ProofForge.Evm` / `Lean.Evm` — see [targets/evm.md](/targets/evm). ## Phase 1 Acceptance Criteria * [ ] Every id in this table appears in `TargetProfile.capabilities` for at least one target. * [ ] EVM Counter build lists `storage.scalar` (and others used) in artifact metadata. * [ ] Attempting `storage.pda` on EVM fails with `capability unsupported` diagnostic. * [ ] Registry stays in sync when RFC 0002 semantic matrix changes. ## Changelog | Date | Change | | ---------- | ----------------------------------------------------------------- | | 2026-06-30 | Initial registry; supersedes ad hoc ids in Chinese technical plan | | 2026-06-30 | Added Psy DPN research column and ZK capability ids |