Trustware: Why Apps Can't Just Accept Deposits Directly Into a Smart Contract
TL;DR: Most onchain apps can't simply let a user send funds straight to a contract, because the contract needs to know who sent what to issue the right receipt, shares, or accounting, and a plain transfer doesn't carry that information. Trustware's smart-account module handles this with Permit2-based signed transfers and an ERC-4337 paymaster, so a deposit and its accounting happen atomically instead of requiring a separate approve-then-deposit dance from the user.
What is the smart contract deposit problem?
The smart contract deposit problem is that a contract receiving a plain asset transfer has no reliable way to know who sent it or why, which breaks accounting for anything that needs to issue a receipt token, credit a balance, or track a position. This is the same friction users hit as the "AAVE problem": depositing into a lending pool or vault isn't a simple transfer, it requires a specific method call so the contract can mint or credit the right receipt back to the right address.
Why a plain transfer doesn't work
If a user sends a token directly to a contract address without calling the contract's intended deposit function, the contract has no built-in way to associate that transfer with an action, there's no data attached telling it whose balance to credit or what receipt to issue. Apps solve this today by requiring a separate approval transaction followed by a deposit call, two signatures and two transactions for something that conceptually should be one action.
How Trustware's smart-account module addresses this
Signed transfers instead of a separate approval step
Trustware's smart-account module uses Permit2, a signature-based transfer standard, to authorize a specific transfer with a single signed message rather than a separate onchain approval transaction. The signature carries the transfer details directly, removing the two-transaction approve-then-deposit pattern for the cases it covers.
An ERC-4337 paymaster for gas and execution
The smart-account client is built on Account Kit's light account infrastructure with a custom paymaster contract, handling gas sponsorship and execution as part of the same flow rather than requiring the user to separately hold and spend gas on top of the deposit itself.
What this changes for accounting
Because the transfer and the destination action can be resolved together, a receipt token or balance credit can be tied to the correct sender within the same flow, rather than depending on a separate deposit call the user has to know to make after their tokens arrive.
The Trustware view, this is a UX problem wearing a blockchain costume
The underlying issue isn't that smart contracts are bad at accounting, it's that a plain transfer carries no context, and fixing that at the application layer usually means asking users to complete two separate steps in the right order. Solving it at the infrastructure layer means the app doesn't have to explain a two-step dance to every user who's never done it before.
A contrarian take, "just call the deposit function" undersells how often this actually breaks
It's easy to say the fix is simple, don't transfer directly, call the deposit method. In practice, users copy addresses from other apps, wallets auto-suggest a plain send, and support tickets from stuck deposits are common enough that this is treated as a known category of user error, not an edge case.
What to check before assuming your deposit flow handles this correctly
- Does your current flow require a separate approval transaction before the actual deposit, and do users understand why?
- What happens today if a user sends funds directly to your contract address instead of using your app's deposit flow?
- Does your accounting depend on the sender address being attached to the transfer, and is that guaranteed by your current method?
- Would a signature-based transfer standard reduce the steps your users have to complete correctly, in order?
- Is gas sponsorship or abstraction part of your deposit flow, or does the user need to separately hold gas on top of the deposit asset?
See the Trustware docs for current smart-account implementation details.
FAQ
Why can't a user just send tokens directly to a vault or lending contract?
Because a plain transfer carries no data telling the contract whose balance to credit or what receipt to issue, breaking the accounting most vaults and lending pools depend on.
What is Permit2, and how does it help with deposits?
Permit2 is a signature-based transfer standard that authorizes a specific transfer through an off-chain signature rather than a separate onchain approval transaction, reducing the deposit flow to fewer steps.
Does Trustware's smart-account module require the user to hold gas separately?
The module is built on an ERC-4337 paymaster architecture designed to handle gas as part of the sponsored transaction flow rather than requiring the user to separately manage gas.
Is this the same thing as the "AAVE problem"?
Yes, it's the same underlying issue, that depositing into contracts like lending pools requires a specific method call rather than a plain transfer, described under a common shorthand name.
Does this affect every kind of smart contract deposit?
{{CITE: confirm current scope of contracts/use cases the smart-account module supports before publishing}}
Is the smart-account flow non-custodial?
Yes, the signed-transfer and paymaster model is designed to execute the user's authorized transfer directly rather than routing funds through an intermediary-held account.
How to decide if this applies to your app
If your deposit flow currently requires users to approve, then separately deposit, or if support tickets mention funds sent directly to a contract address, this is a live problem for you, not a theoretical one. A signature-based transfer model with sponsored gas removes the specific steps most likely to go wrong.
See trustware.io for current implementation options.