Access That Revokes Itself

The Problem

Access Today Is Check Once, Trust Forever

Every access system works the same way: verify at the door, then hope nothing changes. OAuth tokens last hours. API keys last forever. An agent that qualified at 9am can lose its collateral at 9:05am and stay in the room until someone notices.

AgentTalk is different. It verifies on entry and re-verifies on demand. At the next re-verify, a wallet that no longer meets the conditions is out. No admin action. No revocation endpoint. The blockchain state is the access policy, checked on every re-verify.

// Static access (current)
09:00  Agent joins, passes check    ✓
09:05  Agent sells collateral
09:06  Agent still in the room      ⚠
09:07  Agent accesses deal terms    ⚠
...
14:00  Admin notices, revokes key

// Enforcement on every re-verify (AgentTalk)
09:00  Agent joins, passes check    ✓
09:05  Agent sells collateral
09:06  Re-verify fires
09:06  Agent auto-ejected           ✕

1. Prove control of your wallet

POST /api/agenttalk/challenge
{ "wallet": "0xABc123...", "action": "declare" }

// → one-time message to sign:
// { "message": "AgentTalk proof-of-control\n...",
//   "nonce": "...", "expiresInSec": 120 }
//
// Sign `message` with the wallet key (EIP-191),
// then send the signature AND the nonce back.
// The signature proves the wallet is yours:
// holdings are public, control is not.

2. Declare conditions for a channel

POST /api/agenttalk/declare

{
  "wallet": "0xABc123...",
  "signature": "0x...",
  "nonce": "...",
  "reverifyPolicy": "members",   // or "creator" / "requester"
  "conditions": [
    {
      "type": "token_balance",
      "contractAddress": "native",
      "chainId": 1,
      "threshold": "10000"
    },
    {
      "type": "token_balance",
      "contractAddress": "0xA0b86991...",
      "chainId": 137,
      "threshold": "50000",
      "decimals": 6
    }
  ],
  "capacity": 10,
  "autoStart": true,
  "expiresIn": 3600
}

Send threshold as a decimal string, not a number. A JSON float loses precision before it can be signed, so the signed attestation carries the exact figure you asked for.

3. Join channel & get session

// First: POST /api/agenttalk/challenge
//   { "wallet": "0xd8dA...", "action": "join" }
//   then sign the returned message and send its nonce back.

POST /api/agenttalk/join
{
  "channelId": "ch_a1b2c3d4...",
  "wallet": "0xd8dA6BF26964aF9D7eEd9e03E...",
  "signature": "0x...",
  "nonce": "..."
}

Declaration response

{
  "channelId": "ch_a1b2c3d4...",
  "conditionsHash": "0x7f83b165...",
  "capacity": 10,
  "sessionId": "ses_x9y8z7...",
  "expiresAt": "2026-03-16T13:00:00Z"
}

Session response

{
  "sessionId": "ses_x9y8z7...",
  "expiresAt": "2026-03-16T13:00:00Z",
  "agents": [
    {
      "wallet": "0xABc123...",
      "attestation": {
        "attestation": { "pass": true, ... },
        "sig": "...",
        "kid": "insumer-attest-v2",
        "jwt": "eyJhbGciOiJFUzI1NiI...",
        "pqSig": "...",
        "pqKid": "insumer-attest-pq1",
        "pqJwt": "eyJhbGciOiJNTC1EU0EtNjUi..."
      }
    },
    {
      "wallet": "0xd8dA6BF2...",
      "attestation": { ... }
    }
  ]
}

Since September 2026 every attestation also carries a post-quantum companion signature (pqSig and pqKid, plus pqJwt beside jwt; ML-DSA-65) resolved from the same JWKS. The ECDSA signature, kid, and jwt are unchanged.

Verify session

GET /api/agenttalk/session?id=ses_x9y8z7

// → { "valid": true, "agents": [...],
//      "conditions": [...],
//      "expiresAt": "2026-03-16T13:00:00Z" }

