A platform approval and a weighted wallet enforce a decision or signature requirement, while a role assignment grants permission without a second approval.
Every switch under Approvals starts off. Once an owner or platform administrator turns the matching switch on, a single account cannot alone sign off a report, change a desk limit, bust a trade, run an irreversible corporate action such as a stock split, a partial redemption, a cash dividend or a payout in new tokens, or make a change in a protected family such as creating an asset. While a switch is on, the platform does not accept the proposer's own decision.
Some checks need no switch. Filing sign-off and acknowledgement entry always refuse the person who prepared or approved the submission, and two bank rail controls always refuse the proposer. An identity recovery asks a second owner or administrator by default: the Recovery group of Administration starts on, and an owner turns it off to run a recovery alone. The Administration rule does not hold a mint of an existing asset. On a token linked to a bank rail, the Bank rail row holds a mint over the credit limit.
An EVM custody call checks one role and needs no second decision. A weighted Smart Wallet can hold that role and add a signature threshold on top of it. Verify a maker-checker claim by checking who can sign.
What maker-checker requires
Maker-checker is the control in which one person, the maker, raises a change and a different person, the checker, decides it before it takes effect. The platform applies it to specific reporting, trading, corporate action, bank rail and administration changes. For on-chain custody calls, check the signing account's approval controls as well as its role assignment. Custody Approval is the neighbouring control on the key signature itself.
Why a change needs two people
Left alone, a single mistaken instruction or a single compromised account could file a regulatory report, raise a trading desk's risk limit, or retire holder balances in a corporate action, with no one else ever seeing the decision. Maker-checker puts a different person in that path before the change can act.
Reporting sign-off shows the reason most clearly. An organisation configures an obligation for maker-checker so it can show a regulator that someone other than the filer reviewed the numbers before the platform published them, as well as that a filing went out. That is also why sign-off fails closed at publish: a missing second signer is found at publication, before the filing deadline.
A review that lives outside the system it governs can be skipped without anyone noticing. Maker-checker avoids that gap by checking, inside the platform's own write path, whether the decision came from someone other than the proposer. The check applies to writes through the platform. A holder of an on-chain role who calls the contract directly is outside it, as An EVM role does not require two approvals explains.
Where the platform itself refuses the proposer
These surfaces keep this check inside the platform's own write path: signing off a reporting obligation's filing, entering the authority's acknowledgement of one, approving a trading desk's limits, busting a trade, and approving a corporate action that cannot be reversed once it runs. Those corporate actions are a stock split, a bonus issue, a rights issue, a spin-off, a capital decrease, a partial redemption, a coordinated distribution, a dividend or distribution paid in cash, a payout in new tokens and a buyback. Each blocks a decision made by the same person who proposed it, and each keeps a record of who proposed and who decided. For desk limits and trade busts this holds on a venue whose Trading venues switch is on. A venue with the switch off applies them at once, and the approvals ledger records that the approval policy waived the second person.
Two bank rail controls also refuse the proposer, and no Approvals switch turns them off. A client's bank account is active only after a bank rail manager other than the one who proposed it approves it, and the platform refuses the proposer's own approval. Executing or abandoning a recall, the reversal of a credit that the bank took back, starts with a request and waits until a different bank rail manager approves or rejects it. The requester cannot decide it and an impersonated session cannot either. Turning the Bank rail row under Approvals off changes neither rule. That row governs the other bank rail changes, such as a cash-out over the checker threshold, and starts off like every approval. The roles page lists both controls beside the others.
The second signature on a filing must come from a different signed-in person. The platform declines an approval by the person who prepared the filing, because the two signatures would be one person's. It also does not accept one from an operator acting on another user's behalf, because an impersonated session cannot be the second signature. And the approval binds to the exact version the checker reviewed: a filing that changed after the review does not get approved, because applying it would approve bytes nobody read.
Acknowledgement entry follows the same rule under its own name. Recording the authority's acknowledgement discharges the filing period's duty and stops its overdue clock, and the platform does not record it when the entering user is the same person who approved the underlying submission. Entering and approving are two different acts, and each needs its own second person.
Desk trading limits and trade busts run through one shared approval record. On a venue whose Trading venues switch is on, a proposal waits until a different user approves or rejects it. The Console offers the proposer no Approve or Reject on their own proposal. On a venue with the switch off, the proposal is recorded already approved: a desk limit is enforced at once and a bust of an undelivered trade starts its undo at once. A bust of a delivered trade, whose reversal force-transfers the holders' tokens, always waits for a different user. Only an approved desk limit takes effect, and the latest decision wins. An approved proposal is settled: a second approve or reject of it is refused as already decided.
A limit names one wallet, one instrument and that instrument's quote token, and it caps the desk's open exposure across orders. The platform adds the incoming order to the wallet's open exposure on the instrument and rejects the order before it reaches the book when that total exceeds the limit. An order well under the limit on its own can still be rejected once the desk's existing exposure pushes the total over. A desk limit approved before limits had an instrument scope has no quote units, so the wallet cannot trade until an operator approves a scoped replacement.
The same Trading venues switch also governs the other venue controls. A venue configuration change, a fee schedule change, a venue VAT policy change, an operator order cancel and a mass cancel of open orders each wait for a different holder of the role the change needs. With the switch off they apply at once, and the approvals ledger records the waiver. The switch protects itself: switching it off, or letting an emergency halt skip it, is a venue configuration change too, so a second venue admin has to approve it, and a venue with a single admin has to add a second one first. Switching it on applies at once. Venue controls lists each control with its role.
After the maker sends a partial redemption for approval, it waits until an organisation owner or a platform administrator decides it. The corporate action, the issuer event that retires holder balances on a published plan, cannot run before that decision. In the Console the maker enters the PIN once on Review to send it, the sheet reads “Waiting for approval”, and the checker approves with their own PIN. The maker then reopens the run and enters the PIN once more to run the approved plan.
The checker must not be the person who recorded the redemption or ran its last preview. The checker can decide from a signed-in session or with their own API key, but not from an impersonated session. The approval binds to the plan the checker read. A plan that changes afterwards loses its approval, and a decision not made within 72 hours of the last preview ends the record.
Every owner of the organisation and every platform administrator who is a member of it receives an email, except the maker. An owner or a platform administrator can decide it from Actions, where it shows as an “Approval request”. The person who prepared it receives an email when it is approved or rejected.
Unlike reporting sign-off, this gate does not fail closed. The Corporate actions row under Approvals starts off, so an organisation turns the gate on there, and an organisation with no owner other than the maker opens the redemption without it. The record names whether the Corporate actions row was off or the organisation had no owner other than the maker. A dividend, bond coupon or distribution paid in new units of the token waits for the same decision under the same rules, because the platform has no step that takes minted units back. So do the other corporate actions this section lists. Approve or reject a partial redemption covers the calls.
Where sign-off is required, it also fails closed at publish time. An obligation that demands two signatures in an organisation where one person can sign creates a deadlock, one discovered only on the filing deadline. The platform therefore does not publish it until at least two distinct people hold the owner role, because owners are the only eligible approvers it counts. The requirement follows the Reporting switch under Approvals, which starts off. An obligation can carry its own exception to that switch. The publish-time check for two eligible approvers therefore applies per obligation: with the switch off for an obligation, the platform publishes it whatever the number of approvers. Whatever the switch says, the filing sign-off refuses the person who prepared the filing.
Who decides a request from the Approvals inbox
Each kind of request that waits in the Approvals inbox names who may decide it, and approving and rejecting follow the same rule. A held administrative change, a reconciliation break resolution, a dividend entitlement push and a token sale are decided by a member who holds one of the request's approver roles, and only by such a member. No role decides by default: when the approval policy names other roles, an owner or a platform administrator who holds none of them is refused with approver-, the message names the roles that may decide, and the request keeps waiting. A platform administrator who also holds an organisation role decides with either role. A wallet checker approval is decided only by the wallet's named checker. A decision from anyone else is refused with not-named-approver. The maker never decides their own request.
A member who may not decide a request cannot read it through GET /api/ either, unless they made it: the route answers 404. A request that is decided in its own workflow, such as a held price, a bank-rail operation or a corporate action, is refused on POST /api/ with wrong-kind and HTTP 409, and stays where it was raised.
Impersonated sessions cannot decide
A platform administrator can impersonate a member. An impersonated session can still propose, but it cannot approve or reject. This stops one administrator from proposing as themselves and then approving as a second operator. On trading venue items and on the requests in the Approvals inbox, a proposal made while impersonating records the administrator, so the administrator cannot approve it later in their own session either. KYC works the same way: a KYC version submitted while impersonating, and a profile field or organisation detail edited while impersonating, keep the administrator next to the member. The administrator cannot then review that version or those fields in their own session. With the demo switch below on, this KYC check lets the administrator review them.
An impersonated session also cannot give out a sign-in for the member: it cannot approve a device sign-in such as dalp login, add a passkey, or connect an MCP client. Each of these would let the administrator sign in later as the member without the impersonation mark. The refusals answer with HTTP 403 and the codes IMPERSONATED_, IMPERSONATED_ and IMPERSONATED_OAUTH_GRANT. The demo switch below does not lift them.
The refusal covers every decision on an item that waits for a second person: desk limits, trade busts, operator order cancels, mass cancels, venue configuration and fee schedule changes, venue announcements, add-on access proposals, account closure requests, client bank accounts, Canton wallet submissions, custody approvals and lifecycle approvals, KYC and profile reviews, participant registrations, transfer approvals, and the requests in the Approvals inbox. The Platform API answers such a request with DALP-200386 (IMPERSONATED_) and HTTP 403, and nothing changes. The frozen v1 KYC approve and reject routes answer with their usual 403 session-policy refusal. In the Console, Approve and Reject on the trading venue screens are disabled during an impersonation and read “Sign in as yourself to decide”. Other screens show the refusal after the click.
A demo deployment can switch this off with the Helm value global. (ALLOW_ outside the chart). It is false by default and in every shipped values file. Keep it off on any deployment that holds real assets or real people. Three acts refuse an impersonated session even with the switch on: the filing sign-off and its publish, a legal-hold release, and a change that loosens the approval policy.
Issuing an asset with an external custody provider
Approvals are an organisation setting, and every approval starts off except the Recovery group of Administration, which starts on. Until an owner or a platform administrator turns a family on in the Approvals section of the General settings, a change in that family goes ahead on the maker's request alone, and Actions shows it as “No second approval (approval off)”. Identity recovery is the exception, and it also runs alone where the organisation holds no owner or administrator besides the person recovering: the platform cannot ask a person who does not exist.
Creating an asset is an administration change in the Token administration protection group. Turning on the Administration family protects every protection group, Token administration included, unless an exception turns that group off. An exception can also protect Token administration on its own while the family stays off. Either way, creating an asset then waits for a checker. An organisation that sets its protection groups as a list through the approval policy API holds asset creation only when that list includes Token administration.
User A's asset request waits for user B's approval, then DALP runs it as user A, the custody provider signs, and the asset appears in the Console.
The steps in order:
- User A creates the asset. The request needs user A's wallet verification. Instead of running it, DALP records an “Approval request” and answers the API call with
202and a status address under/. Nothing is signed and nothing reaches the network.api/ v2/ checker- approvals/ - DALP holds the request. The approval request stays open for 24 hours, or for the expiry an owner set on administration changes through the approval policy API. A request that nobody decides in that time expires, and a rejected request ends. Either way nothing ran, and user A submits the change again to retry. A second request for the exact same change, while the first one waits, is refused with
409. - User B approves it. The checker must be an owner of the organisation or a platform administrator. The platform does not accept a decision from user A, or from a session in which a platform administrator acts as another user. A member who is not an owner cannot decide unless an owner named the Member role as approvers of administration changes through the approval policy API. Once approver roles are named, only those roles decide: an owner or a platform administrator who holds none of them is refused, and the refusal names the roles that may decide. When the “Approvals required” setting in the Approvals section of General settings is above 1, that many different people must approve. An organisation with no second owner needs a platform administrator to decide, or the request lapses. A platform administrator is an operator of the deployment, not a member of the organisation, and the record names who decided.
- DALP runs the request as user A. The platform runs the original request with user A as the requester, so the record shows who made the change and who approved it. If user A lost the permission to create assets while the request waited, the platform refuses to run it. Otherwise the Transaction Lifecycle Engine, the part of DALP that queues, sends and tracks every on-chain write, queues the transaction. DALP runs an approved request once: a second approval or a repeated decision does not run it again. Reading the request at its status address shows how the run went in
executionState:pendingbefore it starts,running,completed,failedwhen it stopped before the change was applied, orreconciliation-requiredwhen it ran in part and an operator must confirm the outcome. - The custody provider checks its own policy. The signing request goes to the custody provider that holds user A's key. Its policy decides whether the signature needs its own approvers, and the transaction waits for that decision within the approval deadline the deployment sets, at most 24 hours. On a network where a paymaster pays the gas, the wait also ends 60 seconds before the gas sponsorship ticket expires, which leaves about four minutes by default. Gas sponsorship explains the ticket. Custody Approval explains where each provider takes that decision.
- The custody provider signs. Depending on the provider's mode, the provider broadcasts the signed transaction, or it returns the signature and DALP broadcasts it.
- The network records the asset contract. The transaction lands in a block.
- DALP confirms it. DALP's indexer reads the block, and the asset appears in the Console.
While the request waits, DALP keeps it as user A sent it, so it can run it unchanged in step 4. A value the approval details show as [REDACTED], such as a bank connection's logon password or a custody provider's credentials, is stored encrypted with the platform key and opened only to run the approved request. If that value no longer opens, the platform refuses to run the request.
The two approvals answer different questions. The platform approval in step 3 proves that a second person in the organisation agreed to the change. The custody provider's policy in step 5 proves that the key holder's own rules allowed the signature. Neither one replaces the other, and an organisation that wants both turns on the Administration rule in DALP and configures the policy at its custody provider.
While administration changes are protected, user A cannot switch the rule off alone either: turning an approval off waits for another owner or a platform administrator, so an organisation with a single owner needs a platform administrator for it. Until someone decides it, user A can withdraw that held turn-off from the Approvals row on General, and the decider sees each setting as it stands then next to the value the change would set.
Minting units of an existing asset is not held by the Administration rule. A mint goes ahead on the maker's request, subject to the custody provider's policy and, for a weighted Smart Wallet, its signature threshold. For a token on a bank rail, the Bank rail family holds a mint above the credit limit and a raise of the mint limit. Roles and segregation of duties covers how to keep the roles that mint apart from the roles that approve.
The v1 API cannot hold a request, because no v1 client can read the 202 answer. A v1 write whose v2 route a protected group would hold is therefore refused instead, before anything runs. Creating an asset through POST /api/ while Token administration is protected, for example, answers 403 with the code FORBIDDEN and the id that route already returns for a refused caller (DALP-9485 on token routes, DALP-12252 on platform routes, DALP-0003 on identity, compliance and user routes). The message names the protection group, and data.fix names the v2 route to send the change to, here POST /api/. Four v1 writes had no 403 before and now answer DALP-12252 the same way: registering an external token, requesting a KYC profile update, creating a user and revoking a user's session. A v1 write whose v2 route is never held, such as a mint, runs as before.
An EVM role does not require two approvals
The EVM Contract Set, the deployed contracts that gate privileged calls on role permission, checks the custodian role, the token role that may freeze an address or force a transfer, before either call. Any address with that role can authorise the call alone. Granting the same role to two addresses lets either address act alone, so they do not co-sign.
Separating roles can restrict which person starts each kind of operation. It does not add an approval step to a function that checks one role. For a custody call that needs two signatures, a weighted Smart Wallet, the on-chain account that signs only when its collected signatures meet its threshold, can hold the role. Its signer weights and threshold decide which combinations can authorise a call.
Check the wallet's full validator configuration. A single-signer validator installed beside the weighted validator can let its owner authorise a call directly. A threshold also counts signatures, not independent people: confirm who controls each signing key.
Role permission
The asset contract asks whether the calling address holds the required role. Multiple role holders can each act independently.
Signature threshold
The wallet asks whether the collected signatures meet its configured threshold. Its other installed validators must not provide a path that bypasses the intended approval policy.
Verify the approval requirement and its scope
For a platform approval, inspect the proposal, the decision, and the identities that made each. On reporting obligations, confirm that sign-off is enabled. An obligation published without that requirement does not need a second person on its filings. On a partial redemption, read the record's approval policy and waiver: a waived record ran without a second approver.
For an EVM custody call, identify the role that authorises the call and every address that holds it. Then check how each address signs. Counting role holders alone cannot establish maker-checker.
Revoking a role changes who can make the next call. It does not reverse a settled transfer. Preserve the approval record, wallet configuration, role history, and transaction reference needed to assess an earlier operation. Current role membership alone cannot prove which controls applied at that time.
Frequently asked questions
Does a maker-checker requirement mean two people must click a button?
No. The second act can be a recorded decision by another signed-in user or a signature required by the signing account. An ordinary EVM role check alone does not provide that second act.
Does the impersonation rule also cover publishing?
Yes. Publishing an obligation configured for it is what discharges the filing duty, so the platform applies the same rule to that act as to an impersonated approval. A publish attempt from an operator acting on another user's session is blocked, and so is a publish attempt on a submission that was never signed off in the first place. Both cases protect the same fact: a published filing traces back to a signed-in person's own decision. With sign-off off for an obligation, the filing still refuses the person who prepared it.
What happens when the filing changes after the checker reviewed it?
The pending approval is voided and does not carry over to the new content. A sign-off binds to one exact version of the filing, so any edit or regeneration after the checker's review invalidates what they approved, and the filing needs a fresh sign-off before it can publish. The same rule stops a second approver from acting on a submission someone else already approved.
Does approving a trade bust mean the trade is reversed?
Before delivery, yes. After delivery, approval starts the reversal, and it completes only once the tokens' compliance rules allow the transfers. A bust can be proposed within 24 hours of the trade once neither of its orders is still open. Before delivery, approval undoes the trade on the venue by unlocking both legs. After delivery, approval reverses it with custodian forced transfers under the organisation's operations signer, the platform-managed account that signs the platform's writes for the organisation. Listing a market on a venue grants the token's custodian role to that operations signer when the signer listing it may grant that role, and the role can force-transfer and freeze any holder's units of the token, beyond the units in a trade. On a venue whose Trading venues row under “Approvals” is on, a different operator must approve the bust. With the row off, the bust is recorded already approved and runs at once.
Before delivery, approval submits one on-chain call that releases both locked legs. After delivery, it sends the forced transfers. Read the trade's outcome to confirm completion. If the call completed before the platform recorded the result, the Console's “Resume” control completes the remaining record updates. See Trade busts for the workflow and its limits.
How is maker-checker different from custody approval?
They are neighbouring controls that answer different questions. Maker-checker requires a different party's decision before a change takes effect. Custody approval gates the signing of one prepared transaction, and its approvers come from the wallet's own policy: a custody provider's rules, a hardware module's quorum, or a multi-signature wallet's signers.