A standard for self-explanatory smart contracts. A single function instruction() returns a Markdown string that describes — in the contract’s own bytecode — how an AI agent should interact with the contract to accomplish a complete workflow.
interface IInstruction {
function instruction() external view returns (string memory);
}
The instruction lives on-chain, carrying the same immutability and authority as the contract logic itself. Markdown is chosen as the AI-native format that LLMs understand without any adapter layer.
Motivation
Agents can read the ABI, but the ABI doesn’t tell them how to use the contract — the roles, the multi-step workflow, the state machine, the fee rules, the timeouts. Today that knowledge is siloed in off-chain docs that can go stale, get censored, or simply disappear. instruction() makes the contract its own manual.
| Standard | Provides | Audience |
|---|---|---|
| ABI / NatSpec | Function signatures & dev docs | Developers |
| ERC-7572 | Contract identity (name, image) | Frontends |
| EIP-8174 (IntentSpec) | Per-function semantics | Agents (function-level) |
| This ERC | Complete operational workflow | Agents (contract-level) |
Production Validation
SyncTx ships instruction() across four contract types in production — sponsored repost campaigns, quote tweet campaigns, follow-reward campaigns, and European options — demonstrating that a single Markdown-returning function generalizes across very different business domains.
Open Questions
- Is contract-level workflow the right abstraction, or should the scope be narrower/broader?
- The spec defines a CommonMark subset (no HTML, no images). Right constraints?
- Any related proposals I may have missed?