Most teams do not need to rebuild their product to make it chain-abstracted. They need to remove the chain boundary from a few journeys that matter, using building blocks that already exist. This is the order we work in.
1. Find where users hit a chain boundary
List every place a user sees "switch network", "bridge first", "insufficient gas" or a balance on the wrong chain. Look at where users abandon those flows. Two or three journeys usually account for most of the loss, and those are where to start.
2. Upgrade the account layer
Chain abstraction needs accounts that accept one signature for a multi-step outcome and let someone else pay gas. For new users, create embedded smart accounts (ERC-4337) at sign-up. For users with existing wallets, EIP-7702 lets their address take on smart-account behaviour. Add a paymaster so gas is sponsored or paid in a token the user holds.
3. Choose the intent and messaging layer
- Coverage of the chains and assets in your priority journeys.
- How many independent solvers fill on those routes, and at what speed and price.
- How fills are verified and solvers repaid, and the trust assumptions involved.
- Refund behaviour for intents that expire unfilled.
- Support for a shared standard such as ERC-7683, and the audit and incident record.
4. Build unified balances
Show one balance per asset by indexing every supported chain, and decide how to treat assets in flight. A balance that is wrong for a minute does more damage than a split one, so show when data is stale and reconcile continuously.
5. Design for failure states
- Intent not filled before the deadline: refund, with a clear message.
- Funds arrived, follow-up action failed: show the funds where they are and offer the next step.
- Messaging delayed: show progress honestly instead of a spinner with no end.
- Route paused by limits or monitoring: explain and offer an alternative.
6. Launch with limits
Cap the value per route and per user, monitor every flow, and have a tested way to pause a route. Raise limits as volume and confidence grow. Have the contracts you add — paymasters, resolvers, account modules — reviewed independently before they hold user funds.
Questions people ask
Do we need to migrate users to new wallets?
- Not necessarily. EIP-7702 lets existing wallet addresses gain smart-account features, and new users can get embedded smart accounts at sign-up.
Do we need our own solvers?
- Usually not. Integrating an established intent network gives you its solvers. Running your own makes sense only for unusual routes or assets.
Which chains should we support first?
- The ones your users already hold funds on. Your own analytics and wallet data will show where deposits come from.
Can Vayro do this for our app?
- Yes. We map the journeys, choose and integrate the building blocks, build the failure states and launch with limits.