Overview
Every Sprinter credit position is tied to an on-chain account. Integrators need to decide which account type their users will use. This choice affects how delegation works, what permissions are possible, and how the end-user experience feels. There are two options: EOA (Externally Owned Account) — a regular wallet address, or Smart Account — a contract wallet with programmable permissions.| EOA + Operator | Smart Account | |
|---|---|---|
| Setup complexity | Low — user keeps existing wallet | Higher — user deploys or migrates to smart wallet |
| Delegation model | Operator contract draws to whitelisted receivers | Session keys with fine-grained permissions |
| Permission granularity | Receiver whitelist + operator-level constraints | Full control — amount caps, time limits, action types, co-sign |
| Custody model | Non-custodial (operator can’t touch collateral) | Fully non-custodial (user owns the contract) |
| Revocation | Time-delayed (prevents mid-settlement abuse) | Instant (session key revoked immediately) |
| Best for | Card programs, simple delegation, most integrations | Advanced use cases, multi-party access, tight on-chain guardrails |
EOA + Operator
The simplest path. Users keep their existing wallet (MetaMask, Rainbow, Coinbase Wallet, etc.) and interact with Sprinter directly. For delegated actions — where your app needs to act on the user’s behalf, like drawing credit at card swipe — you deploy an Operator contract that the user opts into. How it works:- User locks collateral from their existing wallet
- User calls
setOperator()to authorize your Operator contract - User calls
addCreditReceiver()to whitelist your settlement address - Your backend calls the Operator to draw credit — no user signature needed at transaction time
Smart Account
Users deploy a smart contract wallet (ERC-4337) with programmable session keys or modules. Your app is authorized via a session key that defines exactly what it can do — amount caps, time windows, action types. How it works:- User deploys a smart account (or your app provisions one during onboarding)
- User configures a session key authorizing your backend
- Session key defines permissions: which actions, how much, how often
- Your backend uses the session key to execute — user retains full custody
Which Should You Choose?
- Card Programs
- Wallets & Super Apps
- AI Agents
Recommended: EOA + OperatorCard programs typically have a simple delegation model — your backend draws USDC to a settlement address when the card is swiped. The
ExclusiveOperator contract handles this cleanly. Users don’t need to change their wallet setup, and the Operator’s receiver whitelist ensures funds can only go to your settlement address.Use Smart Accounts if you need per-user spending caps enforced on-chain, or if your users already have smart wallets.Related
Credit Operators
How operators work, existing operators, and how to build your own.
Credit Engine
Credit line creation, drawdowns, repayments, and liquidations.
Policy Engine
Fine-grained credit controls and guardrailed accounts.