Non-custodial dApps often become custodial unintentionally as teams add backends, relayers, and convenience features. The boundary is not about UI or infrastructure presence, but about control: who can initiate fund-moving actions and who can change withdrawal conditions. This note summarizes the custody red line and compares multisig and MPC wallet models, then outlines a signless authorization pattern that improves checkout UX while keeping fund control on-chain and user-governed.

TL;DR

Goal: Define the practical boundary between custodial and non-custodial payment infrastructure and document design patterns that preserve non-custodial guarantees while improving authorization UX.

Scope: Risks of accidental custody emergence, common architectural pitfalls (backend keys, master keys), multisig vs MPC wallet models, and a signless authorization flow implemented via 2-of-2 multisig + escrow verification with off-chain indexing for status delivery.

Result: A design checklist and threat model for teams building payment flows, or authorization layers without crossing into custody.

What “Non-Custodial” Actually Means

“Non-custodial” is frequently treated as a label, but in production systems it is better understood as an operational property.

The boundary

Custody emerges when a service can unilaterally change withdrawal conditions or recover control without the user.

Everything else, including UI, servers, relayers, and proxy contracts, matters only insofar as it changes who can initiate a funds-moving action.

Shades of custody

In practice, custody exists on a spectrum:

• a service can fully control funds (full custody),
• or it can be restricted to pre-agreed recipients (“semi-custody”).

Risks of Accidental Custody Emergence

Custody rarely appears as a stated goal. It often emerges as a side-effect of scaling a system.

The most common trigger is the introduction of a backend layer. This does not automatically create custody, but starts paving the road to it because backends tend to accumulate “convenient” capabilities over time.

Typical “silent custody” points:

• server-side key handling,
• operator signing keys,
• emergency recovery paths that bypass the user.

Architecture Patterns That Turn Payments Custodial

Across payment systems, the failure mode is consistent. Relayers, proxy contracts, and indexers do not make a system custodial by themselves. They become custody-relevant only when paired with signing authority, meaning the ability to initiate transfers, or with privileged controls, meaning the ability to change withdrawal rules, rotate keys, or bypass user approval.

1) Any server-side ability to initiate user transfers

This includes:

• storing user private keys in a recoverable form on a server,
• holding a master key that can withdraw user funds,
• having a control key that can change access rules for user balances.

These patterns often emerge during “UX improvements”, “automation”, or “reliability hardening”.

2) Master keys stored in contracts

A master key that can:

• modify permissions
• re-route withdrawals
• or execute transfers on behalf of users

is functionally custody — even if the UI calls it “non-custodial”.

Why Non-Custodial Matters for Payment Infrastructure

The primary reason is not philosophical. It is operational.

Once a system becomes custodial, it attracts materially higher regulatory and compliance scrutiny. That often cascades into:

• KYB requirements for merchants
• KYC requirements for consumers
• heavier onboarding, integration, and ongoing compliance overhead

For payment infrastructure optimized for frictionless adoption, that shift breaks the core objective.

Wallet Control Models for Payments and Merchants

Payment flows introduce a recurring trade-off:

• single-key wallets are simple but fragile
• multi-approval wallets are safer but can harm conversion

Two solution families dominate production designs: multi-signature wallets and MPC / threshold signing.

Multisig: Contract-Enforced Quorums

Multisig is a smart account that executes an action only if it collects a quorum of signatures M-of-N.

Common multisig forms

• Classic M-of-N: standard for treasury and corporate custody separation
• Role-based multisig: not “any M”, but structured approvals (e.g., CFO + CEO required)
• Policy-extended multisig: contract-level constraints such as:
  
  • withdrawal limits unless a specific key signs
  • withdrawals only to allowlisted addresses

Why multisig exists in practice

• reduces theft risk (one compromised key ≠ immediate loss)
• enforces separation of duties
• supports team changes without migrating funds (if contract supports it)
• creates an explicit audit trail (“who approved”)

In production, the most common implementations are Safe (formerly Gnosis Safe) and ERC-7579-style modular smart accounts.

MPC / Threshold Signing: Single-Signature UX Without a Single Key

MPC (multi-party computation) / threshold signing is a model where:

• the private key is not held by any one party
• participants hold shares of the key
• signatures are produced via a t-of-n protocol
• the result appears as one normal signature on-chain

Why MPC is used

• preserves a “single-key” signing UX
• avoids a single point of failure
• fits high-frequency operations where manual multisig approvals reduce conversion
• often reduces on-chain verification overhead compared to multisig contracts, depending on the account model

