Relationship to target ids
- Target ids are recorded in
docs/decisions.mdand summarized bydocs/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 canonicalsolana-sbpf-asmroute (D-026): direct sBPF assembly codegen. Solana usescrosscall.cpi(notcrosscall.invoke) andstorage.pda— these are Solana-specific per D-027. The CF Workers column is the off-chainwasm-cloudflare-workershost (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:
<domain>.<operation>or<domain>.<variant>(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 toProofForge.Target.Capability until a target profile and lowering rules are
accepted.
Kaspa Toccata
See Kaspa Toccata target.| 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. 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. 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. 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. 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. 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. 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 and 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 firstaleo-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 |
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. 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. 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 |
storage.utxo, script.p2sh, script.unlocker,
timelock.locktime, signature.checksig, and tx.builder.
Zcash Shielded
See Zcash Shielded target. 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 |
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. 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. |
ProofForge.Evm / Lean.Evm — see
targets/evm.md.
Phase 1 Acceptance Criteria
- Every id in this table appears in
TargetProfile.capabilitiesfor at least one target. - EVM Counter build lists
storage.scalar(and others used) in artifact metadata. - Attempting
storage.pdaon EVM fails withcapability unsupporteddiagnostic. - 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 |