For treasury teams
Three jobs. One platform.
Policy evaluated at the transaction layer. Approvals that surface only what needs a human. An audit trail that answers every question, from any point in time. Mints governs autonomous agent finance by architecture — not by dashboard monitoring.
atlas-research requests a 1,500.00 USDC transfer to vendor-ops for inference compute.
Every treasury function handled by a single coherent platform — no stitched-together tools.
Balances are derived from the event log, never stored as an editable number.
Every privileged operation authorizes server-side. No SDK token is implicitly trusted.
01 — Policy
Evaluated at the transaction, not explained after.
Spending policy is configuration, not documentation. Set daily limits, per-counterparty caps, and category rules per agent or per cohort. Every transaction is checked before it proceeds — the policy does not run after settlement to produce a report.
Policy dimensions
Transaction → policy → decision
Transaction submitted
Agent signs the transfer locally and submits it to Mints. The request carries the agent's DID, amount, and counterparty.
Policy evaluated
The platform evaluates the transaction against the agent's configured spending rules: daily limit, per-counterparty cap, category restrictions.
Decision: approve or escalate
Transactions within limits proceed automatically. Those that match a review rule are routed to the configured approval queue — no further routing required.
Approval recorded
The approval decision — automatic or human — is appended as an immutable event. Who approved, when, and which rule triggered the review.
Settlement clears
The transfer proceeds to settlement: direct, via netting cycle, or via escrow release. The event stream records the final state.
Transaction submitted
Agent signs the transfer locally and submits it to Mints. The request carries the agent's DID, amount, and counterparty.
Policy evaluated
The platform evaluates the transaction against the agent's configured spending rules: daily limit, per-counterparty cap, category restrictions.
Decision: approve or escalate
Transactions within limits proceed automatically. Those that match a review rule are routed to the configured approval queue — no further routing required.
Approval recorded
The approval decision — automatic or human — is appended as an immutable event. Who approved, when, and which rule triggered the review.
Settlement clears
The transfer proceeds to settlement: direct, via netting cycle, or via escrow release. The event stream records the final state.
Decision: auto-approve or route to human
Auto-approved
Clears immediately — no human in the loop
Routed to queue
Escalated — decision surface opens for a human
02 — Approvals
The right requests reach the right humans.
You define when a human is required — by amount, by agent, by counterparty, by category. When a transaction matches a review rule, it routes to the appropriate queue immediately. The approval surface shows the agent, the counterparty, the history, and the triggering rule. Not an inbox message. Not a Slack ping.
Approval decisions are recorded as immutable events: who approved, when, and why the rule triggered escalation. Reviewers cannot modify the transaction — they approve or decline it with full context.
atlas-research requests a 1,500.00 USDC transfer to vendor-ops for inference compute.
Rule-triggered routing
Any transaction that matches your configured conditions is routed immediately — no polling, no threshold alerts to configure separately.
Full context per decision
The queue shows the agent's payment history, its lineage, and the exact rule that triggered escalation — before a human makes a decision.
Immutable approval record
Every approval or decline is an event appended to the ledger. Not a log entry in a separate system — the same audit trail everything else writes to.
Lineage-scoped visibility
Approvers see only the agents and transactions within their organization's lineage. Cross-org requests fail closed before they reach a queue.
03 — Audit
An event log that answers any question.
Mints is event-sourced. Every state change is an immutable, sequenced event. Balances are computed from the log — never stored as an editable number.
Illustrative event sequence. Each balance is computed by replaying the event log from origin.
Balances derived, never stored
There is no balance column in a mutable table. The balance you see is computed by replaying the event log from the account's origin. Hidden adjustments are structurally impossible.
Replay to any point in time
Dispute a settlement from six months ago? Replay the log to the relevant sequence number. The state at that instant is deterministically reconstructable with no separate backup or snapshot required.
Monotonic sequence numbers
Every event carries a monotonically increasing sequence number. Gaps are detectable. Reordering is structurally visible. Auditors can verify completeness without trusting the platform's assertions.
No separate reporting pipeline
Reconciliation queries the same stream your product runs on. There is no ETL job syncing to a reporting warehouse that could be hours stale when your auditor asks a question.
Reconciliation should be a query, not a project.
Netting and settlement
Thousands of obligations, a handful of transfers.
High-frequency agent commerce produces thousands of bilateral obligations every hour. Mints tracks every obligation and runs multilateral netting cycles that collapse those obligations to net positions — dramatically reducing the actual transfer count.
Settlement runs on a schedule your treasury can plan around. Not an opaque clearing event — a predictable cycle with cycle identifiers, gross and net volume, and the complete netting audit trail in the event stream.
Settlement details| Counterparties | USDC | Status |
|---|---|---|
| 7f3a…c9e29b1d…44f0 | 12.50 | 142ms |
| a04c…1e773def…90ab | 0.004 | 118ms |
| be21…77c30f5a…d2e1 | 240.00 | 156ms |
| c91f…2b407a6e…ff19 | 3.20 | 131ms |
| 1d8b…6c52e470…aa08 | 89.99 | 149ms |
Netting
A owes B, B owes C, C owes A — Mints collapses cycles to net positions. One multiparty obligation becomes a single transfer or cancels entirely.
Predictable cycles
Settlement cycles run on a fixed schedule. Treasury teams know when funds move and can plan disbursements around cycle windows.
Event-sourced proof
Every netting decision is derivable from the immutable event history. Cycle results carry gross volume, net settled, obligations count, and timestamps.
Mints Custody
Guarded funds for the assets that matter most.
Autonomous spend runs on self-custody — keys on the device, transactions signed locally. Treasury funds that need quorum protection run on guarded custody. One platform, two modes, identical audit trail.
Multi-signature wallets
Treasury operations require a quorum you define. No single key — human or agent — moves guarded funds alone. The threshold is enforced at the platform layer.
Risk scanning before signing
Outbound transactions are evaluated against risk policy before the quorum signs. If a transfer fails the scan, it does not proceed — no after-the-fact explanations.
Guardian recovery
Lost keys are replaced by a formal recovery ceremony among guardians you appointed. Every ceremony step is audited. The result is a new key set, not a support ticket.
A key ceremony with every step on the audit trail is not extra process — it is the proof of process.
Hash-chained audit trail
Every custody event appends to a tamper-evident chain. Structural tamper-evidence, not a policy assertion about data integrity.
Treasury controls at agent speed.
Mints is in early access. Tell us about your governance requirements — we'll walk through the architecture.