Multisig vs MPC: Practical Differences

Multisig

• multiple full keys exist
• each key can sign independently
• contract validates multiple signatures

MPC

• shares are not keys
• a share cannot sign alone
• the chain usually sees one signature

On-chain visibility

• multisig participation can often be inferred from on-chain data by seeing which keys signed
• MPC signer structure is not visible in the same way and is generally more opaque

UX

• multisig can require multiple explicit approvals
• MPC keeps a single-step signing experience

Operational trade-offs

• Multisig: operational friction through coordination between approvers and slower execution in high-frequency flows
• MPC: operational dependency on provider availability, the recovery model, and the durability of the signing setup

In practice, the difference is less about “more secure” and more about auditability vs UX and operational ergonomics.

Are MPC Wallets “More Promising” for Payments?

Not strictly.

One property is clearer:

• MPC is generally more opaque from on-chain observation, making it harder to infer the signer set
• multisig is more explicit

Which is better depends on constraints:

• conversion vs audit trail
• operational complexity vs transparency

Signless Authorization: A Non-Custodial Design Pattern

"Signless" in this context is an authorization UX goal:

• the user confirms via a familiar local factor (e.g., Face ID / PIN)
• while the system does not gain unilateral control over funds

Architecturally, the flow is a specific configuration of account abstraction: the escrow is a smart account, payments are submitted as UserOperations through a bundler, and the "Gas vault" referenced in the Flow Outline below is a paymaster sponsoring gas so the user pays only in the payment token. Under ERC-7579, the co-signer can be plugged in as an authorization module (called a validator in ERC-7579 terminology) rather than hard-coded into the account, which keeps it rotatable. The non-custodial requirement adds one constraint to a vanilla 4337 + Safe deployment: the co-signer's role is signature validation only, with no withdrawal or admin role on the escrow.

Core model

A signless flow can be implemented via 2-of-2 multisig:

• one signing key is user-held
• one signing key is infrastructure-held
• executing the payment requires both signatures

The co-signer cannot initiate a transfer on its own and cannot withdraw from escrow.

Escrow constraint (critical)

To avoid custody, the design includes an escrow contract (similar to a prepaid account) where:

• signature validity is checked on-chain
• and withdrawal / key-change powers remain on the user side

Escrow withdrawal is user-controlled; the co-signer alone cannot extract funds.

The intent is explicit:

• infrastructure participates in authorization
• but cannot extract funds unilaterally

Threat Model and Trust Assumptions

Who trusts whom

• The user must trust the implementation that the co-signer key is stored encrypted and is only unlocked under the intended local authorization flow.

This is a narrower trust assumption than “the service controls my funds”, but it is still a trust boundary and should be stated.

Source of truth for payment status

• On-chain settlement is the ground truth.
• Off-chain indexing is used for delivery of status signals to merchants.

Operationally:

• merchants learn about completion only after the system indexes the transaction and emits the corresponding notification.

Signless Flow Outline (Operational)

This is a concrete implementation outline for signless authorization using 2-of-2 multisig and escrow verification:

Key handling

• a dedicated key is created for the user flow,
• stored on backend in encrypted form (password-encrypted),
• an encrypted artifact is stored locally on the device, derived from the PIN / biometric authorization flow.

Execution path

1. Backend constructs the transaction route (e.g. for navigation via Gas vault for gasless transaction).
2. User passes Face ID
3. The key is decrypted and used to sign on-device, then wiped from memory
4. Signed transaction is sent to backend
5. Backend verifies:
   
   • user authority (e.g. session JWT)
   • transaction body (e.g. sufficiency of funds on escrow)
6. backend signs with the infrastructure key
7. transaction is sent to user escrow
8. escrow verifies signatures and executes token transfer

What stays on the user side

• key changes
• withdrawal from escrow / control operations

This split is the non-custodial boundary in practice:

• infrastructure can co-sign
• but cannot override user control paths

Risks in MPC Architectures and When MPC Becomes Custodial

Key risk: provider dependency

If an MPC provider disappears, recovery may be difficult or impossible depending on the scheme.

When MPC crosses into custody

An MPC solution becomes custodial if:

• the provider has a backup capable of reconstructing the key, or
• the provider can reach a signing threshold without the user

This is consistent with the boundary above.

Closing Notes

Non-custodial systems rarely fail because teams “decide to become custodial”. They fail because custody emerges as a convenience feature.

The safest way to avoid that drift is to define non-custody as an operational rule-set. Everything else, including indexers, dashboards, relays, and UX accelerators, must be designed to respect that boundary.