The way it works now
"Who approved this?"
Sign-off lives in a chat app — a screenshot, an "ok." Months later, no one recalls why the money left.
"Why did this payment go through?"
Limits and agreements live in people's heads. Someone quits, and the rule walks out with them.
"Everyone can do everything"
Permissions handed out "so nothing gets in the way." One wrong recipient address, and there's nothing to recover.
Not a ban — a rule you can always explain
A regular wallet answers one question — how to sign a transaction. The policy engine answers three others: whether it's allowed at all, who has to confirm it, and why the decision came out the way it did. Every operation runs through it, with three outcomes — allow, deny, or send for signature — and a reason for each.
Everything the engine enforces. Every transfer, checked against your rules.
Deny by default. Nothing moves until you allow it. A forgotten setting becomes a denial, not a hole.
Conditions of any complexity. A rule is a tree of and, or, except — across amount, token, recipient and sender.
Recipient whitelist. A closed list money can't leave. Not "these are allowed" but "everyone else is denied."
Check before you send. Before hitting send, the employee sees the outcome — clear, escalate or decline. No surprises.
Limits that actually limit. Per operation, per rolling window or cumulative. The daily cap counts the current transfer too.
Both sides sign. Signatures come from every rule that fires — both parties, not any two names on a list.
Thresholds hold. Set three-of-five and two people leave — it still won't pass on one signature.
The signer sees the reason. Not "two signatures needed" but "12,400 USDT exceeds the 10,000 limit." Decide knowing why.
Everyone gets exactly the access their role grants
Permissions are described once, per role — join a group and you get exactly what it grants. Visibility is its own setting: by default you see only yourself. Addresses and whole folders are shared in a single action — to a person or an entire role — and revoked just as fast.
One role, described once
Permissions live on the role, not the person. Join the group and get everything you need at once.
See everything, touch nothing
An accountant or auditor sees what's opened to them and can run no operation at all — by design.
Who sees whom is a setting
By default you see only yourself. You can share access only with someone you can already see.
Open an address like a note
The owner opens an address in one move — view, or view and operate — and revokes it just as instantly.
One folder, a dozen addresses
Share a folder whole — including addresses added later. Until you share it, it stays private.
Give access to a role, not names
Grant a folder to a role. Access follows its members — arriving and leaving as people join and go.
See who has access, and why
For any address, a list of people — and how each got in: personally, by role, or by folder.
A shared folder can't leak others
Only your own addresses go into a shared folder — and you can always pull yours back out of someone else's.
How it works in practice
One transfer, from the moment it's created to a decision that stays on record — with the engine's answer visible at every step.
Someone creates a transfer
The system shows the outcome instantly: "goes to signature — amount is over the limit."
Funds are reserved
Money is locked the moment the transfer is created, not at execution. Signers can see it's backed.
The decision stays on record
Who initiated, who signed, when, under which rule — and which version of it. A year later, the answer is the same.
Signers decide
Each one sees the amount, the recipient and why a signature is needed. One rejection is a veto — the reserve returns at once.
Built for teams that move money under rules
OTC desks & exchanges
Dozens of operations a day, distinct roles, a limit on each, a closed counterparty list.
Payment services
Incoming funds, access split across teams, payments tagged for the books.
Group treasuries
A separate circuit per legal entity, large sums signed off by several executives.
Teams with outsiders
An outsourced accountant, auditor or contractor — access to the right addresses, no operations, no full-team visibility.
Five guarantees. Each one holds by design.
Signer snapshot. A policy change can't apply retroactively — a request remembers exactly who was assigned the moment it was created.
Rule versions. Every decision points to the policy version in force at the time. Change the rule later — the history stays accurate.
Reserved per request. Funds can't be spent twice while an operation waits for signatures — the amount is held until it resolves.
Immutable journal. Postings are never edited or deleted — a correction is only ever a new reversing entry, never a rewrite.
Exact amounts. Money is counted in whole integers, not fractions — no rounding losses, however many zeros the sum carries.
FAQ. The objections we hear most — answered.
Multisig only answers "how many keys are needed." It knows nothing about the amount, the recipient, the time of day or an employee's role. A rule like "under 1,000 on your own, above that with the CFO, and this counterparty never" can't be expressed at the key level.
You don't have to. We don't store or see private keys — we connect to your wallet service. Our layer handles the rules, the approvals and the record.
A minimal working setup is two employee groups, a limit that escalates to signature, and a daily cap. That's an hour to configure and covers most scenarios; the rest is added later without rework.
That's the default case. A member with no roles sees what's been opened to them and can't run a single operation — the engine declines it for lack of a permitting rule. No separate "read-only mode" to set up.
Member visibility is its own setting, closed by default. A contractor sees only the people you've shown them, and can share access only with those same people.
The pre-send check shows the engine's decision on a specific operation without running it. A mistake is visible before it costs money.