CLI › Guides › Simulate, Verify, Execute

Simulate, Verify, Execute

The canonical ATF workflow. Every production transaction should follow this path: simulate against the policy engine, verify the receipt locally, then execute only when integrity is confirmed.

Prerequisites

Run directly with npx. No install needed.

All commands below use npx @trucore/atf@1.5.1.

doctor passes with no errors.
An active profile with a configured wallet and RPC endpoint.
Network set to devnet (for testing) or mainnet-beta (for production).
A valid transaction payload or preset name.

Confirm environment

npx @trucore/atf@1.5.1 doctor

Workflow Flow

Simulate → Receipt → Verify (local) → Sign → Send → Status → Archive

Each step produces output that feeds into the next. If any step fails, the workflow halts. No transaction is sent unless the verify gate passes.

Step-by-Step

1. Run doctor to confirm readiness

Verify that your environment, RPC connection, and wallet are configured correctly.

Step 1: Doctor

npx @trucore/atf@1.5.1 doctor

Profile: default
Network: devnet
RPC: https://devnet.helius-rpc.com/?api-key=****
Wallet: 5UBb...xYz3
Status: All checks passed

2. Simulate the transaction

Run a deterministic simulation against the ATF policy engine. Use --verify to enable local receipt verification.

Step 2: Simulate

npx @trucore/atf@1.5.1 simulate --preset swap_small --verify

Decision: ALLOWED
Request ID: req_abc123def456
Content hash (server):  0x7f3a...b2c1
Content hash (local):   0x7f3a...b2c1
Status: Integrity verified

3. Verify the receipt

If you did not pass --verify during simulation, you can verify the receipt separately. This recomputes the content hash locally and confirms it matches the server response.

Step 3: Verify

npx @trucore/atf@1.5.1 receipts verify --receipt last

Receipt: req_abc123def456
Decision: ALLOWED
Content hash (server):  0x7f3a...b2c1
Content hash (local):   0x7f3a...b2c1
Status: Integrity verified

4. Sign the transaction

Sign the transaction payload using the wallet from your active profile. Signing happens locally. Your private key never leaves your machine.

Step 4: Sign

npx @trucore/atf@1.5.1 tx sign --receipt last

5. Send the transaction

Submit the signed transaction to the network via your configured RPC endpoint.

Step 5: Send

npx @trucore/atf@1.5.1 tx send --receipt last

Transaction submitted.
Signature: 4kR9...mN7p
Network: devnet

6. Check transaction status

Confirm the transaction landed on-chain and reached the expected confirmation level.

Step 6: Status

npx @trucore/atf@1.5.1 tx status --sig 4kR9...mN7p

Transaction: 4kR9...mN7p
Status: confirmed
Confirmations: 31
Slot: 284,291,088
Block time: 2026-02-27T19:01:22Z

7. Archive the receipt

Store the receipt for audit purposes. Receipts are fully self-contained, contain no secrets, and can be re-verified at any time using the same deterministic hashing.

Step 7: List and confirm

npx @trucore/atf@1.5.1 receipts list

The Local Verification Gate

The verification gate is the core safety mechanism. Before sending any transaction, the CLI (or your script) recomputes the content hash from the receipt fields using the same canonical serialization the server used.

If the local hash matches the server hash and the decision is ALLOWED, the gate passes and execution proceeds. If either condition fails, execution halts.

This means you never have to trust the server alone. Verification is deterministic, reproducible, and uses no secrets.

Troubleshooting

Symptom	Likely cause	Fix
Verification hash mismatch	Receipt was modified or corrupted in transit.	Re-run simulation. If persistent, check network stability.
Decision: BLOCKED	Transaction violates active policy constraints.	Review policy limits. Check slippage, amount, and allowed programs.
RPC timeout on send	RPC endpoint is slow or unreachable.	Run `rpc ping` to diagnose. Try a different endpoint.
Transaction not confirmed	Network congestion or insufficient fees.	Wait and re-check status. On devnet, retry is usually safe.