Smart wallet multisig approvals

Smart wallet approvals let an integration hold a smart wallet user operation until enough configured signer weight has approved it. The approval record stores the user operation hash, the call data to submit, the required weight, the collected weight, the lifecycle status, the optional deadline, and each collected signature.

This page is a reference for integration developers who already build smart wallet user operations. For changing the threshold itself, see Smart wallet multisig thresholds.

Prerequisites

Before creating or signing an approval:

• the authenticated participant must have an active organization
• the wallet must exist in the current system scope
• the wallet must have an installed weighted multisig validator
• the wallet must have a non-zero threshold configured
• the caller must sign as an active signer on that wallet
• the organization must have a provisioned bundler wallet for account-abstraction submission

Approval lifecycle

A multisig approval represents one pending user operation. You create the approval with the user operation hash and encoded call data. DALP records the initiator signature immediately, then stores the approval as pending unless the collected weight already meets the threshold.

Co-signers add signatures to the same approval. Each signature contributes the signer's configured weight. When the cumulative weight meets or exceeds the approval threshold, DALP marks the approval as submitted and submits the user operation automatically.

Approval statuses are:

Create an approval

POST /api/v2/smart-wallets/{address}/approvals

Create an approval when your integration has built a user operation and needs co-signer weight before DALP submits it.

curl -X POST "https://your-platform.example.com/api/v2/smart-wallets/0x1234567890AbcdEF1234567890aBcdef12345678/approvals" \
  -H "X-Api-Key: YOUR_DALP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "userOpHash": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "callData": "0xabcdef",
    "description": "Approve signer rotation for the treasury smart wallet",
    "expiresAt": "2026-06-01T12:00:00Z"
  }'

The userOpHash must be a 32-byte hex hash. DALP rebuilds the operation preview from the supplied call data and wallet state, then rejects the request if the supplied hash does not match that preview.

The threshold request field is optional. DALP reads the current on-chain threshold from the indexed wallet state when it starts the approval workflow.

Use orderingScope only when the operation needs explicit submission ordering. The default is wallet-level ordering. When you set orderingScope to group, you must also provide a non-empty orderingKey; DALP rejects an orderingKey for any other scope.

List and read approvals

Use the list endpoint to show pending approvals and approval history for a wallet:

GET /api/v2/smart-wallets/{address}/approvals

The list endpoint is paginated. It supports filtering by status, initiatorAddress, operationKind, createdAt, and expiresAt. It supports sorting by status, operationKind, createdAt, and expiresAt; the default sort is newest first by createdAt.

Use the read endpoint when you already know the user operation hash:

GET /api/v2/smart-wallets/{address}/approvals/{userOpHash}

Both endpoints return approval records with collected signatures.

List responses use the standard { data, meta, links } collection envelope. Single approval reads use { data, links }.

Sign an approval

POST /api/v2/smart-wallets/{address}/approvals/{userOpHash}/sign

A co-signer signs an existing approval with an empty request body. DALP resolves the caller's signing address from the authenticated participant, verifies that the caller is an active signer on the wallet, records the signature once, and adds the signer's weight to the approval.

curl -X POST "https://your-platform.example.com/api/v2/smart-wallets/0x1234567890AbcdEF1234567890aBcdef12345678/approvals/0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/sign" \
  -H "X-Api-Key: YOUR_DALP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

If the signer already submitted a signature for that approval, DALP does not add duplicate weight. If the approval is expired or no longer pending, the sign request is rejected instead of reopening the approval.

A submitted approval can still be signalled again while the platform continues the user operation submission. The sign endpoint returns the current approval record and does not create a second approval for the same hash.

Operational notes

• Read the wallet and signer list before creating approvals so your integration can display the current threshold and signer weights.
• Treat threshold and currentWeight as decimal strings because signer weights are integer values that can exceed JavaScript's safe number range.
• Store userOpHash as the approval lookup key. The read and sign endpoints use it in the path.
• Set expiresAt when the operation should not remain open indefinitely. Use an ISO 8601 date-time string.
• Use group ordering only for operations that must share a sequencing lane. For ordinary wallet operations, omit orderingScope and orderingKey.
• Do not ask co-signers to call owner-only wallet configuration endpoints directly. Route co-signer participation through the approval sign endpoint.

Related

• Smart wallet API overview
• Smart wallet multisig thresholds
• System paymasters
• Bundler endpoint