We match user/agent intents with their actions cryptographically
NOTE: This can also be used by humans when interacting with blockchain apps/services safely with certainty
This is a framework for agents to have unrestricted reasoning and planning while remaining bounded in on-chain authority. It makes an agent’s blockchain actions accountable and later verifiable by developers, institutions, custody providers, or third-party auditors.
This is a proposed developer tool/framework for accountable AI-agent interaction with blockchain nodes.
This framework is designed for AI agents that interact with blockchains as part of financial or operational tasks.
Developers define the authority given to an agent through a small declarative policy object. Before an agent action is executed, the transaction execution trace is checked against that policy; later, a proof can show that the agent execution followed the committed policy.
The agent is free to reason about how to achieve a task, but it cannot execute actions outside the authority defined by the developer.
Developers specify policy through a constrained JSON schema that is documented and validated by the framework.
{
"spend": {
"asset": "USDC",
"max_amount": "100000000",
"target_account": "0x.."
},
"call_rules": {
"delegatecall": "deny"
}
}POLICY TABLE / PUBLIC INPUTS
+------------------------+-------------------+
| field | value |
+------------------------+-------------------+
| allowed_asset | USDC |
| max_spend | 100000000 |
| allow_delegatecall | 0 |
| policy_hash | H(policy_json) |
+------------------------+-------------------+
Suppose an agent proposes a transaction that transfers 80 USDC and later performs a DELEGATECALL.
NORMALIZED EXECUTION TRACE TABLE
+------+------------------+--------+----------+-----------+-------------+-----------------+
| step | action_kind | asset | amount | transfer? | delegatecall?| cumulative_spend|
+------+------------------+--------+----------+-----------+-------------+-----------------+
| 0 | START | - | 0 | 0 | 0 | 0 |
| 1 | ERC20_TRANSFER | USDC | 80000000 | 1 | 0 | 80000000 |
| 2 | DELEGATECALL | - | 0 | 0 | 1 | 80000000 |
+------+------------------+--------+----------+-----------+-------------+-----------------+
The fixed AIR checks generic constraints using the policy values:
spent_next =
spent_current + is_transfer * amount
spent_final <= max_spend
(1 - allow_delegatecall) * is_delegatecall = 0
The transfer limit passes:
80000000 <= 100000000
However, the DELEGATECALL rule fails:
(1 - 0) * 1 != 0
Therefore, the execution violates the policy and no valid policy-adherence proof should be generated.
- It is not a ZK proof of an agent’s full reasoning, planning, or decision-making process.
- It is not a proof that an agent made the economically optimal decision.
- It is not a full zkEVM implementation or a proof of every EVM opcode in the initial implementation.
- It is not a privacy-first implementation in its first version.
- It does not initially prove that the GetBlock-provided trace is authenticated by Ethereum consensus.
The initial proof statement is narrower:
Given a committed policy and a normalized transaction trace supplied through the GetBlock api, the execution trace satisfies the declared policy constraints.
- A developer-defined policy object in JSON.
- Ethereum-compatible blockchain interaction.
- Direct ERC-20 transfer policies only.
- Minimum, maximum, or exact transfer amount constraints.(range checks)
- One supported token and one approved recipient.
DELEGATECALLdeny rule.- GetBlock transaction simulation or execution trace input.
- A fixed-size normalized execution trace table.
- Stwo front-end AIR framework.
The Stwo frontend contains the fixed Policy-Coherent Execution AIR and generates a STARK proof when all policy constraints are satisfied. It does not create a new AIR for every policy; instead, it applies fixed generic constraints using policy parameters such as spending limits and call permissions.
The transaction trace parser receives raw execution or simulation traces and normalizes them into fixed-width AIR witness rows. It extracts policy-relevant events such as token transfers, call types, target contracts, amounts, and forbidden operations such as DELEGATECALL.
GetBlock RPC provides the blockchain interaction and tracing layer used to obtain transaction simulation or execution traces. In the first version, it acts as the source of the raw trace data that is transformed into the execution witness.
The policy commitment object is the developer-facing JSON schema used to define the authority delegated to an agent. It is validated, canonicalized, hashed into a policy_hash, and compiled into parameters consumed by the fixed AIR.
The verifier checks that the generated proof is valid for the expected policy_hash, transaction reference, and execution trace commitment. It allows an institution or third-party auditor to verify that the agent execution remained within its approved authority.
The developer gives the agent both a task specification and an execution policy.
Task specification:
What the agent should try to achieve.
Execution policy:
What the agent is allowed to do on-chain.
The agent can reason and plan freely, but each candidate blockchain action is checked before execution. After execution, an institution or auditor can verify the resulting proof and confirm that the agent did not violate the committed policy.
The policy compiler and trace parser produce two different inputs:
Policy compiler output:
- policy parameters
- policy commitment hash
- policy rule table
Trace parser output:
- normalized transaction execution rows
- execution trace commitment
These inputs are checked by the fixed AIR:
Policy table + execution trace table
↓
Fixed Policy-Coherent Execution AIR
↓
Stwo proof generation
↓
Verifier
The long-term objective is to provide a reusable framework where developers can delegate bounded blockchain authority to AI agents and later prove that the agent remained within its declared policy.