Maker-checker

A single mistaken instruction or a single compromised account cannot move money, file a report, or approve a corporate action alone at five surfaces: reporting sign-off, acknowledgement entry, desk trading limits, trade busts, and hard-to-reverse corporate actions (partial redemptions and payouts in new tokens). The platform will not accept a proposer's own decision on any of them, and sign-off fails closed: it cannot publish unless two distinct people can sign.

An EVM custody call checks one role, not two decisions. 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, not by trusting the role names.

One person proposes; another approvesCopy Anchor Link

Maker-checker limits what a mistaken instruction or a compromised account can do alone. It requires a different party to approve a proposed change before that change takes effect. The platform applies this requirement to specific reporting, trading, and corporate action operations. For on-chain custody calls, check the signing account's approval controls as well as its role assignment.

Why a change needs two people, not oneCopy Anchor Link

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 at five surfaces before any of them can act, so one instruction is never enough on its own.

Reporting sign-off shows the reason plainest. An organization 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, not only that a filing went out. That is also why sign-off fails closed at publish rather than being discovered missing on the filing deadline, a rule this page covers next.

Asset Lifecycle makes a related point about a regulated instrument's issuance and servicing: 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. It runs during the Service stage, on desk limits, trade busts, and reporting sign-off, and again at the corporate-action step that retires holder balances, near the Retire stage, though it stays a control rather than a stage of that lifecycle.

Where the platform itself refuses the proposerCopy Anchor Link

Five 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 partial redemption or a payout in new tokens. Each blocks a decision made by the same person who proposed it, and each keeps a record of who proposed and who decided.

The filing sign-off shows how strict that enforcement is. The second signature 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 will 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: a proposal waits until a different user approves or rejects it. Only an approved desk limit takes effect, and the latest decision wins. The limit then does real work at intake, but it caps the desk's open exposure, not any single order. The platform adds the incoming order to open exposure in the approved scope. A market limit covers that market. A venue-wide limit covers the venue's markets with the same quote token. The order is rejected 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 partial redemption waits after preview until an owner or admin decides it. The corporate actionA Corporate Action pays a coupon, a dividend, or a matured redemption straight to token holders, turning an issuer's announced terms into an on-chain payout.Read the concept, the issuer event that retires holder balances on a published plan, cannot run before that decision. The checker must not be the person who recorded the redemption or ran its last preview, and must decide from a signed-in session rather than an API key or 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. Unlike reporting sign-off, this gate does not fail closed. An organization can switch it off, and an organization with no second owner or admin opens the redemption without it. The record names which of the two reasons applied. A dividend, bond coupon or distribution paid in new units of the token, rather than cash, waits for the same decision under the same rules, because the platform has no step that takes minted units back. 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 organization 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 or admin role, the two roles counted as eligible approvers. The requirement is a per-obligation switch, on by default: a newly configured obligation requires maker-checker unless someone turns it off. An obligation published with the switch off carries no second approver on its filings at all, so "we run maker-checker" is a claim about specific published obligations rather than about the organization.

An EVM role does not require two approvalsCopy Anchor Link

The EVM Contract SetThe EVM Contract Set is the identity, compliance, custody, and settlement contracts DALP deploys around one composable security token, checked in one call.Read the concept, the deployed contracts that gate privileged calls on role permission, checks the custodian role before freezing an address or forcing a transfer. Any address with that role can authorize the call alone. Granting the same role to two addresses lets either address act; it does not make them 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 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 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 authorize a call.

Check the wallet's full validator configuration. A single-signer validator installed beside the weighted validator can let its owner authorize a call directly. A threshold also counts signatures, not independent people: confirm who controls each signing key.

Verify the approval requirement and its scopeCopy Anchor Link

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 approver 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 authorizes 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 questionsCopy Anchor Link