Ledger Transactions

TREA integration uses AtlasDB transaction payloads.

Transaction Types

PublishContractArtifact
InstantiateContract
AcceptContractVersion
UpdateContractLifecycle
ContractCall

Use these payloads in order:

1. publish artifact;
2. instantiate contract;
3. optionally accept a version;
4. move lifecycle if needed;
5. call entrypoints.

PublishContractArtifact

Publishes contract source as an immutable artifact.

Required:

• artifact_id;
• source.

Optional:

• family_id;
• version_id;
• memo.

This step stores executable source and canonical metadata. It does not create contract storage.

InstantiateContract

Creates a contract instance from an artifact.

Required:

• contract_id;
• artifact_id.

Optional:

• admin;
• memo.

This step creates contract state, lifecycle, and version-binding surface.

AcceptContractVersion

Records that the caller accepts a specific artifact version.

Required:

• contract_id;
• artifact_id.

Optional:

• role;
• memo.

This step changes artifact resolution for that actor. It does not create a new contract instance.

UpdateContractLifecycle

Moves the contract through governed lifecycle states.

Required:

• contract_id;
• lifecycle_state.

Optional:

• reason;
• memo.

This step changes whether later calls are admissible for commit.

ContractCall

Executes an entrypoint.

Required:

• contract_id;
• asset;
• entrypoint or entrypoint_selector.

Optional:

• args;
• memo.

Inline source override is rejected.

ContractCall resolves executable code from the published artifact set. It does not accept inline source.

For read-only queries from Ethereum tooling, use the Ethereum Adapter (POST /api/eth/call/:contract_id) instead — it accepts raw Ethereum calldata and does not require a signed transaction. See Ethereum Adapter.

Commit Sequence

For a call transaction, AtlasDB evaluates the flow in this order:

1. resolve the contract instance;
2. resolve the caller's accepted artifact or default artifact;
3. validate lifecycle and artifact-family consistency;
4. execute the contract locally;
5. validate resulting ledger effects;
6. persist storage and settlement metadata if commit succeeds.

Important Boundary

A valid payload is not enough for success.

The runtime can execute successfully and still produce a result that the ledger rejects during final commit.