A wallet decision that looked sensible in 2024 can be an expensive mistake in 2026. Ethereum accounts can now delegate execution logic, while custody vendors offer increasingly complete signing and policy services. I would buy the signing and key-custody layer for most teams, then build the transaction policy and recovery process in-house. The exception is a company whose wallet infrastructure is itself the product.
Ethereum’s account changes weakened the case for building a signer first
Before Ethereum’s Pectra upgrade, a common argument for an in-house wallet stack was that externally owned accounts could not support enough application-specific behavior. That argument is weaker after EIP-7702, activated on Ethereum mainnet on May 7, 2025, according to the Ethereum Foundation’s published schedule. An EOA can authorize a delegation to contract code, allowing developers to design more flexible execution without first moving every user to a new smart-account address. Delegation does not remove the authority of the EOA’s underlying key, however, so it is not a substitute for protecting that key.
This changes a CTO’s procurement question. “Can we build account abstraction?” is too broad to guide a decision; “Who controls the signing key, the delegated implementation, and the policy that approves a transfer?” exposes the actual boundaries. ERC-4337 remains relevant for teams using UserOperations, bundlers, and paymasters, while EIP-7702 offers another route to account behavior. Neither protocol decides who can authorize a recovery, who pays when sponsorship fails, or how an incident commander stops withdrawals.
Older advice to choose one wallet architecture up front and hide it behind a generic “send transaction” API is now risky because that API obscures whether a request is an EOA transaction, an ERC-4337 UserOperation, or a delegated-account call. EIP-5792’s wallet_sendCalls can help represent batched calls where a wallet supports it, but wallet support and execution semantics must be checked rather than assumed. Put the operation type, chain identifier, expected signer, authorization method, and sponsorship decision into your internal request model. CAIP-2 chain identifiers can keep that model unambiguous when the same address appears on several networks.
Cryptocurrency APIs for Developers: Build Secure Wallets is a useful starting point for wallet design, but its title’s build-first implication should not settle the custody decision. A capable team can write a viem 2.x client in days; demonstrating that its signing service will withstand a compromised application credential, a mistaken policy change, and a regional outage is a different project. I would not build a production key-signing service merely to avoid a vendor bill, because that bill is usually easier to bound than the consequences of an untested recovery path.
Buy custody when it is a dependency; build it when control is the product
The explicit choice is between a managed custody and signing API and an in-house signer using infrastructure such as AWS KMS or an HSM. The managed option wins when a wallet supports another product: it buys an established operational surface for key creation, signing controls, and access management. Its costs are vendor fees, integration work, exit planning, and the risk that a provider’s outage or policy model constrains your releases. The in-house option wins when you need to own signing semantics across providers or can justify dedicated cryptography and operations staff. Its costs include key ceremonies, access reviews, secure deployment, monitoring, and incident exercises, not just code.
A cost comparison should price the same trust boundary on both sides. AWS KMS supports the ECC_SECG_P256K1 key specification used for Ethereum-compatible signatures, according to AWS documentation, but that feature alone is not a complete wallet policy engine. Your team still has to control who may call Sign, bind a signature request to an approved transaction, and prevent an application server from turning a broad signing permission into an unlimited withdrawal permission. Conversely, a managed provider is not automatically safe because it advertises multiparty computation: ask which actors can change policy, initiate recovery, or approve a destination, and test those answers in a sandbox.
Use a comparable workload before comparing quotes. For example, model 50,000 active wallets and 10,000 signing requests per day as planning assumptions to replace with your forecast, not as claims about a typical deployment. Request a quote for that workload, including recovery events, webhook delivery, additional environments, and support. Alongside it, estimate engineering time for an in-house service, security review, on-call coverage, and an annual recovery exercise. The cheaper API price is not decisive if exporting accounts or recreating policies during an exit requires work your team has not funded.
There is also a middle path worth stating precisely: buy key custody but own the approval policy outside the provider. A policy service can require a destination allowlist, a transaction simulation result, and a second approver before it requests a signature. Keep those decisions in an auditable store you control, then restrict the vendor credential so it cannot bypass them through an alternate endpoint. This arrangement wins when portability matters but key operations are not your differentiator; it costs an additional service and a careful review of every vendor permission. Do not describe it as “vendor-neutral” until you have run an exit test with another signer.
A successful API call no longer proves that the intended account will execute it
Integration advice used to concentrate on authenticating an API request, receiving a transaction hash, and watching for confirmation. That sequence misses an important question for delegated accounts: what code will the account use when the transaction executes? EIP-7702 delegation can change through an on-chain authorization, so an address classified once at onboarding cannot be treated as permanently unchanged. A transaction preview should record the chain, account state, target code, calldata, and block context; the approval service should recheck the facts it relies on immediately before submission.
The following viem 2.x script checks whether an Ethereum mainnet address currently exposes an EIP-7702 delegation indicator. Save it as check.mjs, run npm install viem@2, and set ETH_RPC_URL and WALLET_ADDRESS before running node check.mjs:
import { createPublicClient, http, isAddress } from 'viem';
import { mainnet } from 'viem/chains';
const address = process.env.WALLET_ADDRESS;
if (!address || !isAddress(address)) throw new Error('Set WALLET_ADDRESS');
const client = createPublicClient({
chain: mainnet, transport: http(process.env.ETH_RPC_URL)
});
const code = await client.getCode({ address });
const delegated = /^0xef0100[0-9a-f]{40}$/i.test(code ?? '');
console.log({ address, delegated,
implementation: delegated ? `0x${code.slice(8)}` : null });
This is an inspection aid, not an approval check: it reads current code but does not verify the implementation’s behavior, prove who authorized it, or guarantee the state at a later block. Where approval depends on a particular implementation, pin its address and reviewed code hash, simulate the proposed call against recent state, and fail closed if the delegation changes. Use a separate review for upgrades to that implementation. A passkey login under WebAuthn or a successful SIWE message under EIP-4361 proves something about authentication; neither, by itself, proves that the resulting transfer matches the user’s intent.
I would use Cryptocurrency APIs for Developers Secure Wallet Integration for integration vocabulary, not as evidence that an SDK settles this trust boundary. ERC-1271 contract signatures, WalletConnect v2 sessions, provider permissions under EIP-1193, and delegated-account execution all give an application different ways to receive an apparently valid approval. The policy service must specify which of those approvals is acceptable for each operation, because treating every “signature verified” result as equivalent makes recovery and high-value transfers harder to defend.
The procurement test should be an exit and incident exercise
Over the last two years, the operational question has also become harder to postpone. In the EU, MiCA’s crypto-asset service provider provisions began applying on December 30, 2024; whether they apply to a particular wallet business depends on its services and jurisdiction. DORA has applied since January 17, 2025, to covered financial entities and affects their management of ICT third-party risk. Neither rule means every wallet team needs the same licence or contract. Both make “we will document our provider dependencies later” poor advice for a covered operation, because the dependency determines who can act during a failure.
Before signing a custody contract, run a timed exercise rather than accepting a diagram. Give the vendor and your team a scenario in which a policy administrator is compromised while one signing region is unavailable. Set a test target of 30 minutes to disable new withdrawals; that is an internal target to tune against your risk, not a vendor performance claim. Record who has the authority to pause signing, how that authority is authenticated, and whether the action also blocks an attacker holding an existing API credential. Then restore service without quietly discarding the audit trail.
Run a second exercise in which the provider relationship ends. Export what is actually exportable, identify accounts that cannot migrate without user action, and reproduce transaction policy with a replacement signer. Safe contracts, OpenZeppelin Contracts 5.x components, and standard EVM transaction formats may improve portability, but none guarantees that a vendor’s recovery roles or off-chain approval history will transfer. Ask for the data format and procedure in the contract, because an undocumented promise of “easy migration” cannot be tested during procurement.
Finally, make the decision reversible where you can. Keep your application’s ledger, transaction intents, and policy decisions outside the signing provider, with identifiers that remain meaningful after a migration. Require receipts to link an approved intent to the exact signed payload and resulting on-chain transaction. This separation costs additional engineering now, but it lets the company change custody arrangements without rewriting the business rules that determine whether money may move.
Start with the failure you would otherwise delegate
Ask each shortlisted provider and your in-house team to demonstrate the same compromised-admin pause and account-exit exercise next week. Write down the authority, elapsed time, missing data, and manual steps for each attempt. Choose the option that leaves your team able to stop and explain a bad transfer—not the one whose SDK produces the first successful transaction hash.
