# Smart wallet multisig approvals Source: https://docs.settlemint.com/docs/developer-guides/api-integration/smart-wallet-approvals Create, inspect, and sign weighted multisig approvals for pending DALP smart wallet user operations. Smart wallet approvals coordinate pending account-abstraction user operations when one signer does not meet the wallet threshold alone. The approval record stores the user operation hash, the required cumulative signer weight, the current collected weight, lifecycle status, optional deadline, and each collected signature. This page is a reference for integration developers. For changing the threshold itself, see [Smart wallet multisig thresholds](/docs/developer-guides/api-integration/smart-wallet-thresholds). ## Prerequisites [#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 [#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: | Status | Meaning | | ----------- | ---------------------------------------------------------------------------------------- | | `pending` | The approval exists and still needs more signer weight, or it is waiting for submission. | | `submitted` | The collected weight met the threshold and DALP submitted the user operation. | | `executed` | The submitted user operation completed successfully. | | `expired` | The approval deadline passed before completion. | | `cancelled` | The approval was cancelled before completion. | | `failed` | Submission or execution failed. | ## Create an approval [#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. ```bash 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. ## List and read approvals [#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. | Field | Type | Description | | ------------------ | ----------------------- | ------------------------------------------------------------------------------------------------------- | | `id` | string | Approval record ID. | | `userOpHash` | string | User operation hash for the pending operation. | | `walletAddress` | Ethereum address | Smart wallet contract address. | | `chainId` | number | Chain ID for the approval. | | `organizationId` | string | Organization that owns the approval record. | | `initiatorAddress` | Ethereum address | Signer that created the approval. | | `threshold` | string | Required cumulative signer weight as a decimal string. | | `currentWeight` | string | Collected signer weight as a decimal string. | | `callData` | hex string | Encoded call data for the operation. | | `description` | string or null | Optional operation description. | | `status` | enum | Approval lifecycle status. | | `expiresAt` | ISO 8601 string or null | Optional approval deadline. | | `createdAt` | ISO 8601 string | Creation timestamp. | | `updatedAt` | ISO 8601 string | Last update timestamp. | | `signatures` | array | Collected signer signatures with signer address, signature bytes, signer weight, and signing timestamp. | ## Sign an approval [#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. ```bash 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. ## Operational notes [#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. * Do not ask co-signers to call owner-only wallet configuration endpoints directly. Route co-signer participation through the approval sign endpoint. ## Related [#related] * [Smart wallet API overview](/docs/developer-guides/api-integration/smart-wallets) * [Smart wallet multisig thresholds](/docs/developer-guides/api-integration/smart-wallet-thresholds) * [System paymasters](/docs/developer-guides/api-integration/system-paymasters) * [Bundler endpoint](/docs/developer-guides/api-integration/bundler)