The policy decides what can move, not whoever holds a key.
A multisig raises the number of keys it takes to move money. It says nothing about what those signers are allowed to approve, who proposed it, or why it passed — and those are the controls a finance function takes for granted everywhere except on-chain.
Why a multisig is not a treasury control.
A multisig decides how many keys a movement needs. Every failure below happens with the multisig working exactly as configured, because none of them are key-count problems.
Spend limits and allowlists are conventions rather than enforced controls
A limit written in a treasury policy document is advisory, and the signer can still sign. Limits, allowlists, velocity caps and time windows belong in a declarative rule set evaluated on every proposal, with that engine as the only path to a signable payload.
Controls that stop everything get routed around
A human review step on every movement turns treasury operations into a queue, and the queue is what produces the approval in a group chat. Rules are evaluated automatically with the decision attached to the proposal, so routine movements inside limits clear without review and only exceptions escalate.
A single compromised signer can move the entire treasury
Raising the key threshold does not help if one identity can both originate and execute. Proposer, approver and signer are distinct roles with M-of-N thresholds across independent signers, so a compromised key produces an unapprovable proposal rather than a transfer.
Balances across chains and custodians never agree at one instant
Summing live reads from several sources produces a figure that is already stale when it renders. A double-entry ledger is authoritative and external sources are reconciled into it daily, with breaks raised as exceptions and the delta attributed rather than quietly netted.
The audit trail for an approval is a screenshot
Who permitted this has to be answerable from a record rather than from recollection. Every policy evaluation is stored with its rule-set version, inputs and outcome on an append-only log, so a decision from months ago can be reconstructed exactly as it was taken.
An emergency becomes the reason to bypass the controls
If moving fast means disabling policy, then policy is off during precisely the incidents it exists for. Break-glass is a first-class path with a raised approval threshold, a mandatory reason and automatic notification, which keeps the urgent movement inside the system.
How we build one.
Every layer below is arranged around one constraint: the policy engine is the only route to a signable payload, with no bypass, including for administrators. Decide that boundary late and it ends up as a setting somebody switches off during an incident.
- 01
Treasury console
Consolidated positions across hot, warm and cold wallets, proposal creation, the approval queue and reporting exports, with each role seeing only the actions it holds.
- Next.js
- Role-aware UI states
- 02
Proposal service
Proposal lifecycle as an explicit state machine, approval collection against M-of-N thresholds, comment history, and role separation enforced rather than assumed.
- State machine
- RBAC
- 03
Policy engine
Declarative evaluation of limits, allowlists, velocity and time windows against versioned rule sets, with the decision and its inputs written down whether it passed or failed.
- Rust
- Declarative rules
- Decision log
- 04
Ledger
Double-entry accounting for every movement, append-only, reconciled daily against wallets and custodians so a disagreement surfaces as a break with a cause.
- PostgreSQL
- Double-entry
- Append-only
- 05
Signing layer
Multisig and MPC orchestration with hardware signer support, typed payloads and pre-sign simulation, and a signer that fails to respond leaves the proposal approved and unbroadcast rather than half-executed.
- Multisig / MPC
- HSM
- EIP-712
- 06
Chains and custodians
Balance and transaction sync across networks and the custody providers a treasury already uses, normalised into the ledger as reconciliation inputs rather than as the figures anyone is shown.
- EVM
- Solana
- Custodian APIs
We have already built this.
VAULT is our digital-asset treasury console: a policy engine evaluating spend limits, allowlists, velocity caps and time windows on every proposal, proposers, approvers and signers held as distinct roles, multisig and MPC orchestration that custodies no keys, break-glass as a path with a raised threshold rather than a bypass, and daily reconciliation across wallets and custodians into a double-entry ledger. It is a MaatX demonstration rather than a client deployment, and the mechanisms above are running in it.
Questions we get asked.
Do you hold keys or take custody of funds?
No. The signing layer orchestrates multisig and MPC with hardware signer support and holds no keys itself — they stay with your signers, your HSM or your custodian. We build software, which is not a custody arrangement and not a regulatory position: if your model depends on holding client assets, that needs counsel before it needs engineering.
Can an administrator override the policy engine?
Not as a bypass, and that is deliberate. There is no route to a signable payload that skips evaluation, administrators included. What exists instead is break-glass: the same pipeline at a raised approval threshold with a mandatory reason and automatic notification, recorded like any other decision. An override that leaves no record is indistinguishable from a compromise.
Will this work with the custodian and multisig we already have?
That is the premise — the wallets and the custody usually already exist and the controls do not. The demonstration syncs balances and transactions across EVM chains, Solana and custodian APIs, keeps hot, warm and cold wallets under one account structure, and drives existing multisig and MPC signers rather than replacing them. Worth stating the edge: validator and staking operations are not in it, so that is scoping work rather than something we can point at.
What does an engagement look like?
Usually Mechanism and Architecture first — one to three weeks to settle the policy model, where the role boundaries fall and what the ledger treats as authoritative. Those are the three that are expensive to reverse, because changing them later means re-deriving history you have already reported on. Build follows if you want us to do it.
What it costs, and what you are agreeing to.
The commercial answers in one place, so none of them has to wait for a call.
Typical route in
Full System Build
Typically $25,000–120,000
Scoped per system
The contract is one layer. Most of what decides whether an on-chain system survives production lives in the indexing, the risk model and the reconciliation.
A starting point for the scope described, not an estimate for your project. Ongoing engineering runs at $75 per hour blended.
Who owns what you build?
You do. On full payment of the fees for an engagement, the intellectual property in everything built specifically for you is assigned to you.
Our pre-existing tools, libraries and internal infrastructure stay ours — but where a deliverable uses them, you get a perpetual, worldwide licence to run, modify and extend it. Nothing we hand over needs us to keep operating it. Open-source and third-party components keep their own licences, and we tell you which ones and what they require.
We also will not name you as a client, describe your project, or publish a case study about it without your written agreement.
What happens if it does not work out?
Either of us can end an engagement with 30 days written notice, or immediately if the other commits a material breach and does not remedy it within 15 days. You pay for work properly performed up to that point, and we hand over completed work along with every deliverable you have paid for.
Two limits worth stating before you ask. We are engineers, not advisers: nothing we deliver is legal, regulatory, tax or financial advice, and a system built to your specification is not an opinion that it is lawful in your jurisdiction. And where our work includes reviewing or auditing code, the findings cover the scope and time agreed — an absence of findings is not a guarantee that nothing is there.
What do you need from me to start?
Not a specification. Discovery exists precisely because most people do not have one — an idea, or a technical problem you cannot yet size, is enough to begin.
What the work does assume: timely access to the people, systems, credentials and environments it touches; decisions and approvals at roughly the pace the timeline assumes, since delays on your side move both dates and cost; and that you have the right to give us whatever you give us, including data, code and third-party material.
Why you rather than the alternative?
Against hiring a senior engineer in-house: sourcing one takes months and commits you permanently. Discovery runs 1–3 weeks, and you keep the architecture whichever way you then go — including if the answer is to make that hire.
Against the cheapest contractor available: you will pay less per hour. Our argument is that the architecture decision is the one that is expensive to reverse, which is why we sell it first, separately, and at a price you can say yes to before committing to a build.
Against a larger firm: there is no account layer. The people who scope the work are the people who build it.
And when not to hire us: if a no-code or off-the-shelf tool still fits what you are doing, stay on it. We are worth paying once you have hit a ceiling you cannot engineer around from where you are.
These are summaries. The binding version of the ownership, exit and liability terms is in our Terms of Service. A person reads every enquiry. We usually reply within a few hours.
Start a technical assessment
Holding assets where the policy, not the person, has to decide what can move?
Send us the architecture or the problem. We will come back with the technical risks we can see and a sensible path forward, free, and tell you if we are not the right people for it.