1
Intent Creation
The agent declares what it wants to do (swap, lend, withdraw). This is a structured intent object, not a raw transaction.
← Back to ATFTechnical Deep Dive
How ATF Works
A step-by-step breakdown of the execution lifecycle, policy engine internals, enforcement model, and threat mitigations that make ATF a deterministic trust boundary for autonomous agents.
Execution Lifecycle
Every agent transaction follows six deterministic steps from intent to verifiable receipt. No step can be skipped or reordered.
- 2
Policy Evaluation
The Policy Engine evaluates the intent against all active rules: allowlists, rate limits, spend caps, and time-of-day constraints.
- 3
Permit Issuance
If the policy evaluation passes, a scoped, TTL-bound permit is issued with a single-use nonce and minimum required capabilities.
- 4
Transaction Construction
The transaction is built within the boundaries of the permit. Parameters that violate permit constraints are rejected before signing.
- 5
Execution Validation
Pre-flight simulation verifies slippage bounds, protocol allowlists, and output constraints. The transaction is fail-closed if any check fails.
- 6
Receipt Anchoring
A cryptographic receipt captures the policy evaluation, permit details, execution outcome, and settlement data for tamper-evident audit.
Policy Engine Internals
The policy engine is the first enforcement boundary. It evaluates every intent against a deterministic rule set with zero probabilistic logic.
Deterministic rule evaluation
Every policy rule produces the same output for the same input. No probabilistic logic, no model inference in the critical path.
Capability-scoped permits
Permits grant the minimum set of capabilities required for a single operation. Scope cannot be widened after issuance.
TTL and nonce enforcement
Every permit carries a time-to-live and a single-use nonce. Expired or replayed permits are rejected automatically.
Domain separation
Permits are scoped to a specific domain (TruCore ATF + environment). Cross-domain reuse is structurally invalid.
Replay protection
Nonce tracking combined with domain separation ensures no permit can be submitted more than once, across any context.
Enforcement Model
ATF enforces a strict security posture. Every default is deny. Every exception is explicit. Every override is impossible at the agent layer.
Fail-closed default
If a policy rule cannot be evaluated, or if any check is ambiguous, the transaction is blocked. Silence is a denial.
Explicit allowlists
Only pre-approved program IDs, token mints, and protocol endpoints are reachable. Everything else is rejected by default.
Hard invariants vs soft guidance
Hard invariants (spend caps, TTLs, protocol allowlists) cannot be overridden. Soft guidance (warnings, telemetry) is informational only.
No agent-side self-approval
Agents cannot issue, extend, or modify their own permits. Approval authority is external to the agent runtime.
Threat Mitigation Matrix
Each threat vector maps to a specific enforcement layer within the ATF pipeline.
| Threat | Mitigation Layer |
|---|---|
| Unbounded execution | Permit TTL + scoped capabilities |
| Slippage exploitation | Execution validator with hard slippage bounds |
| Protocol drift | Allowlist registry restricting reachable programs |
| Replay attack | Nonce + domain separation on every permit |
| Audit opacity | Tamper-evident cryptographic receipts |
For teams already building
Design Partner Program
Working with a limited cohort of early teams integrating ATF into production trading bots on Solana. This is not a waitlist - it is hands-on integration support.
Includes:
- • Dedicated partner API key tier
- • Integration guidance and policy design review
- • Direct access to engineering