Demo replay of Mercury sandbox data. No live API calls. Demo signing key; in production Mercury signs with its own key. Org: “Not A Real Company Inc.” (Mercury sandbox), simulated money.

Overview

Loading…
Mercury SANDBOX

Cash, verified by the bank

Every number below is read from Mercury or computed from frozen Mercury responses, and reconciled.

Concept · a feature Mercury could ship

Outflows by month · internal & treasury transfers excluded

Owner vs customer money · 90d

Cash by account

Spend by vendor · 90d

Agent payments, under your limits

Read → draft → execute. The agent never moves money on its own.

Concept · a feature Mercury could ship
Readbalances & history
Drafta staged action you can inspect
Executeonly on your click, within limits

Ask

✦
Type a payment in plain English, or pick an example. You'll see exactly what the agent understood, which limits it checked, and the API calls it would make, before anything happens.

Accounts

Audit log

Verified company snapshot:

Shareable page ↗
…Verifying…
Signed with a demo key — in production Mercury signs with its own key. Mercury does not sign snapshots today.
SHA-256
sig · ECDSA P-256

Why this matters

A page the founder hosts can be edited by the founder. Read-only fields don't help, because they control the server. A snapshot is only trustworthy if the bank signs it. Your browser recomputes the hash and checks the signature, so no one has to trust the page.
Press t to simulate a founder edit · r to reset

Owner vs customer money · 90d

Not every inflow is revenue. Mercury verifies where cash came from; it is not the source of truth for every metric.

Agent flagged for owner confirmation

Reconciliation · tie-out

Founder-provided — not verified
This is a sandbox demo company. In a real snapshot the founder narrates here: what the cash is for, what changed this quarter, what's next. Mercury signs the numbers; it does not sign this paragraph.
Next sources: Stripe (revenue), Gusto (payroll), Carta (cap table), Delaware (entity), not connected.

Your limits

Set by the customer, enforced in code before Mercury is ever called, and re-checked at execution time.

policy.json · reloaded on every request

How a payment is routed

1ParseDeterministic rules, no LLM. Every field traced to your words.
2CheckAllowlist, ACH details on file, per-payment cap, daily cap, method, funds, 24h duplicate guard.
3You approveSingle-use approval card. Nothing runs without your click.
4Route
5Read back + logThe transaction is fetched back from Mercury and appended to a hash-chained audit log.

Allowed recipients

Anything not on this list is blocked before Mercury is called. Edit policy.json to change limits.