TakusenConnect
Local protocol mode — Anvil, development executor keys, and synthetic Nitro registration are not production trust assumptions.
真takusenDocs v1.0

Build with Takusen

Payments, privacy & access

Understand the x402 payment contract, funded wallets, private results, and optional browser sessions.

1. Pay with x402

POST the final judgement body to /v1/x402/requests without a payment signature. The 402 Payment Required response supplies the exact network, asset, escrow, maximum amount, one-use challenge, and EIP-712 authorization to sign. Submit the unchanged body again with the x402 v2 payload in PAYMENT-SIGNATURE; success returns 202 Accepted and a request ID.

  1. The agent prepares the exact request body and receives a challenge tied to its body hash.
  2. The payer signs the request-scoped EIP-712 budget authorization.
  3. The agent sends an x402 v2 PaymentPayload in PAYMENT-SIGNATURE with the Takusen extension.
  4. The API verifies scheme, network, asset, pay-to, amount, challenge, signer, signature, and body hash.
  5. The challenge is consumed before credit reservation; success returns PAYMENT-RESPONSE and 202.

2. Fund prepaid credits

A payer funds one settlement domain before making requests. POST /v1/credits/deposit returns either EIP-3009 typed data or approve-and-deposit wallet transactions for that domain. Credits become spendable only after the finalized deposit is observed; they never move to another domain automatically.

3. Understand what the payer signs

The x402 challenge contains an EIP-712 AuthorizeRequest message bound to the settlement domain, request ID, exact input hash, payer, maximum budget, and expiry. That signature can authorize only the committed request and can reserve only credits already observed for the payer on that domain. EOA and ERC-1271 contract wallets are supported.

SignatureEffect
EIP-3009 TransferWithAuthorizationMoves USDC into escrow and purchases credits
EIP-712 AuthorizeRequestReserves a maximum from existing credits for one committed request
SIWECreates an application session; does not move or reserve funds

Public and private results

  1. Use visibility: public when anyone should be able to read the question, progress, answers, and evidence by request ID.
  2. Use visibility: private when reads should stay scoped to the payer's authenticated access.
  3. The payment and execution path is the same for both modes; visibility controls who can retrieve the record, not whether a verifiable record is created.
  4. A private request still produces receipts, settlement state, and evidence commitments. It does not publish the private question and answer as a public webpage.

Each login attempt receives its own ten-minute nonce row. Issuing another nonce for the same public address does not invalidate an in-progress signature, and verification atomically consumes only the exact signed nonce.