Stackup

• Name: Stackup
• URL: https://www.stackup.fi/
• Category: wallet-and-treasury-operations company / smart-account workflow operator / crypto finance-operations platform
• Tags: ethereum-ecosystem
• Summary: Stackup belongs as an entity note, not just a smart-account note. The useful question is who operates the hosted dashboard, passkey auth layer, API-key boundary, bank-connectivity workflow, and offchain access-configuration handling around the self-custodial accounts. Stackup says the accounts stay self-custodial, but the practical operating surface still lives in a named company that controls org auth, role policy, application access, compliance-gated fiat flows, and the default platform most teams will use to run treasury operations.
• What it does:
  • Provides a web platform and developer APIs for businesses to receive crypto payments, automate bill payments, manage shared wallets, and run treasury workflows
  • Uses self-custodial smart accounts based on Stackup’s keystore architecture, with passkeys, granular access controls, and configurable wallet policies rather than shared EOAs
  • Connects onchain treasury operations with offchain banking and fiat-conversion flows, including US bank connectivity and KYB-gated features
  • Operates a passwordless platform with org-level roles for admins, members, and API-key-backed applications
  • Stores and serves offchain access-configuration data for keystore accounts, with backup and export / verification flows described as part of the operating model
• Key claims:
  • The homepage now positions Stackup as crypto finance infrastructure for companies that want to get paid onchain, automate bill payments, and unify onchain and offchain treasury operations
  • The security docs say Stackup optimizes for self-custodial control, enterprise-grade protection, and simplified UX, while still operating the dashboard and APIs teams use to manage those accounts
  • The docs say access configuration is stored offchain in a Merkle-tree structure, treated as sensitive data, backed up daily, and exportable for independent verification against onchain commitments
  • The docs describe a platform authorization split between admins, members, and applications using API keys, making the company-run auth and role model part of the real control surface
  • The docs say some bank and ramp features require KYB for legal compliance and that Stackup operates on AWS infrastructure in the United States with encrypted-at-rest and encrypted-in-transit data handling
  • The smart-account guide says Stackup’s keystore accounts are purpose-built for shared multi-chain treasuries and that Stackup moved from earlier ERC-4337 infrastructure work toward a business wallet and finance platform
• Whitepaper: No separate company whitepaper is the key artifact here. The strongest primary materials are the official site, current security and smart-account docs, and the keystore architecture article plus specification.
• Sources:
  • https://www.stackup.fi/
  • https://docs.stackup.fi/docs/security-overview
  • https://docs.stackup.fi/docs/understanding-smart-accounts
  • https://www.stackup.fi/resources/stackup-keystore
  • https://github.com/stackup-wallet/keystore
  • https://github.com/stackup-wallet/keystore/blob/main/doc/spec.md

Internal linkages

• Project-layer alias: stackup.
• Best adjacent operator-boundary comparisons: turnkey, safe, crossmint, and parfin.
• Keystore-account comparison lens: safe for the more established smart-account substrate and privy for embedded-wallet workflow contrast.
• Reusable lens: when a company sells self-custodial treasury infrastructure, the real leverage often lives in org auth, approval workflow, banking integrations, policy defaults, and offchain account-configuration handling rather than only in the account contract.

Protocol / company boundary

• The keystore smart-account design is real and technically interesting, but the practical operating story is not just a new account abstraction primitive.
• Stackup runs the dashboard, passkey-authenticated operator surface, developer API boundary, org-role model, bank-connectivity workflow, and the offchain configuration handling that customers depend on to actually use the accounts day to day.
• That makes companies/stackup the more useful canonical note. The project-layer alias should mainly answer where is the deployed product and who runs the practical workflow?, not pretend there is a clean neutral protocol boundary doing most of the work here.

Control surface

• Practical leverage sits in organization onboarding, passkey and workspace authentication, admin-versus-member permissions, API-key issuance, wallet-policy configuration, compliance-gated fiat and bank features, and the hosted dashboard or API that users treat as their treasury control plane.

• An additional soft but important control surface is Stackup’s handling of offchain keystore-configuration data: the docs say it is sensitive, stored by Stackup, backed up daily, and exportable for independent verification. That does not make Stackup a custodian of customer funds, but it does mean availability, integrity, backup, and recovery workflow around configuration become part of the real operating trust boundary.

• The company also shapes which treasury actions feel normal or easy: invoice generation, payment batching, approval visibility, passkey recovery posture, bank transfers, and compliance reporting are all part of the product packaging rather than neutral protocol facts.

• Read Stackup as a company-run treasury and signer workflow control plane built on self-custodial smart accounts, not as only a keystore contract design.

• Last reviewed: 2026-08-06 UTC