The server holds no key
Each wallet is created with an empty set of authorization keys, so there is nothing for us to sign with — not for support, not under subpoena, not if this process is compromised.
For exchanges · OTC desks · payment agents
Your treasury.
Your treasury.
Nobody else’s signature.
A non-custodial USDC wallet for a company, with the controls a finance team actually needs: roles, spend limits, an allowlist of who can be paid, and approval thresholds above which one person is not enough. Payments are signed on the payer’s own device — we cannot sign for you, and the server holds no key that could.
Wallets are created with no server authorization key. That is not a setting; it is how they are made.
Non-custodial
Only your people can move your money.
Not the strongest claim we could make. It is the one that is true.
Policy decides before anyone signs
Limits, allowlist and thresholds are checked first. Nobody is ever asked to approve a payment on their device that policy would refuse anyway.
The ledger is append-only
Movements are written once and never edited, protected twice over: by a database trigger and by permissions the application does not hold.
Controls
Four things that stop a bad payment.
Each one refuses on its own. Getting past all four takes more than one compromised laptop.
Roles
WhoFive of them. An operator may spend but never approve; an approver may clear a payment but not raise one; a viewer reads and exports, and reaches nothing that moves money.
Limits
How muchPer transaction, per day, per week — for the organisation and for each member. Money already promised to a pending payment counts against them, so two parallel sends cannot both be allowed.
Allowlist
To whomAdd one address and every other recipient is refused from that moment. Off until you use it, absolute once you do.
Approvals
Who elseAbove the amount you set, a payment waits for sign-off. The person who raised it cannot be one of the approvers, and nobody signs anything until the queue clears.
How it works
Three steps.
STEP 01
Create the organisation
Your treasury wallet is created with it, on Base, in USDC. The key that controls it is generated on your device and never leaves it.
STEP 02
Invite the people, set the rules
Roles, limits, allowlist, approval thresholds. An invitation grants nothing until the person accepts it themselves.
STEP 03
Pay, and export the ledger
Every movement is recorded with three dates — posted, value, settled — and comes out as CSV your accountant can import.
What is live, and what is not
We would rather lose the
We would rather lose the
signup than the trust.
Below is what the product does today. Everything else we are working on is in the second column, described as unbuilt, because finding a gap after you have moved money is a worse discovery than finding it here.
One thing worth saying plainly: today a payment above your threshold waits for approvals and is then signed by one device. That is an approval policy, and we do not call it anything stronger. Signing that needs several keys at once is being built.
Live today
Being built
USDC on Basesend & receive
Roles & team invitesfive roles
Spend limitsorg & per member
Recipient allowlistabsolute once used
Approval thresholdswith sign-off
Ledger exportCSV, three dates
M-of-N signingnot yet
Fiat in and outnot yet
Mass payoutsnot yet
USDT on Tronnot yet
Incoming on-chain deposits are not yet journalled, so the export covers outgoing and internal movements. It says so on every file.
Design partners
We would rather build it
We would rather build it
with you than at you.
If you run an exchange, an OTC desk or a payment agency, tell us how you sign a $200k transfer today and what hurts most about it. If we are not a fit, we will say so on the call rather than follow up for a quarter.