Don't hand your agent a password.
Hand it a token.

When an AI agent acts on your behalf, its authority should be something you can see, limit, and destroy โ€” not a secret it carries. Token-Controlled Token Circulation (TCTC / ERC-7303) makes each permission an on-chain token: grant is a mint, revoke is a burn, and the chain โ€” not a permission server โ€” is the source of truth.

Why tokens, not credentials

Delegation you can audit, limit, and end

API keys and passwords were designed for software you trust completely. An autonomous agent is something new: fast, capable, and fallible โ€” with your credentials in its pocket. Handing it a secret and handing it an on-chain token fail in very different ways.

Delegating with a credential

  • Secrets copy. A leaked or prompt-injected key works for whoever holds it โ€” you can't tell the agent from the attacker.
  • Revocation is rotation. Find every place the key lives, rotate it everywhere, and hope you got them all.
  • No audit surface. Who can do what, right now? Nobody can answer without crawling config files.
  • Coarse scope. One key usually opens far more than the task at hand needs.
  • Forgotten grants live forever. Credentials don't expire unless someone remembers them.

Delegating with a token

  • Soulbound certificates can't be copied or transferred โ€” authority stays exactly where you put it.
  • Revocation is one burn. The issuer acts unilaterally; the agent's next call fails on-chain, whatever the agent believes.
  • Holdings are public. Anyone can verify who holds which role, live, on any block explorer.
  • Roles are scoped and composable. One certificate per capability; OR within a role, AND across roles.
  • Grants can end themselves. Expiring certificates report balanceOf = 0 when time runs out โ€” no transaction needed.
The whole model in three verbs

Permissions without a permission server

ERC-7303 gates a target contract's functions with a modifier that asks one question: does this address hold the required token? Everything else โ€” granting, auditing, revoking โ€” is ordinary token mechanics that every wallet, explorer, and indexer already understands.

grant = mint()

Grant

The issuer mints a control token โ€” an ERC-721 or ERC-1155 certificate โ€” to the holder. Soulbound variants stop delegation; expirable variants end it on a timer.

check = balanceOf() > 0

Check

The target contract checks the balance at call time. Multiple certificates can OR into one role; multiple roles can AND across modifiers. Composition, on-chain.

revoke = burn()

Revoke

The issuer burns the certificate โ€” no holder cooperation needed. The very next call fails. This is the kill switch that makes delegation safe.

Running today

Not a proposal โ€” it already runs

Delegating real capability to an AI agent needs an authorization you can revoke faster than the agent can act. TCTC gives an agent's wallet a role the same way it gives a human one โ€” and takes it back with one burn, or lets it expire with no transaction at all.

# principal grants the agent a role (timed)
grant_role(agent, MINTER_ROLE, expires_in: 1h) โœ…
# agent verifies its own permission on-chain
check_role(agent, MINTER_ROLE) โ†’ true ยท balanceOf = 1
# something feels wrong โ€” kill switch
revoke_role(agent, MINTER_ROLE) ๐Ÿ”ฅ burnByIssuer
check_role(agent, MINTER_ROLE) โ†’ false ยท next call reverts
  • Kill switch, on-chain. The issuer burns the certificate unilaterally; the agent's next transaction fails at the contract, regardless of what the agent believes.
  • Gasless auto-expiry. Expirable certificates report balanceOf = 0 once the clock runs out โ€” a forgotten revocation revokes itself.
  • Agent-native tooling. tctc-mcp exposes check / grant / revoke to any MCP client, with delegation rules for the agents themselves.
  • See it happen. 60-second demo: grant โ†’ agent mints โ†’ burn โ†’ agent instantly loses the capability.
The onion model

Tokens controlling tokens, all the way down

TCTC is recursive: the circulation of a token is controlled by another token, whose circulation can itself be token-controlled. The recursion bottoms out at an innermost layer where issuance is governed by a plain onlyOwner. But the root of trust is not the issuer โ€” it is the contract: a target names the certificate contracts it accepts, a wallet records the ticket contracts it trusts, and if a contract's circulation rules are sound, it doesn't matter who mints under it.

holders โ€” humans & AI agents roles on target contracts control tokens issuer onlyOwner
  1. Issuer โ€” where the recursion ends

    The innermost layer, mechanically: certificate issuance governed by onlyOwner โ€” a key or a multisig that can mint and burn. An operator of the collection, not the thing anyone is asked to trust.

  2. Control tokens โ€” the root of trust

    What verifiers actually trust: the certificate contract and its published circulation rules โ€” soulbound, issuer-burnable, expirable. Trust the contract, and it doesn't matter who issues under it. One collection can serve many targets.

  3. Roles on target contracts

    Trust is pinned to contract addresses: each target declares which certificate contracts satisfy which role (introspectable via ERC-165). OR within a role, AND across modifiers โ€” policy lives in the target.

  4. Holders โ€” humans and AI agents

    The outermost layer: whoever holds the token can act โ€” an employee, a partner, an autonomous agent โ€” until expiry or the issuer's burn says otherwise.

For humans

A general-purpose permission manager

The TCTC Dashboard makes the whole model clickable: inspect any ERC-7303 contract, watch role verdicts and balance evidence live, grant and revoke as the issuer, and deploy new certificate collections straight from a browser wallet. Not just for AI delegation โ€” any on-chain permission, managed like tokens.

TCTC Dashboard screenshot: a target contract inspected, MINTER_ROLE HAS ROLE with balance evidence, issuer grant/revoke controls

Live on Sepolia โ€” roles, evidence, and issuer controls in one page. Click to open.

For the boundary

Token-gate any MCP server โ€” without touching it

Agents get their capabilities through tools. tctc-gate is a transparent proxy that wraps an existing, unmodified MCP server and checks an ERC-7303 role on-chain before forwarding each tool call โ€” the principal adds the permission boundary, no server author's cooperation required.

agent โ”€โ”€MCPโ”€โ”€โ–ถ tctc-gate โ”€โ”€MCPโ”€โ”€โ–ถ any existing MCP server (unmodified)
before each tool call: hasRole? balanceOf? โ”€โ”€โ–ถ the chain decides
# no role โ†’ the call never reaches the server:
TCTC_ROLE_DENIED + a grant URL that opens the dashboard, one click from approval
# burn the certificate โ†’ the next call is refused; expiring certs end the delegation by themselves
Lineage

Twenty-seven years of tickets controlling tickets

Build with it

Everything is open