An AI wallet your agent can use, never control.
Cantumi is being built as an AI wallet and payment control plane for Canton Network. The intended flow lets a user create a browser-held signing key, request wallet provisioning, connect a supported AI client through Remote MCP, review an exact transaction request, and authorize signing. The product is not yet publicly released, and current behavior is limited to local development.
Agents propose
Planned: a connected Claude or ChatGPT client may read an allowed balance and create a transaction request without receiving a private key or reusable signature.
You approve
Planned: the user reviews the agent, asset, amount, fee, network, recipient, and purpose before deciding.
Canton settles
Target: after authorization, the system tracks signing, broadcast, confirmation, or failure in Activity.
Planned product flow
The target journey has seven steps from account access to tracked settlement. Steps marked planned are not publicly available yet.
Access an account
The local implementation supports account creation, verification, and sign-in. Public account pages remain hidden during pre-launch.
Planned core concepts
These concepts describe the intended product boundary. Except for the LocalNet wallet prototype, they are not publicly available.
Canton wallet
The LocalNet prototype lets a verified user create a browser key and request one wallet. Production balances and Assets views are planned.
Remote MCP connection
Planned: a revocable authorization will expose only the Cantumi tools allowed for a supported client.
Transaction request
Planned: a fixed proposal will capture the agent, wallet, asset, amount, recipient, fee, network, purpose, identifier, and expiry.
Exact approval
Design goal: a decision is bound to the reviewed request, and changed data requires a new approval.
Canton settlement
Planned: an authorized request progresses through signing, submission, and ledger confirmation before completion.
Activity
Planned: a readable history will show requests, decisions, pending states, failures, confirmations, and transaction identifiers.
Planned agent connection
The planned design connects Claude and ChatGPT through a revocable Remote MCP authorization. Neither connection is publicly available yet.
A connected agent is intended to
The server is intended to prevent an agent from
Release target: connections can be revoked from Agents, and revoked, expired, or unhealthy clients are blocked from creating new requests. This behavior still requires end-to-end validation.
Claude and ChatGPT connection preview
Not publicly available. Client-specific setup will be published only after authorization, revoke, expiry, tenant isolation, and connection-health behavior have been validated.
Claude
Planned sequence: open Agents, choose Claude, authorize the Cantumi Remote MCP server, then verify its scopes and connection health before using wallet tools.
ChatGPT
Planned sequence: open Agents, choose ChatGPT, authorize the Cantumi Remote MCP server, then verify its scopes and connection health before creating a request.
Security design goals
These are intended boundaries, not a completed security certification. Each one must pass end-to-end review before public release.
Browser-held key
The LocalNet prototype generates a non-extractable key in the browser. For wallet signing, only the public key and resulting signatures are sent to the API. Private-key material remains in the browser. This boundary remains subject to release review.
Exact transaction review
The planned approval view will show the asset, amount, recipient, fee, network, purpose, and expiry before a decision.
Single-use decision
Design goal: an approval is bound to one request identifier and cannot authorize changed or replayed data.
Visible transaction state
The planned Activity view will show signing, submission, confirmation, rejection, expiry, and failure states.
Revocable connections
The intended design lets a user revoke Claude or ChatGPT access without changing the wallet itself.
Prompts stay off ledger
Design goal: prompts and model outputs remain off ledger; the final data boundary still requires release review.
Proposed Remote MCP contract
The draft tool names below communicate the intended boundary. They are not a published or stable API and may change before implementation and protocol testing are complete.
REST API · PLANNED
REST paths are intentionally not published while the contract is unstable. Documented routes will be added only after authentication, idempotency, errors, and transaction lifecycle behavior are fixed.
Current status
The public website remains a Coming Soon preview. Functional work below is either local-only or planned.
ACCOUNT · LOCAL
The account UI and API contract have been tested locally. Public account routes remain hidden.
WALLET · LOCALNET
Browser-key creation and wallet provisioning have been tested only against LocalNet.
AGENTS · PLANNED
Claude and ChatGPT Remote MCP connections are not publicly available.
APPROVALS · PLANNED
Exact review, approval, rejection, expiry, and replay protection remain under development.
ACTIVITY · PLANNED
Durable transaction lifecycle and settlement history remain under development.
ACCESSIBILITY · TARGET
Keyboard support, reduced motion, responsive layouts, and WCAG 2.2 AA are release requirements, not a current certification.
Roadmap
This sequence communicates dependencies rather than public dates. Scope and release order may change as each stage is tested.
Local account and wallet foundation
Authentication and browser-key wallet provisioning have been validated in the local development environment.
Core transaction path
Asset reads, Remote MCP authorization, transaction requests, exact approvals, settlement, reconciliation, and Activity.
Network and production readiness
Network validation, security review, accessibility QA, recovery drills, monitoring, support, backup, and rollback readiness.
Gacha, after the core product
Gacha remains deferred until the full core product flow is released and stable.
Whitepaper
Cantumi whitepaper
The full product and technical design of the Cantumi control plane, planned as a PDF alongside the core product release.
Support and FAQ
Current answers and planned behavior for accounts, wallets, agents, and transaction requests.
When is my Canton wallet created?
Signup currently creates a wallet shell. In the LocalNet prototype, the user then creates a non-extractable browser signing key and requests provisioning.
Does Cantumi hold my private key?
The current browser design uses a non-extractable local key and does not send the private key to the API. The full boundary remains subject to release review.
Which AI clients can connect?
Claude and ChatGPT are the planned initial clients. Public Remote MCP connections are not available yet.
Where do transaction requests appear?
In the planned flow, new requests will appear in Approvals so the user can review every field before approving or rejecting the exact transaction.
What happens after I reject or a request expires?
The planned flow will not authorize a transaction after rejection or expiry, and will retain the final request state for review.
Where can I check confirmation?
The planned Activity view will show signing, broadcast, confirmation, failure, and the available transaction identifier.
Need more help? Email support@cantumi.cc.