Smart Wallet
A Smart Wallet lets a tenant require several signers to agree before an instruction moves assets, with the rule enforced on chain, not by one private key.
Weights sit with the signers. The rule sits inside the account.
A weighted Smart Wallet needs several signers to agree before it acts. Each signer holds a weight, and their combined weight must clear the account's own threshold whenever the weighted validator is the account's only authorization path.
The weighted validator checks that threshold on chain, inside the account itself, not in a process beside it. Review every installed validator, since another one can authorize a different signing path. Fees stay separate from authority: a sponsor, the platform while it sponsors, can pay the network fee for an instruction the account has already approved, so no signer has to hold funds for fees.
Reconfiguring the account is itself an instruction. With only the weighted validator installed, changing the signer set or the threshold has to clear the current threshold first, the same as any other call.
Why an account needs a rule of its own
A Smart Wallet stops one signer from being able to move an account's assets alone. A tenant sets how many signers must agree and how much each one's approval counts for, and the account itself checks that agreement before anything executes. The mandate, who may act and how much of them it takes, is the same object that moves the assets, not a policy sitting next to it.
An ordinary account on a chain is a private key: whoever holds it can move everything the account holds, at any hour, with no second party in the room. Institutions answer that risk with a maker who proposes and a checker who authorizes, the split maker-checkerMaker-checker keeps a single mistaken instruction or a single compromised account from moving money, filing a report, or approving a corporate action alone.Read the concept names directly, but that discipline usually lives in the process around the key rather than in the account itself. A Smart Wallet moves the requirement inside the account: signers hold weights, and an instruction executes only when the weight behind it reaches the threshold.
Two consequences follow. The control does not rest on the platform's good behavior, because the account contract holds the signer set and does the arithmetic itself. And the control cannot be widened without notice: adding a signer or lowering the threshold is an instruction that must clear the current threshold first.
The account also separates the fee from the authority. A sponsor, the platform while it sponsors, can pay the network fee for an instruction the account has already authorized, which removes the standing job of keeping every signer's key funded with the chain's native token. The sponsor gains no say over what executes.
Every operation across an asset's Asset Lifecycle, from issuance through servicing to redemption, reaches the chain as a transaction some account sent. A Smart Wallet is one way that account decides what counts as authorized, underneath every stage rather than inside any single one of them.
This is what changes when the account is a contract rather than a key.
| What differs | A key account | A Smart Wallet |
|---|---|---|
| Who moves the assets | Whoever holds the key | Any set of signers whose weights reach the threshold |
| Where the rule is enforced | In the process around the key | In the account, on chain, before it executes |
| How the rule changes | By changing the process | By an instruction that clears the current threshold |
| Who pays the network fee | The key, from its own native balance | The account, or a sponsor that authorized that instruction |
| Who the chain records as the actor | The key | The account |
Why this rule lives in the account, not beside it
The alternative to a rule the account enforces is a rule enforced by whatever produces the account's signature. A managed custody providerA Custody Provider decides who signs for an organization's accounts, a managed custodian or the holder's own wallet, without changing accounts or approvals.Read the concept or an internal approval process can require the same number of sign-offs before it releases a signature. That check runs off chain, in a system separate from the account, so the account has no way to confirm that every signature it later accepts passed through it. Whoever still holds a key the account will accept can produce a valid signature outside that process entirely.
A Smart Wallet closes that gap by moving the check onto the account itself. The threshold lives on the validator module the account installs, so the account counts the signing weight behind every instruction itself, before it executes anything, whichever key or provider produced each signature. Compliance rules, role grants, and the audit trail already name the account's address, and the threshold check runs at that same address, so there is no second system for those records to reconcile against.
Running a Smart Wallet day to day
A Smart Wallet is the account whose signer set and threshold someone has to maintain once it is live, and that gives an operations team three recurring jobs. You set the signer set and the threshold when the account is created. You keep that set current as people arrive and leave. And you keep the gas reserves funded, or instructions never reach the chain at all.
You create the account with its signers, a weight for each, and the threshold, either directly or by staffing it through MultisigMultisig lets a tenant put a wallet under several signers, weighted so authority follows who must actually agree, before any of them can act alone.Read the concept's draft, invite, and finalize flow. A configuration that could never execute anything is refused at creation: a repeated signer address, or a threshold above the sum of the weights.
Sizing that threshold is the one setting with no universally right value, since it trades control against convenience. A higher threshold needs more signers to agree before anything moves, including a change to the signer set itself, so it limits what one compromised signer can do, while requiring more signing weight to remain available. A lower threshold keeps things moving with fewer people, at the cost of concentrating effective control in whichever few signers reliably show up. Weight the signers whose sign-off should never be optional heavily enough that nothing passes without them. Check which signer losses would prevent reaching the threshold. Making one signer mandatory also makes that signer's availability necessary for recovery.
Changing the set afterwards follows one rule: a change is an instruction like any other, so the account approves it at the threshold in force. Removing a signer therefore needs the remaining signers to agree, and a removal that would leave their weights short of the threshold is refused when you request it rather than left for someone to discover when the next instruction stalls.
An instruction that arrives without enough weight does not fail. The account would refuse it outright, so the platform never submits one: it waits instead as a pending approval that the other signers see and co-sign, under an optional expiry set when the approval is created. Custody ApprovalCustody Approval lets you require a decision from your own approvers before a key signs, enforced by the party holding the key, not the platform.Read the concept, the pending-decision record that tracks each instruction until co-signers resolve it, covers that queue, where an approval ends approved, declined, expired, or cancelled.
Two gas reserves, held on the organization's own bundler walletAn operator wallet lets your users transact without holding native gas: the platform pays the network fee, and you fund and monitor the wallet that covers it.Read the concept, keep advanced accounts, the console's name for this execution route, working at all, and they fail differently. The submission reserve pays to get any instruction on the chain and is always required: when it empties, instructions stall for every participant. Watch it with the bundler balance read, which reports that reserve's live native balance so a gas manager can fund it before it stalls anything. The sponsorship reserve pays gas on behalf of participants and matters only while the platform sponsors: when it empties, sponsored instructions fail and each account falls back to its own native balance. Runway is the signal for the second one: the console adds the paymaster, bundler, and splitter balances together and divides by the average daily gas cost across every operation the bundler processed in the last seven days.
An instruction clears the account's own weight check first, then the fee question decides who pays, and can still block execution if no payer is available.
How it works and where the boundaries sit
A Smart Wallet is a contract account under ERC-4337, the account-abstraction standard. Instructions reach it as signed intents, UserOperation objects that hold a signature, rather than raw transactions. A shared entry-point contract validates each intent and then calls the account to execute it, and a relayer, the off-chain service that batches many participants' intents into one on-chain submission, submits those batches to that entry point.
The account is modular, following ERC-7579, the modular-account standard. Validation is not compiled into the account: it is a module the account installs. A single-signer account installs a plain signature validator. A weighted account installs a validator that stores each signer's weight and the threshold and compares the collected weight against it. An account can hold up to sixteen validators at once, and cannot be left with none.
Each account is a light proxy over one shared implementation, sharing its code and none of its state. A fix ships once and every account inherits it, and no individual account can upgrade itself.
The reconfiguration boundary is the one to check first. The weighted validator answers "may this actor manage this account directly" with no, always, for every actor. Adding a signer, removing one, or moving the threshold therefore has to arrive as an instruction the account validates like any other, which means through the threshold. That restriction holds only when another installed validator does not authorize direct management.
One boundary sits outside the account. Whether a participant's writes leave from their own key or from their Smart Wallet is an organization-level setting, not a per-request choice. Flipping it changes which address the chain sees as the actor, so on-chain state written for a participant, such as identity registrations and role grants, follows the address that wrote it. A participant created as key-only, or as account-only, keeps its own route either way; the setting governs the rest.
The integration contract
On the API, a Smart Wallet is one object with its address, its installed validators, its signers and their weights, and its threshold. You create the account once, read it from the indexed record, and change its signer set and threshold through separate queued writes.
Creation takes an optional multisig object, and whether you supply one is a decision rather than a default to accept unread. Omit it and the account is created with the default single-signer validator, which authorizes its recorded owner to manage the account directly from a raw transaction, the same single-key exposure a Smart Wallet otherwise removes. Omitting it only makes sense where that owner's own key already sits behind controls you trust, such as a hardware module or a custody provider's policy. Include it and you supply the signers, a weight for each, and the threshold, which keeps every reconfiguration behind the threshold instead of one key. The request is rejected before anything is queued when a signer address repeats, when a signer is the zero address, which could never produce a valid signature, or when the weights cannot reach the threshold. A weight is a positive integer that fits in an unsigned 64-bit value and defaults to 1.
Creation is a queued write, not a synchronous one. The response tells you the platform durably took the request, not that the account exists. Check the original request before sending another create call; the key alone does not make the whole route replay-safe. Read the outcome as a Settlement VerdictA Settlement Verdict lets you report success only when an operation actually happened, not from acceptance alone, across four recorded end states.Read the concept, the final recorded outcome of the queued write: completed, failed, dead letter, or cancelled.
Reads split into two kinds, and the difference decides what you may conclude. The account, its signers and its approvals come from the indexed record and never touch the chain, so a change you queued a moment ago is absent there until it is indexed. The gas-status read is live: it reports the account's native balance, whether a sponsor is available for the next instruction, and whether the chain charges gas at all.
One limit shapes how you plan a signer set: only account creation lets you set a signer's weight above the default of 1. No route raises an existing signer's weight afterward, and a signer removed and then re-added returns at weight 1. Set every non-default weight at creation, and check the API reference for the exact mutation routes.
Controls and evidence
A Smart Wallet is a preventive control at the point of execution. The account validates the collected signer weight before it does anything, so an instruction below the threshold is refused rather than executed and reported afterwards. The enforcement point is the account contract itself, on chain.
That is what makes the control defensible under questioning. The signer set, the weights and the threshold are on-chain state, and the check runs where the assets are rather than in the application that displays them. The control also cannot be widened from outside, provided the weighted validator is the only validator installed. The account grants direct access to any actor that any one of its installed validators authorizes, so a single-signer validator left in place beside the weighted one would hand its own recorded owner that same direct path. With only the weighted validator installed, it refuses direct management outright, so a change to the signer set, to the threshold, or to which validators are installed, has to clear the threshold in force first. The same fence covers identity claims made on the account, which must arrive through the account rather than from one signer acting alone.
Attribution is the second control the account provides. The party on chain is the account, not whichever signer's key produced a signature, so transfer restrictions, role checks and the audit trail all name one address you already govern.
Evidence has two halves and both are producible on request. On chain: the signer set, the weights, the threshold, and each amendment to them, with the transaction that made it. On the platform: each pending approval with the weight it required, the weight it collected, and every collected signature with its signer, its weight and its time.
One boundary to state plainly: a Smart Wallet is not transfer compliance. The threshold check runs first, during validation. The asset's own rules run later, inside the transfer, and the asset contract enforces them, so a fully approved instruction can still be rejected there. Transfer-Path ComplianceTransfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.Read the concept is that separate control.
Frequently asked questions
How is this different from a multi-signature vault?
No separate vault contract holds assets on behalf of an account. The account itself is the multi-signature arrangement: assets sit in it directly, and the threshold applies to everything it does, not only to withdrawals from a special-purpose contract. That also means there is no second address to reconcile and no bridge step between the account you configure and the account that holds the assets. See MultisigMultisig lets a tenant put a wallet under several signers, weighted so authority follows who must actually agree, before any of them can act alone.Read the concept for how a weighted account like this one actually gets staffed, through a draft, invites, and one finalize step.
What happens if a signer loses their key?
The remaining signers remove that signer and add a replacement, which is an instruction like any other, so it needs their combined weight to reach the threshold. Check that arithmetic when you set the account up. If the lost signer's weight was necessary to reach the threshold, the remaining signers cannot pass any instruction at all, including the one that would repair the signer set. No administrator can override that: the fence that stops an attacker is the same fence that would have to lift for a rescue.
Can the fee sponsor change or block what I do?
The sponsor cannot change it. A sponsorship authorization names the account and a hash of the exact call it covers, together with a deadline and a fee ceiling. Changing one argument puts the instruction outside the authorization, and a fee above the ceiling falls outside it too. A sponsor can decline to cover an instruction, and an unfunded sponsorship reserve has the same effect: the account then pays the fee from its own balance, or the instruction fails if it holds none, rather than waiting for funds.
What is an advanced account, and can it be turned off?
Advanced accounts is the console's name for routing an organization's on-chain work through Smart Wallets and the sponsored-fee path instead of through participants' own keys. The setting is organization-wide and one-way: once it is on, the platform does not accept turning it off. On-chain state written for a participant, such as identity registrations and role grants, follows the address that wrote it, so switching back would strand what was already written from the account.
Can a weighted account also keep the single-signer validator installed?
Yes, but doing so reopens the direct-management path the weighted validator closes: the account authorizes any actor that any one of its validators authorizes, as covered under Controls and evidence. Remove the single-signer validator once the weighted one is in place, or never install one, if the threshold should be the only way in.
Delegated Authority
Delegated Authority lets a signed-in operator work inside another party's account. One check decides who may enter; the party's own roles decide the rest.
Multisig
Multisig lets a tenant put a wallet under several signers, weighted so authority follows who must actually agree, before any of them can act alone.