TWC Audit, Trust Wallet Patterns & Zero-Fee Infrastructure Strategy
Goals: Use Trust Wallet Core (TWC) built-in gas-efficient and batch features instead of overwriting; achieve near-zero transaction fees; position as infrastructure core for liquidity, bridge, and provider layers (miniapp on Telegram).
Last updated: 2026-02-04
1. How Trust Wallet (App) Works — What We Can Reuse
1.1 Gas Optimization (Trust Wallet App)
| Feature | Description | Relevance for us |
|---|---|---|
| Automatic gas-efficient routing | Swap feature picks the most gas-efficient liquidity source per tx. | Use for DEX/swap layer: route through best path (1inch-style or internal aggregator). |
| Gas sponsorship | Trust Wallet can cover Ethereum fees (e.g. up to 4 gas-free swaps/day, $50 min, when user has 0 ETH). | We can sponsor via Paymaster (ERC-4337) or relayers for “zero fee” UX. |
| FlexGas | Pay gas with TWT, USDT, or USDC on BSC/Ethereum instead of native token. | Aligns with “pay fee in stablecoin”; we can offer same via Paymaster or meta-txs. |
| Multi-DEX distribution | Orders split across DEXs to reduce slippage and optimize execution. | Our swap/liquidity layer should aggregate DEXs and choose best route. |
1.2 Takeaway
Trust Wallet achieves low/zero fees and good UX through: (1) routing (gas-efficient + multi-DEX), (2) sponsorship (gas paid by app or Paymaster), (3) alternative fee payment (pay in USDT/USDC). We should mirror these in our stack: use TWC where it already supports these patterns, and add upper layers (aggregator, Paymaster, bridge) without duplicating low-level logic.
2. What We Have in TWC (Build) — Used vs Unused
2.1 TWC Proto (Ethereum) — In Our Repo
From packages/blockchain/twc/proto/Ethereum.proto and generated Go:
| Proto / enum | Purpose | We use it? |
|---|---|---|
| TransactionMode | Legacy, Enveloped (EIP-1559), UserOp (ERC-4337) | ✅ Enveloped (EIP-1559). ❌ UserOp not used. |
| Transaction.Transfer | Native ETH/BNB transfer | ✅ Via BuildEVMSigningInput. |
| Transaction.ERC20Transfer | ERC20 transfer | We use ContractGeneric + encoded transfer() instead of this dedicated type; same outcome. |
| Transaction.ContractGeneric | Generic contract call (amount + data) | ✅ Used for ERC20 and for multisend (we encode MultiSend contract call in data). |
| Transaction.Batch | Batched transaction for ERC-4337 wallets — repeated BatchedCall (address, amount, payload) |
❌ Not used. We do multisend via ContractGeneric to Gnosis MultiSend. |
| Transaction.ERC20Approve | approve(spender, amount) | ❌ Not used (we could use for one-time approve or permit flows). |
| SigningInput.user_operation | ERC-4337 UserOperation (entry_point, paymaster_and_data, etc.) | ❌ Not used. |
| UserOperation | Full ERC-4337: entry_point, init_code, sender, pre_verification_gas, verification_gas_limit, paymaster_and_data | ❌ Not used. |
2.2 TWC Sign Flow (What We Call)
We never call TWC with Transaction.Batch or UserOperation. We always:
- Build SigningInput in Go (evm_builder, tron_builder, ton_builder).
- Set Transaction to one of: Transfer, ContractGeneric (ERC20 or multisend).
- Call twc_any_signer_sign(inputData, coinType) once per tx.
So:
- Batch (proto): TWC’s
Transaction.Batchis for ERC-4337 smart contract wallets (batch of calls from one UserOp). It is not the same as “EOA + one MultiSend contract call.” Our current approach (EOA + ContractGeneric to MultiSend) is correct for EOA; we are not overwriting a “batch” path. To use TWC’s Batch we’d need to move to ERC-4337 (smart account + UserOp + optionally Paymaster). - UserOp + Paymaster: Would enable gasless UX (we or a partner pay via Paymaster). We have the proto; we don’t yet build or sign UserOperations.
2.3 What We Should Use From TWC (No Overwrite)
- EIP-1559 (Enveloped): Already used. Keep using; do not fall back to Legacy for normal flows.
- Transaction.ERC20Transfer: Optional: we could switch from ContractGeneric+encoded transfer to the dedicated ERC20Transfer type if TWC produces smaller or more optimal calldata; worth a quick test.
- Transaction.Batch + UserOperation: Use when we introduce ERC-4337 (smart contract wallets):
- One UserOp can contain a batch of calls (Batch + BatchedCall).
- paymaster_and_data in UserOperation → Paymaster pays gas → zero fee for user.
- TRON: We use native/TRC20 SigningInput; no TWC batch for TRON in proto. Our TRON savings come from energy rental (see GAS_AND_ENERGY_EFFICIENCY.md), not from a different TWC path.
- TON: TWC ton_builder has a TODO for multisend (highload wallet / multiple txs). We don’t overwrite; when we implement TON batch, do it via TWC’s intended pattern if documented.
2.4 Summary Table (TWC)
| Capability | In TWC? | We use? | Action |
|---|---|---|---|
| EIP-1559 | ✅ | ✅ | Keep. |
| ERC20 transfer | ✅ (Transfer + ContractGeneric) | ✅ | Optional: try ERC20Transfer type. |
| EOA multisend | Via ContractGeneric to MultiSend | ✅ | Keep; not overwriting Batch (Batch is for ERC-4337). |
| ERC-4337 Batch | ✅ Transaction.Batch | ❌ | Use when we add smart accounts. |
| ERC-4337 UserOp + Paymaster | ✅ UserOperation, paymaster_and_data | ❌ | Use for zero-fee layer. |
| TRON energy | N/A in TWC | N/A | We use rental (external API). |
3. New Methods: HD Wallets, Smart Wallets, DEX, CEX-Style
3.1 HD Wallets (Current) vs Smart Contract Wallets
- HD (EOA): We derive keys (BIP39/44), one address per user per chain. Simple, no on-chain account deployment. Gas: user (or we) pay per tx in native token.
- Smart contract wallets (ERC-4337):
- Batched execution: Multiple operations in one UserOp (e.g. approve + swap + transfer) → fewer txs, often lower total gas.
- Gas abstraction: Paymaster pays gas → zero fee for user; we can sponsor or use partner Paymasters (Pimlico, Alchemy, Candide, Circle, etc.).
- Flexible auth: Multisig, passkeys, social recovery.
Recommendation: Keep HD/EOA for deposits and hot wallet; add ERC-4337 optional path for “zero fee” withdrawals and swaps (UserOp + Batch + Paymaster). Use TWC’s Transaction.Batch and UserOperation when we implement that path.
3.2 DEX Handlers & Gas-Efficient Routing
- Aggregation: Route swap through best pool/aggregator (1inch, Paraswap, 0x, or our own router) to minimize gas and slippage.
- Batching: Where possible, batch multiple user swaps into fewer txs (e.g. via ERC-4337 Batch or internal settlement).
- Implementation: Our swap service can sit above TWC: TWC signs the tx (or UserOp); we compute route and calldata. No need to overwrite TWC; we add a “routing layer” that produces the same inputs we already sign.
3.3 CEX-Style Build (Fast Deposit / Withdrawal)
- Deposits: Already fast (watchers + confirmation threshold). Optional: L2/alternate chains for lower fees.
- Withdrawals: Batch (we have multisend for EVM); TRON energy rental (mandatory when little TRX); optional ERC-4337 + Paymaster for sponsored withdrawals.
- Liquidity in time: Internal balance (ledger) + on-chain settlement in batches → fewer on-chain txs, faster UX.
4. Strategic Goals: Zero Fees, Infrastructure, Miniapp
4.1 Goals (Aligned With Your Direction)
| Goal | How |
|---|---|
| Zero (or near-zero) transaction fees for users | Paymaster (ERC-4337) for EVM; TRON energy rental so we don’t burn TRX; optional gas sponsorship for swaps/withdrawals. |
| Competitors: swap everything, fast deposit/withdrawal | DEX aggregation + gas-efficient routing; batch withdrawals (multisend); fast confirmation and ledger updates. |
| Company as infrastructure core | TWC + our signers + watchers + ledger = core. Upper layers: liquidity provider, bridge, “everything to everything” via APIs and miniapp. |
| Liquidity in time, bridge, provider of everything | Core handles keys, signing, settlement; upper layers add: multi-DEX liquidity, cross-chain bridge, fiat ramps, and a single miniapp on Telegram. |
4.2 Layered View
┌─────────────────────────────────────────────────────────────────┐
│ Telegram Miniapp (swap, deposit, withdraw, bridge, liquidity) │
├─────────────────────────────────────────────────────────────────┤
│ Upper layers: DEX aggregation, bridge, Paymaster, liquidity API │
├─────────────────────────────────────────────────────────────────┤
│ Our core: Gateway, Wallet, Withdrawal, Swap, Ledger, Watchers │
├─────────────────────────────────────────────────────────────────┤
│ Signing & chains: TWC (EVM/TRON/TON) + tron energy rental │
└─────────────────────────────────────────────────────────────────┘
- Core: We already use TWC for sign; we should use only TWC’s intended paths (Enveloped, ContractGeneric, and when ready Batch + UserOp) and avoid reimplementing less gas-efficient logic.
- Upper layers: Add without replacing core: aggregator, Paymaster integration, bridge connectors, liquidity endpoints.
5. Implementation Checklist (High Level)
5.1 TWC (No Overwrite, Use What Exists)
- [ ] Confirm EIP-1559 used for all EVM txs (no Legacy unless fallback).
- [ ] Optional: Try TWC
Transaction.ERC20Transferfor simple ERC20 (vs ContractGeneric) and compare gas. - [ ] When adding ERC-4337: Use TWC
Transaction.Batch+SigningInput.user_operation+UserOperation.paymaster_and_datafor batched, gas-sponsored txs. Do not implement a parallel sign path that ignores these.
5.2 Zero / Low Fees
- [ ] TRON: Energy rental mandatory when we have little TRX (see GAS_AND_ENERGY_EFFICIENCY.md).
- [ ] EVM: Integrate Paymaster (e.g. Pimlico, Alchemy, Candide) for sponsored withdrawals/swaps; sign UserOp with TWC.
- [ ] FlexGas-style: Offer “pay fee in USDT/USDC” where supported (BSC/ETH via Paymaster or meta-tx).
5.3 DEX / Swap Layer
- [ ] Gas-efficient routing: Route swap through best DEX/aggregator (1inch/Paraswap/0x or own); output = calldata + target; TWC signs as today (or as UserOp when on ERC-4337).
- [ ] Multi-DEX: Split or route orders across DEXs to limit slippage; same signing layer.
5.4 Infrastructure / Product
- [ ] Fast deposit/withdrawal: Keep watchers + batch withdrawal; add L2 if needed.
- [ ] Bridge: Add bridge provider integration (e.g. Symbiosis, LayerZero, LI.FI) as an upper layer; core does sign + track.
- [ ] Miniapp: Single Telegram entry point for swap, deposit, withdraw, bridge, and future liquidity features.
6. References
- Trust Wallet: Gas fees, DEX swap.
- TWC: Our proto
packages/blockchain/twc/proto/Ethereum.proto(Transaction.Batch, UserOperation, TransactionMode). - ERC-4337: erc4337.io, Paymasters.
- Internal: GAS_AND_ENERGY_EFFICIENCY.md, technical-onboarding.md.