Wallets that need more than one person
A participant account can now be a multisig wallet where each seat carries its own weight and the bar to clear is a total of weights rather than a signer count.
Institutional control is rarely one person with one key, and until now a participant account on DALP was exactly that. A participant can now be a multisig wallet, meaning an account that acts only when enough of its signers agree.
Weights, not head counts
A creator drafts the wallet on the platform: a name, a bar to clear, and one row per intended signer. Nothing exists on chain while the draft is open. Signers join by invitation, and the creator finalizes once to deploy the wallet with whoever has joined.
- Seat weight
- Set per signer
- Threshold
- A total of weights
- Invites
- Single use, seven days
- Deploys
- Once, at finalize
Why weights and not a count
A weighted threshold lets the wallet assign different authority to each signer. An operation needs enough collected weight to reach that threshold.
Each seat here carries its own weight, and the threshold totals those weights rather than counting heads. A treasurer's seat can outweigh two junior seats. A counterparty can hold a real seat that never clears the bar on its own. If a creator sets no explicit bar, the strictest one applies: every seat's weight added together, so the wallet needs all of them.
Staffing happens before anything reaches the chain
A multisig is a staffing decision first, and the flow respects that order. The draft is a record on the platform and nothing more, so a creator can change their mind without an on-chain trace of a wallet that never existed.
Set a name, the bar to clear, and one row per intended signer. The creator is seeded as a seat at weight one. Two seats cannot resolve to the same address, a draft cannot name another multisig as one of its signers, and a bar no combination of seats could ever reach is refused outright.
A seat is filled one of two ways. Invite a person on the platform, and they accept by choosing one of their own eligible signing keys, which commits that address to the seat. Or add an external seat: a bare address, with no platform account behind it, for a hardware wallet or a counterparty.
An invite is a single-use link, delivered by email, valid for seven days, and revocable while the draft stays open. The platform sends no reminder, so the creator must follow up on outstanding invitations.
Finalizing is the creator's call, not a wait for every invite. It locks the draft, drops the invites still pending, and deploys the wallet with the signers who had joined. From then on the account enforces its own weights and threshold on every instruction.
Day to day, it is a co-signing queue
Once the wallet exists, acting through it works the way a control function expects. Any signer proposes an operation, the others co-sign, and the operation executes when the collected weight clears the threshold. The Console shows the progress toward the bar and the time remaining, because a proposal does not wait forever.
The threshold is not a check the Console performs. The deployed account is itself code on the chain, and the weights and the threshold live inside it as a module it installs. The account adds up the signatures it was given and refuses anything below its own bar before it executes, so submitting straight to the chain and bypassing our interface reaches the same refusal. Changing a signer or moving the threshold is not an exception: that instruction is validated through the threshold like any other, so there is no side door into the account's own rules.
The record survives the people
Invitation history remains available after provisioning.
Each invite keeps its own record: when it was created, the weight it carried, whether it lapsed, was revoked, or was accepted. That record outlives the deployed wallet and is independent of it. If a review needs to show who was proposed for a seat and then dropped, the record carries that name. The signer list on the chain never would, because it only ever shows who ended up seated.
Invites are stored as a hash of a random token rather than the token itself, so the platform cannot reproduce a link it already sent.
Availability and compatibility
A multisig wallet is one of the platform's smart wallets, meaning an account that is code on the chain rather than a private key. Deploying one needs the service that submits and pays for that deployment, so an organisation needs that service enabled and configured on the chain in question before it can finalize a draft. Where it is not enabled, the option is unavailable rather than silently broken.
Nothing changes for single-signer participants. That path is untouched, existing participant accounts keep working exactly as before, and multisig is an added option at creation rather than a replacement. There is no migration.
Note the boundary between the two: this is the process that staffs and deploys the wallet. Weight changes, threshold changes, and reconfiguration afterwards belong to the deployed account itself.
Understand multisig provisioning → · How the deployed account enforces it → · Compare the approval planes →
Regulatory reporting
Report families now generate from platform data on your filing schedule, and every state-changing request is recorded with the person, role, and outcome.
Transfer pre-check
A read-only check answers whether a transfer would clear an asset's compliance rules before anyone signs, naming every blocking rule and who can resolve it.