Sonic V2.2 just dropped a pattern that kills multi-sig hell for complex onchain flows.
The Problem:
Why tf do you sign 5 times for a 5-step operation? You authorized the outcome when you clicked the button. Everything after is the system begging for permission on steps you never chose individually.
The Delegate Pattern:
1. App spins up a throwaway account (delegate key)
2. You sign ONCE to send funds to delegate
3. Delegate executes the entire flow (swaps, purchases, deposits)
4. Final txs send results back to your wallet
5. All wrapped in one atomic bundle
If anything fails, entire sequence rolls back. Your funds never moved.
Real Example:
You want 5 NFTs at $20 each. All or nothing.
Old way: 5 signatures
New way: 1 signature for $100 transfer → delegate buys all 5 → transfers them back
11 transactions, 1 user signature
Why It's Safe:
Your signed tx includes the hash of the ENTIRE execution plan. If the app changes ANY step, your signature becomes invalid. You're not trusting behavior, you're signing a cryptographic commitment.
Delegate key is fresh per operation, gets discarded after. Nothing to steal, nothing to exploit.
Where It Works:
- Token ops (batch swaps, multi-hop routing, yield harvesting)
- NFT batch purchases/listings
- Multi-asset portfolio rebalances
Where It Doesn't:
Protocols that assign ownership based on msg.sender (lending positions, LP positions, staking). Delegate creates the position, gets discarded, position is orphaned.
Fix: Either use protocols with "on behalf of" parameters, or fall back to standard multi-sign bundles (still atomic, just more signatures).
Bottom line: For any workflow that produces transferable assets, you just went from N signatures to 1 signature.
For position-creating flows, standard bundles still give you atomicity.
Sonic V2.2 isn't asking permission anymore. It's executing intent.
The Problem:
Why tf do you sign 5 times for a 5-step operation? You authorized the outcome when you clicked the button. Everything after is the system begging for permission on steps you never chose individually.
The Delegate Pattern:
1. App spins up a throwaway account (delegate key)
2. You sign ONCE to send funds to delegate
3. Delegate executes the entire flow (swaps, purchases, deposits)
4. Final txs send results back to your wallet
5. All wrapped in one atomic bundle
If anything fails, entire sequence rolls back. Your funds never moved.
Real Example:
You want 5 NFTs at $20 each. All or nothing.
Old way: 5 signatures
New way: 1 signature for $100 transfer → delegate buys all 5 → transfers them back
11 transactions, 1 user signature
Why It's Safe:
Your signed tx includes the hash of the ENTIRE execution plan. If the app changes ANY step, your signature becomes invalid. You're not trusting behavior, you're signing a cryptographic commitment.
Delegate key is fresh per operation, gets discarded after. Nothing to steal, nothing to exploit.
Where It Works:
- Token ops (batch swaps, multi-hop routing, yield harvesting)
- NFT batch purchases/listings
- Multi-asset portfolio rebalances
Where It Doesn't:
Protocols that assign ownership based on msg.sender (lending positions, LP positions, staking). Delegate creates the position, gets discarded, position is orphaned.
Fix: Either use protocols with "on behalf of" parameters, or fall back to standard multi-sign bundles (still atomic, just more signatures).
Bottom line: For any workflow that produces transferable assets, you just went from N signatures to 1 signature.
For position-creating flows, standard bundles still give you atomicity.
Sonic V2.2 isn't asking permission anymore. It's executing intent.