Denze documentation

Denze is a self custodial spending account for AI agents. You fund an onchain account you alone control, write a policy, and hand your agent a token. The agent can spend inside the policy and cannot spend outside it, because the rules are enforced onchain by the account itself, not by a company promise.

What Denze is

Five things to hold in your head. Everything else follows from them.

• Account. An onchain smart account that you own. Deployment is gas sponsored, so it never needs ETH. Funding is a plain USDC transfer to its address. Only your owner key can withdraw.
• Agent. A named identity with its own session key, held server side and never given to the agent. The agent holds only a bearer token. Pause an agent and its token stops working. The kill switch revokes every agent at once, onchain.
• Policy. The rules one agent spends under: caps, budgets, a merchant allowlist, paid link allowlist, approval thresholds and more. Hard rules compile to onchain validation. Changing a policy requires your signature.
• Cosigner. A separate service that checks the soft rules before every spend and co signs only when they pass. It fails closed: if it is unreachable, spends decline. It can never move money on its own.
• Receipts. Every decision, settled or declined, becomes a receipt with the reason attached. Settled spends carry the transaction hash. Any receipt can be published as a public page.

Quickstart

1. Sign in at app.denze.xyz. Email or wallet, via Privy. Programmatic signup with an EOA works too, over SIWE.
2. Create your spending account from the Profile page. One click, no gas needed.
3. Fund it: send USDC to the deposit address shown in the app, on the network the app displays next to it. The network matters: a transfer on any other network cannot be recovered.
4. Create an agent on the Agents page. Its MCP token is shown once, at creation. Treat it like a password.
5. Set the agent's policy on the Policy page and sign. The rules are live onchain from that moment.

Then connect the agent to whatever runs it:

$ claude mcp add --transport http denze https://mcp.denze.xyz/agt/YOUR_HANDLE \
    --header "Authorization: Bearer YOUR_AGENT_TOKEN"

Connect an agent

The agent surface is a streamable HTTP MCP server at https://mcp.denze.xyz/agt/:handle, scoped to one agent by its bearer token. Anything that speaks MCP can hold an allowance.

• Claude Code: the one command above. The webapp's Settings page prints it pre filled.
• Cursor and VS Code: add an HTTP MCP server in the editor's MCP config with the same URL and an Authorization: Bearer ... header.
• ChatGPT, claude.ai and other hosted platforms: add https://mcp.denze.xyz/agt/YOUR_HANDLE as a custom connector. The platform discovers Denze's OAuth server automatically and sends you to a consent screen where you pick which agent it becomes. No token pasting. See OAuth for platforms.
• Your own code: use @denze/sdk or plain JSON RPC POSTs. See SDK.

MCP tools

Six tools. Amounts are decimal strings in the allowance token, USDC.

Settled spends also return the remaining budget, so an agent can plan its next spend without a second round trip.

Policy reference

A policy has hard rules and soft rules. Hard rules compile to a policy hash anchored onchain and are validated by the account itself: a compromised agent, a rogue prompt, even a compromised Denze cannot exceed them. Soft rules are checked by the cosigner before it co signs, and it fails closed.

Hard rules

Soft rules

Paying the open web: x402

x402 is the open standard for machine payable HTTP: a server answers 402 with payment requirements, the client pays in USDC, retries with proof, and gets the content. Denze implements the standard exact scheme, so any compliant merchant works with no integration on either side. That includes AI inference by the call, web search, data APIs and travel.

How a Denze x402 payment actually moves:

1. The agent calls pay_x402 with the URL. Denze reads the 402 challenge and checks the price against the agent's maxAmount and policy.
2. The account funds a relay address through the normal policy path. Caps, cosigner, approvals and receipts all apply, and the endpoint URL hash is bound into the onchain receipt.
3. The relay signs a standard EIP 3009 authorization. The merchant's facilitator settles it and serves the content.
4. If the merchant refuses without settling, the funds are automatically returned to the account. A refused call costs nothing.

With the allowlist on, add the endpoint URL to the policy's paid links. URLs are matched exactly, so give the agent the precise URL to call, with parameters in the request body rather than the query string where the API allows it.

Ask me first

Set a threshold in the policy and any spend at or above it pauses instead of settling. You get a notification and the request appears in the webapp's Approvals inbox. Approving grants a single use pass bound to that exact amount, merchant and reason. The agent redeems it by retrying the same spend. Declining blocks retries of that spend for the grant's lifetime, so an agent cannot nag you into a yes. Requests expire on their own if you do nothing.

Standing orders

A standing order pays the same merchant a fixed amount weekly or monthly. Create one from the Recurring page or the API. Every run is a normal spend: policy caps, the allowlist and ask me first all still apply, and each run gets a receipt linked to the order. Pause, resume or cancel at any time. Resuming does not back pay missed periods.

Receipts

Every decision is recorded: settled spends with their transaction hash, declines with the exact rule that fired. From the Receipts page you can export CSV, dispute a spend, block a merchant in one tap, or publish a receipt to a public page you can hand to anyone, no sign in required. Published receipts never expose your account address or agent identity.

CLI

$ npx denze login --token <session token>
$ denze account            # balance and deposit address
$ denze agents create bot  # prints the MCP token once
$ denze policy <agentId>
$ denze allowance <agentId>
$ denze receipts --limit 20
$ denze mcp                # prints your MCP install command
$ denze catalog exa        # search the merchant catalog
$ denze killswitch         # freeze every agent, owner signed

SDK

@denze/sdk ships two clients. DenzeClient wraps the user API with your session token: accounts, agents, policies, receipts, approvals. DenzeAgent speaks the agent MCP surface with an agent token, as plain JSON RPC over HTTP, one POST per tool call, no MCP framework required. It also exports an x402 aware fetch for paying paywalled endpoints directly from your own code.

REST API

API origin https://mcp.denze.xyz. User endpoints authenticate with a session bearer from Privy sign in, SIWE or passkey. Operations that change onchain state follow a prepare, sign, submit shape: the API prepares an operation, you sign its hash with your owner key, and submit it back. Denze never holds your owner key.

OAuth for platforms

Hosted platforms that cannot attach a static header connect over the MCP authorization flow. Denze serves the full surface on the MCP origin:

• /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server for discovery. A 401 from the MCP endpoint names the resource metadata in its WWW-Authenticate header.
• /oauth/register: dynamic client registration. Clients are public, PKCE with S256 is required, redirects must be https or loopback.
• /oauth/authorize sends the owner to a consent screen in the webapp, where they choose which agent the platform becomes. A connection is an agent binding: the platform gets that agent's allowance and policy, nothing more, and the same pause and kill switch cut it off.
• /oauth/token: authorization code and rotating refresh grants. Access tokens work on the MCP endpoint exactly like static agent tokens.

Security model

• Self custody. Funds live in your smart account. Denze holds no deposits and cannot withdraw. Owner operations require your signature every time.
• Agents never hold keys. An agent token is a scoped credential for one agent. Session keys stay server side, encrypted, and are revocable onchain.
• Hard rules are chain enforced. The session key module validates every spend against the caps, expiry and allowlist. Nothing on our side can override a decline.
• The cosigner fails closed. Soft rules are checked by a separate service that co signs approvals only. If it is down, spending stops rather than loosening.
• The kill switch is two taps. It revokes every agent token immediately and revokes the onchain session key epoch with your signature. Nothing can spend afterwards.
• Honest caveat. The contracts have not yet had an external audit. Size your deposits accordingly.

Questions, or a merchant you want in the catalog? Say hello: denze.xyz.