A creator drafts a signer list, each invited signer joins or is revoked, and one finalise 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 finalises it.
Each invite is single-use, expires after seven days, and stays revocable until then. Finalise does not run while an invite is pending. A lapsed invite stops counting as pending and leaves its seat empty, so the creator can finalise once every invite has been accepted, revoked or lapsed.
Each seat holds its own weight, so control can follow who must agree in practice. The threshold totals weight, and a seat whose weight reaches it can act alone. 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 and weights each seat so authority follows who must agree.
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. The wallet contract then enforces that no instruction executes until the weight behind it reaches the threshold. Give no single seat a weight that reaches the threshold if no one person may act alone.
Why provisioning happens before any wallet exists
The whole staffing process runs on the platform first, as a draft, until the creator finalises it. That draft-first path is a control of its own, separate from whatever the deployed wallet later enforces.
Who accepted a seat, with which key, and which seats were offered and then withdrawn before finalising are facts a compliance review needs, and none of them are visible from the chain alone. A revoked invite stays on the draft with the weight it offered and, when the creator emailed it, the address it went to, evidence a plain on-chain signer list would never show.
Provisioning through the platform, instead of deploying a wallet directly and registering it afterwards, also turns the finished wallet into a participant the platform already recognises. 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 finalise runs.
What multisig covers
Multisig names a specific pairing: the weighted Smart Wallet, the deployed account that enforces weight and threshold once it exists, plus the draft, invite, and finalise 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. Multisig belongs to the Self-custody module. Where the deployment or the organisation has that module off, wallets keep one signer and a threshold of one.
A draft is not a wallet. No signer holds any standing on chain, no address exists, and nothing about it can be enforced until finalise deploys the account with the resolved signer set. See Smart Wallet for the weight and threshold mechanics. See Custody Approval, 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 invite is accepted, revoked or lapsed and the creator finalises. 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.
A creator can build a signer list gradually: invite one colleague this week and a counterparty the next, and watch who joins before finalising.
Finalising is one-way, and it does not run while any invite is still pending. Finalise deploys the wallet only after every invite is accepted, revoked or lapsed. The platform sends no reminder, so a draft with an unanswered invite stays unfinalised until the signer joins, the creator revokes the invite, or seven days pass. A lapsed invite shows as Expired on the draft and adds no weight, so check that the seated signers still reach the threshold before finalising.
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 opens the link, signs in, and accepts by choosing one of their own key wallets, a wallet controlled by a single key, which commits its address to that seat. The seat then shows as joined.
An invite that never joins either lapses or is revoked by the creator.
Joined, lapsed and revoked are final. A lapsed invite can no longer be accepted, and finalise deploys the wallet without its seat.
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, finalising locks the draft and deploys the wallet with the signers who joined, plus any seat added directly. Signing afterwards 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. In the Console each signer finds the wallet under Shared accounts in the sidebar, and its Approvals tab lists the approvals waiting for their signature.
Three kinds of seat, and what finalise 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 joined seat records which platform participant accepted and with which key, and a revoked invite keeps the weight it offered and any email it went to, while an external seat keeps only its address and weight. The FAQ below covers when that trade is worth making.
Provisioning checks run before any account creation request is built. An own or invited seat must be a key wallet, so neither can be another multisig. The platform does not check an external seat's address, so it does not stop that address from being one. Two seats cannot resolve to the same address, and a threshold no combination of seats could reach is rejected outright.
Finalise locks the draft first, then re-derives the signer list from that locked snapshot, so a late edit or a second finalise attempt cannot race the first. Deployment then switches the new wallet to the weighted signer set. A failed finalise ends one of three ways:
Finalise runs in the background. The call waits only as long as the caller asked, and otherwise answers 202 with a finalise request, which the caller reads until it reports the participant and the Smart Wallet. The draft reads as finalising until the run finishes.
The platform's draft snapshot and the wallet's on-chain signer set agree because finalise builds the wallet from the draft. 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 finalise. Creating a draft, adding or inviting signers, and accepting an invite all happen against the platform's own records, and only finalise 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.
Finalise carries an idempotent write key derived from the draft and its current member set version, so a duplicate call against an unchanged draft deploys nothing new.
Frequently asked questions
What happens if a seated signer's key stops being eligible before finalise?
Finalise checks every seat against the platform record behind it, as well as the address captured when the seat was added. If a seated signer's platform wallet was revoked or removed after joining the draft, finalise does not proceed, even when the signers who remain still meet the threshold by weight. The draft reopens, so remove or replace that seat and finalise again.
When is an external seat the wrong choice?
When a review later needs to show who was proposed as a signer and then reconsidered. An invited seat leaves that trail behind: a joined seat records which participant accepted, and a revoked invite keeps the weight it offered and any email it went to, so a review can see a seat that was offered and withdrawn. An external seat records an address without the platform identity and acceptance history of an invited signer. Reach for one only when the signer never holds 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. Where other material calls this an N-of-M multisig, it means the same weighted mechanism. See Smart Wallet for the full weight and threshold mechanics.