VAULT
Digital Asset Treasury
Unified treasury infrastructure for digital assets.
Give a finance team the controls it takes for granted off-chain: spend limits, approvals and an audit trail that actually holds.
- Policy engine
- Multisig / MPC
- Segregation of duties
- Double-entry ledger
- Break-glass
Multi-wallet treasury operations with policy controls, approval workflows and the audit trail a finance team actually needs.
What the product is built around.
VAULT puts a policy engine in front of every movement. A transaction is a proposal that must satisfy declared policy and collect the required approvals before it can be signed — and the reason it passed or failed is recorded permanently.
Policy is enforced, not documented
Spend limits, allowlists, time windows and approval thresholds are evaluated on every proposal. A transaction that violates policy cannot be signed.
Segregation of duties
Proposers, approvers and signers are distinct roles. No single identity can originate and execute a movement.
Reporting as a by-product
Because every movement is a policy-evaluated, approved proposal, month-end reporting is a query rather than a reconciliation project.
What makes this hard.
A treasury holding digital assets ends up with wallets across chains, custody split between providers, and approvals happening in a group chat. The controls a finance function takes for granted off-chain — segregation of duties, spend limits, an approval trail — have to be rebuilt from nothing.
- 01
No consolidated position across chains, custodians and wallet types
- 02
Approvals happen in chat and the audit trail is a screenshot
- 03
Spend limits and allowlists are conventions rather than enforced controls
- 04
A single compromised signer can move the entire treasury
- 05
Month-end reporting means manually reconciling dozens of addresses
What the system does.
VAULT puts a policy engine in front of every movement. A transaction is a proposal that must satisfy declared policy and collect the required approvals before a signer is offered a payload, and the reason it passed or failed is recorded permanently. Proposers, approvers and signers are distinct roles, so no single identity can originate and execute a transfer.
Spend limits, allowlists, velocity caps and time windows enforced, not documented
Role separation so a compromised key produces an unapprovable proposal
Daily reconciliation across wallets and custodians with breaks raised as exceptions
Every policy decision stored with its rule-set version and inputs
Break-glass as a first-class path with a higher threshold, not a bypass
VAULT, as working interface.
Rendered UI, not a mockup — real tables, charts, filters and states. Try ⌘K for the command palette.
Total treasury
$74.21M
Liquid (T+0)
$41.80M
Pending approvals
5
Operating runway
31 months
Approval queue
| Proposal | From wallet | Counterparty | Amount | Policy | Approvals | Proposed by | Status |
|---|---|---|---|---|---|---|---|
| prop_4K8m2Q | Ops — Hot (Base) | Payroll provider | $412,000 | Passed | 2/2 | Finance Ops | Ready to sign |
| prop_9Rt5nW | Reserve — Cold (ETH) | Market maker A | $6,200,000 | Passed | 2/3 | Treasury Lead | Awaiting |
| prop_2Wb7xL | Yield — Warm (ARB) | Unlisted address | $1,480,000 | Blocked | 0/3 | Yield Desk | Policy blocked |
| prop_6Ln3vK | Ops — Hot (Polygon) | Cloud vendor | $84,200 | Passed | 1/1 | Finance Ops | Executed |
| prop_8Cq1hZ | Reserve — Cold (BTC) | Custodian B | $240,000 | Passed | 1/3 | Treasury Lead | Awaiting |
| prop_5Yd9pM | Ops — Hot (Solana) | Grant recipient | $96,400 | Velocity | 1/2 | Grants | Review |
Proposals require policy pass and threshold approval before a signer is offered the payload
Asset allocation
- Stablecoins42.3%
- ETH & LSTs29.4%
- BTC17.0%
- Tokenized T-bills8.4%
- Other3.0%
Allocation vs target
drift bands- Stablecoins — target 40%42.3% (+2.3)
- ETH — target 30%29.4% (−0.6)
- BTC — target 20%17.0% (−3.0)
- T-bills — target 8%8.4% (+0.4)
- Other — target 2%2.9% (+0.9)
Policy decision — prop_2Wb7xL
- Rule
- counterparty.allowlist
- Result
- BLOCKED
- Reason
- Destination not allowlisted
- Amount vs limit
- $1.48M / $2.00M
- Velocity 24h
- $3.1M / $5.0M
- Time window
- Within business hours
- Override
- Requires 3-of-4 admin
- Logged
- Immutable · prop log
Treasury value
12MWallet structure
- Reserve — Cold4 wallets · 3-of-5 multisig · $38.4M51.8%
- Ops — Hot12 wallets · 2-of-3 · $6.2M · daily cap $500K8.4%
- Yield — Warm8 wallets · 2-of-4 · $18.8M25.3%
- Custodian BQualified custody · $9.4M12.7%
- Payroll — Hot2 wallets · 2-of-2 · $1.4M · scheduled only1.9%
Audit trail
- Proposal blocked by policy14:21:08
prop_2Wb7xL · counterparty.allowlist · no approvals collected
- Second approval recorded13:47:32
prop_9Rt5nW · Treasury Lead · 2 of 3 · awaiting CFO
- Transfer executed12:04:19
prop_6Ln3vK · $84,200 to allowlisted vendor · tx confirmed on Polygon
- Policy updated11:12:55
Ops hot-wallet daily cap raised $350K → $500K · approved 3-of-4
- Allocation drift alert09:30:00
BTC 3.0pp below target band · rebalance proposal drafted automatically
- Daily reconciliation08:00:04
38 wallets reconciled to ledger · 0 breaks
Counterparty concentration
Policy ceiling 35% per counterparty- Comfortable≤ 20
- Within limit≤ 35
- Breach≤ 50
- Critical≤ 100
Interface states
UI statesNo wallets connected
Add a wallet or connect a custodian to start tracking treasury positions.
Add walletEmpty stateSigner unreachable
The hardware signer for the Reserve cold wallet did not respond. The proposal remains approved and unsigned — nothing was broadcast.
How it is put together.
The policy engine is the only path to a signable payload. There is deliberately no bypass, including for administrators.
- 01
Treasury Console
Position views, proposal creation, approval UI and reporting exports.
- Next.js
- React
- TypeScript
- 02
Proposal Service
Proposal lifecycle, approval collection, role separation and comment history.
- Node.js
- State machine
- RBAC
- 03
Policy Engine
Declarative rule evaluation over limits, allowlists, velocity and time windows with a recorded decision.
- Rust
- Declarative rules
- Decision log
- 04
Ledger
Double-entry accounting for every movement with daily wallet reconciliation.
- PostgreSQL
- Double-entry
- Append-only
- 05
Signing Layer
Multisig and MPC orchestration with hardware signer support and no key custody.
- Multisig
- MPC
- HSM
- 06
Chains & Custodians
Balance and transaction sync across networks and qualified custody providers.
- EVM
- Solana
- Custodian APIs
What the product does.
The capability set the demonstration is built around.
Multi-wallet management
Hot, warm and cold wallets across chains and custodians under one account structure.
Asset allocation
Target allocation bands with drift monitoring and rebalance proposals.
Transaction approvals
Proposal, review and approval flow with role separation and full comment history.
Policy controls
Spend limits, allowlists, velocity caps and time-window restrictions per wallet.
Treasury analytics
Runway, concentration, yield contribution and counterparty exposure.
Transaction history
Immutable record of every proposal with the policy decision that allowed it.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
Policy has to be enforced without becoming an operational bottleneck
Rules are evaluated automatically and the decision is attached to the proposal. Routine movements inside limits clear without human review; only exceptions escalate.
A compromised signer should not be able to move the treasury
Signing authority is separated from proposal authority and split across independent signers. A single compromised key produces an unapprovable proposal, not a transfer.
Balances across chains and custodians never agree at one instant
The ledger is authoritative and external sources are reconciled into it daily. Breaks are raised as exceptions with the delta attributed, rather than silently netted.
Auditors need to know why a transaction was permitted
Every policy evaluation is stored with the rule set version, inputs and outcome. The answer to 'who allowed this' is a record, not an recollection.
An emergency should not require breaking the controls
Break-glass is a first-class path with a higher approval threshold, a mandatory reason and automatic notification, so urgency does not mean bypassing the system.
The stack behind it.
Policy engine
- Rust
- Declarative rule sets
- Spend limits & velocity caps
- Counterparty allowlists
- Time-window restrictions
- Versioned rule sets
- Recorded decision log
Approvals & segregation of duties
- Node.js
- Redis
- Proposal state machine
- RBAC
- M-of-N approval thresholds
- Role separation enforcement
- Break-glass with raised threshold
Signing & key custody
- Multisig
- MPC threshold signing
- HSM
- Hardware wallets
- EIP-712 typed payloads
- Pre-sign transaction simulation
- Signer timeout handling
Ledger & reconciliation
- PostgreSQL
- Double-entry ledger
- Append-only audit log
- Daily wallet reconciliation
- Break attribution
- Month-end reporting exports
Allocation & analytics
- Target allocation bands
- Drift detection
- Rebalance proposal generation
- Counterparty concentration limits
- Runway modelling
- Yield contribution attribution
Chains & custodians
- Ethereum
- Base
- Arbitrum
- Polygon
- Solana
- EVM
- Custodian APIs
Treasury console
- Next.js
- React
- TypeScript
- Tailwind CSS
- Role-aware UI states
- Immutable proposal timeline
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
Consolidated visibility and a working approval flow on one chain.
- Multi-wallet balance consolidation
- Proposal and approval workflow
- Basic spend limits and allowlists
- Transaction history
Policy automation, allocation management and reporting.
- Declarative policy engine with velocity caps
- Target allocation bands and drift alerts
- Multi-chain and custodian sync
- Month-end reporting pack
Treasury operations across entities with full governance.
- Delegated sub-treasuries with inherited policy
- Accounting system integration for journal entries
- Scheduled payment rails with pre-approved envelopes
- Scenario planning for runway under stress
Where it could go next.
Directions this system would extend into.
- 01
Accounting system integrations for automated journal entries
- 02
Scheduled and recurring payment rails with pre-approved envelopes
- 03
Scenario planning for runway under market stress
- 04
Tokenized money-market allocation with automated laddering
- 05
Delegated sub-treasuries for business units with inherited policy
Holding assets where the policy, not the person, has to decide what can move?
We built VAULT to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.