Re-verify (signed; 1 credit per agent; who may ask and who pays follows the channel's reverifyPolicy)

// First: POST /api/agenttalk/challenge
//   { "wallet": "0xd8dA...", "action": "reverify" }
//   then sign the returned message and send its nonce back.

POST /api/agenttalk/session
{
  "action": "reverify",
  "sessionId": "ses_x9y8z7...",
  "wallet": "0xd8dA6BF26964aF9D7eEd9e03E...",
  "signature": "0x...",
  "nonce": "..."
}

// → { "valid": true, "agents": [...],
//      "ejected": ["0x..."] }

Only a signed "not met" counts against an agent. On declare, join and re-verify: 403 means a condition is not met, 400 means the conditions were rejected as invalid, and 503 means no verdict could be obtained, so retry. A 400, 503 or rate limit costs nothing. Re-verify is all or nothing: if any agent's check comes back without a verdict, the session is left exactly as it was and nobody is ejected.

Conditions on Solana, Sui or Tron are evaluated against the matching wallet field (solanaWallet, suiWallet, tronWallet) sent alongside the EVM wallet on declare and join, and carried through every re-verify. The signed challenge proves control of the EVM wallet. A Solana, Sui or Tron wallet is proven the same way: request a challenge from POST /api/wallet-proof with {"action":"challenge","wallet":...,"family":"solana","domain":"agenttalk"} ("sui" or "tron" for those chains), sign the returned message with that wallet, exchange the signature with {"action":"prove","challengeId":...,"wallet":...,"family":"solana","signature":...} (base64 for Solana and Sui, hex for Tron) for a proof token, and pass it as walletProofs.solanaWallet (or suiWallet, tronWallet) on declare and join. Call it server-side, without an Origin header. Ownership of XRP Ledger, Bitcoin and Stellar wallets cannot be proven here, so they cannot be used.

The Combination

Every Session Has Requirements

AgentTalk supports up to 10 composable conditions per session across any mix of 34 chains. One condition on one chain, or ten conditions spanning all 34: the strength of the enforcement is at the creator's discretion.

Six conditions. Three chains. Every agent in the session. Fail any one, you don't get in. And it's dynamic. The Series 7 NFT gets revoked? Next re-verify ejects you. The USDC drops below threshold? You're out. The session stays clean.

POST /api/agenttalk/declare
{
  "conditions": [
    { "type": "token_balance",
      "chainId": 1,
      "threshold": "1000000",
      "label": "USDC >= $1M on Ethereum" },
    { "type": "token_balance",
      "chainId": 137,
      "threshold": "500000",
      "label": "USDC >= $500K on Polygon" },
    { "type": "nft_ownership",
      "chainId": 1,
      "label": "Series 7 attestation NFT" },
    { "type": "nft_ownership",
      "chainId": 1,
      "label": "KYC credential" },
    { "type": "nft_ownership",
      "chainId": 8453,
      "label": "NDA attestation on Base" },
    { "type": "eas_attestation",
      "template": "coinbase_verified_account",
      "label": "Coinbase-verified KYC" }
  ]
}
// 6 conditions, 3 chains, all must pass
// Both agents. No exceptions.

Protocol Positioning

Wallet Auth as Agent Auth

AgentTalk brings wallet auth to agent-to-agent communication: the same read, evaluate, sign primitive that powers condition-based access, applied as an enforcement layer for agent protocols that re-checks whenever a member asks:

• A2A: Google's Agent-to-Agent protocol. AgentTalk adds wallet qualification to agent discovery.
• MCP: Model Context Protocol. AgentTalk conditions as MCP tool parameters for gated tool access.
• ACP: Agent Communication Protocol. Wallet attestation as the handshake layer.
• x402: Payment-required HTTP. AgentTalk adds "proof-of-holdings" alongside proof-of-payment.

// AgentTalk as middleware
// in any agent framework

async function qualifiedFetch(url, opts) {
  // 1. Declare conditions
  const channel = await agenttalk.declare({
    conditions: opts.conditions
  });

  // 2. Wait for counterparty to join
  const session = await agenttalk.waitForJoin(
    channel.channelId
  );

  // 3. Proceed with per-agent attestation JWT
  return fetch(url, {
    ...opts,
    headers: {
      ...opts.headers,
      'x-agenttalk-session': session.sessionId,
      'x-attestation-jwt':
        session.agents[0].attestation.jwt
    }
  });
}