everything on-chain.

features, architecture, and how MPP Vault compares to server-side alternatives. every rule enforced by solana — no server, no middleman.

sub-accounts

one vault, many agents.

each agent gets an isolated sub-account with its own budget. create, pause, close — anytime.

Instead of creating a separate wallet for every agent and manually funding each one, you deploy a single vault. Inside, each agent gets a sub-account — a PDA derived from the vault address and an agent identifier. Sub-accounts are fully isolated: one agent can't access another's budget. The vault owner can create, pause, or close any sub-account instantly.

Isolated budgets per agentCreate/pause/close anytimePDA-derived — deterministic addressesNo manual wallet management
spending rules

max per tx. max per day.

hard limits enforced on-chain by the solana program. can't be bypassed.

Spending rules are stored as on-chain account data on each sub-account. The Solana runtime enforces them — there's no server to compromise. You can set a maximum amount per individual transaction, a rolling 24-hour spending cap, or a total budget that never resets. Rules are checked atomically before every payment.

Max per transactionMax per day (rolling 24h)Total lifetime budgetAtomic on-chain enforcement
whitelist

approved services only.

agents can only pay whitelisted addresses. everything else is rejected.

Every outgoing payment is checked against an on-chain whitelist. If the destination address isn't on the list, the transaction is rejected — no exceptions. The vault owner can add or remove addresses at any time, and each entry can have a human-readable label. Even if an agent is compromised, it physically cannot send funds to unauthorized addresses.

On-chain address verificationAdd/remove in real-timeHuman-readable labelsProtection against compromised agents
time rules

when they can spend.

set time windows — 09:00-17:00 UTC, no weekends. enforced on-chain.

Time rules use Solana's on-chain Clock sysvar as the source of truth. You define windows — for example, weekdays 09:00-17:00 UTC — and any transaction outside those windows is rejected. Multiple windows can be configured per sub-account. Since the clock is on-chain, enforcement works even if the agent's server is offline or tampered with.

UTC time windowsDay-of-week restrictionsSolana Clock sysvarWorks even if agent server is down
auto top-up

never run dry.

minimum balance triggers auto-refill from the main pool. zero downtime.

Set a minimum balance threshold on any sub-account. When the balance drops below that threshold, the vault program automatically refills it from the main pool up to a target amount. The top-up runs as a permissionless crank — anyone can invoke it, but the rules are enforced on-chain. Your agents never stop because they ran out of funds.

Minimum balance triggersAuto-refill from main poolPermissionless crankZero downtime for agents
multi-sig

team approvals.

large payments need multiple signatures. 2-of-3, 3-of-5. defined on-chain.

For high-value operations above a threshold you define, multiple signatures are required. When a multi-sig payment is initiated, a proposal account is created on-chain. Each required signer submits an approval. Once the threshold is met, anyone can finalize the transaction. Proposals expire after a configurable TTL. Signers are defined on-chain and can be updated by the vault authority.

Configurable threshold (2-of-3, 3-of-5)On-chain proposal flowExpiring proposals with TTLSigner management
fees
0%

zero platform fees. 100% of your funds go where you send them. every transaction publicly verifiable on solana.

get started →

how it works.

three steps. under a minute. deploy, configure, and let your agents transact.

01step 01

deploy vault

create a vault on solana. a program-derived address holds all funds.

You call the create_vault instruction with your wallet as authority. The program derives a PDA from your public key, allocates on-chain storage for the vault state, and transfers your initial deposit (USDC). The vault address is deterministic — you can compute it off-chain before deploying.

02step 02

set rules

configure limits, whitelist, time windows. all stored as on-chain account data.

For each sub-account, you configure spending rules, whitelist entries, time windows, auto top-up thresholds, and multi-sig settings. Each rule type is stored in its own PDA derived from the sub-account. Rules can be updated at any time by the vault authority — changes take effect immediately.

03step 03

agents pay

agents transact through the vault. rules checked, payment settled, logged on-chain.

When an agent wants to pay an MPP service, it sends a transaction to the vault program (not a direct transfer). The program checks every rule atomically: budget, whitelist, time window, per-tx limit. If all checks pass, the payment is sent from the sub-account to the service. The transaction is logged on-chain — fully auditable.

why mpp vault?

othersmpp vault
server-side rules
on-chain smart contract
trust their server
trustless & verifiable
wallet per agent
one vault, sub-accounts
server dies = no control
rules run even offline
no whitelist
on-chain whitelist
no time rules
solana clock enforcement

the problem with server-side rules

Solutions like MPP Gate run budgets on a server. The server holds the rules, the server enforces them. If the server goes down, there are no rules — agents can spend freely or not at all. Each agent needs its own wallet, funded manually. There's no whitelist, no time restrictions, no multi-sig. And you have to trust their infrastructure.

MPP Vault moves everything on-chain. Rules are stored as Solana account data and enforced by the Solana runtime. The vault program runs even if your server is offline. Sub-accounts eliminate the need for separate wallets. Whitelist, time rules, auto top-up, and multi-sig are all built in. Every transaction is publicly verifiable on the blockchain.

ready to deploy?

read the docs or launch the dashboard to create your first vault.