# Smart wallet integration walkthrough Source: https://docs.settlemint.com/docs/developers/api-integration/wallets/smart-wallet-integration-walkthrough A step-by-step tutorial that takes you from confirming account abstraction is active to submitting your first transaction through a participant's smart wallet. By the end of this tutorial you will have confirmed account abstraction is enabled for your deployment, provisioned a participant's smart wallet (which deploys it fully on-chain), verified gas readiness, and submitted a transaction that routes through the smart wallet. Each step produces a visible API response so you can confirm the system is working before moving to the next. The single most important thing to carry forward: provisioning a smart wallet via `POST /api/v2/smart-wallets` completes the full deployment workflow — predicting the address, deploying the contract on-chain, adding the management key, and registering the identity. The wallet address returned is live and ready to use for executor selection, gas checks, and every subsequent operation. **Prerequisite:** account abstraction is enabled for your DALP deployment and you have a valid API key (`X-Api-Key` or equivalent credential). The organization's AA flag must be on before participant smart wallets can be provisioned. ## Step 1. Discover the EntryPoint and confirm your organisation has AA enabled [#step-1-discover-the-entrypoint-and-confirm-your-organisation-has-aa-enabled] Two distinct conditions must both be true before participant smart wallets can be provisioned: the platform must have an EntryPoint registered in the directory, and account abstraction must be enabled for your specific organisation. This step checks both. **1a. Discover the platform EntryPoint address** The bundler discovery endpoint returns the active chain ID and the EntryPoint address registered at the platform level. ```bash curl --request POST "$DALP_API_URL/api/v2/bundler" \ --header "Content-Type: application/json" \ --header "X-Api-Key: $DALP_API_TOKEN" \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "eth_supportedEntryPoints", "params": [] }' ``` A successful response contains a `result` array with one EntryPoint address. Note that address — dependent tooling (ERC-4337 SDKs, off-chain signing flows) uses it to construct `PackedUserOperation` structs. If the `result` array is empty or the endpoint returns an error, the platform has no EntryPoint configured and you cannot continue until the operator registers one. > **Important:** a non-empty `result` here confirms only that the platform-level EntryPoint is registered. It does not mean account abstraction is enabled for your organisation. `eth_supportedEntryPoints` reads from the on-chain directory and has no visibility into per-organisation settings. **1b. Confirm your organisation has advanced accounts enabled** A successful bundler response is necessary but not sufficient. Account abstraction must also be enabled for your organisation. Confirm this through the operator platform settings for your organisation before proceeding. If you are unsure, attempt Step 2 and check whether the response returns an AA-not-enabled error — that error is the authoritative signal that the org-level setting is off. See the exact response shape and the `eth_chainId` method in [Bundler discovery](/docs/developers/api-integration/wallets/bundler). ## Step 2. Read or provision the participant's smart wallet [#step-2-read-or-provision-the-participants-smart-wallet] Every participant in an AA-enabled organization has exactly one smart wallet in DALP. Call the smart wallets endpoint for the participant. If no smart wallet exists yet, DALP runs the full provisioning workflow: it predicts the CREATE2 address, deploys the wallet contract on-chain, adds the smart wallet as a management key on the participant's identity, and registers it in the identity registry. The returned address is the live, deployed wallet address. ```bash curl --request POST "$DALP_API_URL/api/v2/smart-wallets" \ --header "Content-Type: application/json" \ --header "X-Api-Key: $DALP_API_TOKEN" \ --header "X-Participant: $PARTICIPANT_ID" \ --data '{}' ``` > For the exact request body fields (validator type, initial signers, description), refer to the request shape in [Smart wallets](/docs/developers/api-integration/wallets/smart-wallets). The response includes the wallet `address`. This is the address you use for all subsequent work. Store it. DALP is idempotent: calling this endpoint again for the same participant returns the existing wallet address without re-running the provisioning workflow. ## Step 3. (Optional) Configure a weighted multisig threshold [#step-3-optional-configure-a-weighted-multisig-threshold] This step only applies if the wallet in Step 2 was created with a multisig validator — that is, if the `POST /api/v2/smart-wallets` request included multisig signers and a threshold in the request body rather than an empty `{}`. The threshold endpoint searches for an installed MultisigWeightedValidator and returns an error if one is not present. A wallet created with the default ECDSA validator (body `{}`) does not have this module installed and cannot use this endpoint. To provision a multisig wallet from the start, pass the multisig signers and threshold in the Step 2 `POST` body instead of `{}`. See the request body fields in [Smart wallets](/docs/developers/api-integration/wallets/smart-wallets) for the exact shape. If the wallet was created with multisig config, you can update the threshold at any time before submitting transactions through the wallet: ```bash curl --request PUT \ "$DALP_API_URL/api/v2/smart-wallets/$SMART_WALLET_ADDRESS/threshold" \ --header "Content-Type: application/json" \ --header "X-Api-Key: $DALP_API_TOKEN" \ --header "Prefer: respond-async" \ --data '{"threshold": "2"}' ``` > For the exact `threshold` field constraints and the async response shape, see [Smart wallet thresholds](/docs/developers/api-integration/wallets/smart-wallet-thresholds). For adding co-signers and coordinating their approvals on pending operations, see [Smart wallet approvals](/docs/developers/api-integration/wallets/smart-wallet-approvals). If you are setting up a single-signer wallet (default ECDSA), skip ahead to Step 4. ## Step 4. Check gas readiness before transacting [#step-4-check-gas-readiness-before-transacting] Before sending your first transaction, confirm the smart wallet has gas coverage. DALP uses paymasters to sponsor UserOperation gas. If sponsorship is missing and the wallet has no native balance, the operation fails at submission. The gas-status endpoint reports the wallet balance, whether a sponsorship paymaster is available for the wallet's system, and whether the chain is configured as zero-gas. It is the single check for readiness: ```bash curl "$DALP_API_URL/api/v2/smart-wallets/$SMART_WALLET_ADDRESS/gas-status" \ --header "X-Api-Key: $DALP_API_TOKEN" ``` > See [Smart wallets](/docs/developers/api-integration/wallets/smart-wallets) for the gas-status response fields, and [Account native balances](/docs/developers/api-integration/wallets/account-native-balances) if you also need the indexed balance with `nativeBalanceObservedAtBlock` for freshness evidence. If your deployment relies on sponsorship, also confirm the system paymaster deposit is funded. A low deposit means sponsorship will be unavailable for future operations. > See [System paymasters](/docs/developers/api-integration/wallets/system-paymasters) for deposit and sponsorship status endpoints. When gas status reports a paymaster is available or the wallet holds enough native balance, you are ready to submit. ## Step 5. Submit your first transaction through the smart wallet [#step-5-submit-your-first-transaction-through-the-smart-wallet] Now route a real transaction through the smart wallet. The key is the `X-Executor: smart-wallet` request header. Without it, DALP uses the organization's default executor policy. With it, DALP forces smart-wallet execution for this request. Because the wallet was fully deployed in Step 2, DALP routes this UserOp through the already-deployed contract with no additional deployment overhead. The example below shows the header pattern. The actual endpoint and body depend on the operation you are performing (token transfer, claim issuance, and so on). Apply the same headers to any mutating API call: ```bash curl --request POST "$DALP_API_URL/api/v2/" \ --header "Content-Type: application/json" \ --header "X-Api-Key: $DALP_API_TOKEN" \ --header "X-Participant: $PARTICIPANT_ID" \ --header "X-Executor: smart-wallet" \ --header "Prefer: respond-async" \ --data '{ ... }' ``` > For the full `X-Participant` and `X-Executor` contract and the rules around valid values, see the executor selection section in [Smart wallets](/docs/developers/api-integration/wallets/smart-wallets). DALP accepts the request, queues a transaction through the AA execution path, and returns an accepted async response with a status URL. Persist the status URL. Refer to the reference page for the exact response fields. ## Step 6. Poll the status URL and observe the result [#step-6-poll-the-status-url-and-observe-the-result] After submitting, poll the `statusUrl` from the accepted response. The operation is asynchronous: the UserOp moves through the bundler, the EntryPoint executes it, and the indexer confirms the result before DALP marks it complete. ```bash curl "$STATUS_URL" \ --header "X-Api-Key: $DALP_API_TOKEN" ``` When the status transitions to `completed`, the response includes the on-chain transaction hash. At that point: * the operation you submitted has been executed through the smart wallet * subsequent calls with `X-Executor: smart-wallet` for this participant continue routing through the deployed wallet If the status shows a failure, the status response describes the rejection reason (refer to the reference page for the exact field). Common causes are an insufficient paymaster deposit, a threshold that was not met, or a validator module rejecting the signer set. ## What you built [#what-you-built] You have completed the full smart wallet integration path: 1. Confirmed AA is active for the deployment and discovered the active EntryPoint. 2. Provisioned the participant's smart wallet — deployed on-chain with management key and identity registration — and stored the wallet address. 3. (Optionally) configured a multisig threshold on the already-deployed wallet before submitting any transactions. 4. Verified gas readiness through the native-balance and paymaster endpoints. 5. Submitted a transaction with `X-Executor: smart-wallet`, routing it through the deployed wallet. 6. Polled the status URL and confirmed the transaction completed. ## Where to go next [#where-to-go-next] * [Smart wallets](/docs/developers/api-integration/wallets/smart-wallets) - full endpoint reference for listing wallets, managing validators and signers, and reading gas status. * [Smart wallet approvals](/docs/developers/api-integration/wallets/smart-wallet-approvals) - how co-signers review and approve pending operations on a multisig wallet. * [Smart wallet thresholds](/docs/developers/api-integration/wallets/smart-wallet-thresholds) - update threshold values on an already-deployed wallet. * [System paymasters](/docs/developers/api-integration/wallets/system-paymasters) - monitor and top up paymaster deposits to keep gas sponsorship available. * [Account native balances](/docs/developers/api-integration/wallets/account-native-balances) - read indexed gas balances for any platform account. * [Bundler discovery](/docs/developers/api-integration/wallets/bundler) - `eth_chainId` and `eth_supportedEntryPoints` reference.