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.
A creator drafts a signer list, each signer joins or lapses, and one finalize step deploys the wallet.
A tenant assembles a multisig's signer list before anything commits: the draft stays invisible outside the platform, and nothing exists on chain until the creator finalizes it.
Each invite is single-use, expires after seven days, and stays revocable. Finalize will not run while one is still pending, so a wallet deploys only once every seat has joined, lapsed, or been revoked.
Each seat holds its own weight, so control can follow who must agree in practice rather than a headcount. The threshold totals weight, not signers. Once deployed, weight and threshold become the Smart Wallet's own concern, one of two approval planes under Custody Approval, alongside a custody provider or hardware module gating a single signer's own key.
Why a wallet needs more than one signer
A wallet with a single key has a single point of failure: lose that key, or have it taken, and control over everything it holds goes with it. Multisig spreads that control across several signers instead, weighted so authority follows who must actually agree rather than who happens to hold a key.
A generic N-of-M scheme fixes the single-key problem by adding signers, but it treats every signer as equal, and that rarely matches how authority works inside a financial institution. A treasurer's sign-off usually needs to count for more than a junior desk's, and a counterparty may hold a seat that can never clear the threshold alone. Multisig's weighted seats let the wallet's own threshold mirror that chain of authority. Segregation of duties, the rule that no one person moves funds alone, is then enforced by the wallet contract itself, not by a policy no one can prove was followed.
Why provisioning happens before any wallet exists
Staffing a multisig is worth getting right before it becomes permanent, so the whole process runs on the platform first, as a draft, until the creator finalizes it. That draft-first path is a control of its own, separate from whatever the deployed wallet later enforces.
Who was proposed as a signer, who accepted, and who was dropped before finalizing are facts a compliance review needs, and none of them are visible from the chain alone. A lapsed or revoked invite still keeps the name behind it, evidence a plain on-chain signer list would never show.
Provisioning through the platform, rather than deploying a wallet directly and registering it afterward, also turns the finished wallet into a participant the platform already recognizes. The same account-abstraction infrastructure that sponsors the deployment, the identity and compliance surfaces other participants already have, and the co-signing workflow in Custody Approval are all in place once finalize runs.
What multisig is, and what it isn't yet
Multisig names a specific pairing: the weighted Smart WalletA 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.Read the concept, the deployed account that enforces weight and threshold once it exists, plus the draft, invite, and finalize process that staffs it. This page covers getting from an empty signer list to a working wallet. Smart Wallet covers what that wallet does once it exists.
A draft is not a wallet, and treating it as one is the most common mistake. No signer holds any standing on chain, no address exists, and nothing about it can be enforced until finalize deploys the account with the resolved signer set. See Smart Wallet for the weight and threshold mechanics. See 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 co-sign workflow that governs signing once the wallet exists, for how this approval plane compares with a custody provider or hardware module gating a single key.
Configure signers before deployment
A creator decides who holds a seat and at what weight, and nothing commits until each invited signer joins or declines. Give the seats whose sign-off is not optional enough weight that the wallet cannot act without them, and set the threshold below the full total only where being outvoted by the rest is an acceptable outcome.
Provisioning happens on the platform first, so a creator can build a signer list gradually: invite one colleague this week and a counterparty the next, and watch who joins before finalizing. Nothing about the draft is visible outside the platform, so a plan can be reworked or scrapped with nothing to show for it on chain.
Finalizing is deliberate and one-way: it does not run while any invite is still pending. A creator resolves every invite, by acceptance or revocation, before finalize can deploy the wallet with that signer set. The platform leaves each invite for the creator to close. It sends no reminder of its own.
Running a draft to completion
A creator drafts a multisig with a name, a threshold, and one row per intended signer, then invites each one with a link. Each invite ties to one seat and the weight the creator set for it. The creator shares it directly or sends it by email, so nothing goes out until the creator hands it over. Naming no threshold gets the strictest one: every seat's weight added together, so the wallet needs all of them.
An invited signer accepts by choosing one of their own eligible keys, which commits their address to that seat.
An invite that never joins ends one of two other ways. It lapses, or the creator revokes it. All three outcomes are final.
A creator waiting on a slow signer chases the invite directly, or revokes it and checks that the remaining signers can still meet the threshold. Once nothing is pending, finalizing locks the draft and deploys the wallet with the signers who joined, plus any seat added directly. Signing afterward runs through the co-sign flow Custody Approval covers: create the approval, collect signatures until the weight clears the threshold, then read the terminal status.
Three kinds of seat, and what finalize locks in
A signer row resolves one of three ways. An own seat is the creator's own eligible key. A joined seat is an invited signer who accepted. An external seat is a bare address the creator added directly, with no platform identity behind it. That last kind trades away the off-chain evidence an invite leaves behind: a lapsed or revoked invite still keeps the signer's name, and an external seat keeps none. The FAQ below covers when that trade is worth making.
Provisioning checks run before any account creation request is built. A draft cannot nest another multisig as one of its own signers. Two seats cannot resolve to the same address, and a threshold no combination of seats could reach is rejected outright.
Finalize locks the draft first, then re-derives the signer list from that locked snapshot rather than from whatever state the draft held a moment earlier. That ordering keeps a late edit, or a second finalize attempt, from racing the first. A failure before deployment starts, such as an invite that arrived while the draft was locking or a signer whose key stopped resolving, reopens the draft so the creator can fix it and finalize again. A failure once deployment is already underway instead leaves the draft locked for manual reconciliation, so a retry can never deploy a second wallet against the same draft.
Finalize is also the point where the platform's draft snapshot and the wallet's on-chain signer set are expected to agree, since finalize is what produced the second from the first. A review checking provisioning evidence compares the draft snapshot against the deployed wallet's signer configuration directly.
What runs off chain, and the one call that does not
A multisig draft runs entirely on the platform until finalize. Creating a draft, adding or inviting signers, and accepting an invite all happen against the platform's own records, and only finalize reaches the chain.
Creating a draft seeds an own seat for the creator at weight one. Each invite stores only a hash of a random token, never the token itself.
Finalize carries an idempotent write key derived from the draft and its current member set version, so a duplicate call against an unchanged draft is a no-op rather than a second deployment.
Read Smart Wallet for account constraints and Custody Approval for later co-signing.
Frequently asked questions
What happens if a seated signer's key stops being eligible before finalize?
Finalize checks every seat against the platform record behind it, not just the address captured when the seat was added. If a seated signer's platform wallet was removed after joining the draft, finalize does not proceed, even when the signers who remain still meet the threshold by weight. Reopen the draft, remove or replace that seat, and finalize again.
When is an external seat the wrong choice?
When a review will later need to show who was proposed as a signer and then reconsidered. An own or invited seat leaves that trail behind: a lapsed or revoked invite still keeps the signer's name, so a review can see who was considered and dropped. An external seat records an address without the platform identity and acceptance history of an invited signer. Reach for one only when the signer will never hold a platform identity at all, and only once losing that off-chain trail is an acceptable trade.
Is DALP's multisig the same as a generic N-of-M wallet?
No. A generic N-of-M scheme only counts how many signers took part. DALP's multisig sums each signer's configured weight instead, so a two-signer wallet where one signer holds enough weight alone can execute without the other, while a three-signer wallet with equal weights might need every one of them. A description elsewhere that calls this an N-of-M multisig is shorthand for the same weighted mechanism, not a separate, simpler scheme. See Smart Wallet for the full weight and threshold mechanics.
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.
Custody Provider
A Custody Provider decides who signs for an organization's accounts, a managed custodian or the holder's own wallet, without changing accounts or approvals.