Best-route swaps across six aggregators, at production scale.
Process each user's swaps one at a time. Gaya Wallet quotes six aggregators in parallel to find the best route, then hands the winner to a per-user sequencer that executes inside a database transaction. Concurrency happens across users, never within one, which removes the race entirely.
Because no aggregator wins every pair. Routing quality varies by chain, by token and by size, and a wallet committed to a single aggregator quietly gives up value on every trade that aggregator is not best at.
The six are quoted in parallel, so the extra coverage costs latency roughly equal to the slowest responder rather than the sum of all six. The winner is chosen net of fees, gas and slippage, because a headline rate that ignores gas is not a real price.
The ordinary one: a user fires two swaps at almost the same moment and both read the same balance before either writes. Handled naively, the wallet spends money it does not have.
The fix is to make concurrency per-user rather than global. Swaps for one account are processed sequentially inside a database transaction, so the second sees the effect of the first. Different users still run fully in parallel, so throughput does not suffer.
They are the same problem with longer timescales. A bridge moves value between chains and a DCA schedule spends on a cron, and both touch the same balance the swap path does.
Putting all of them behind the same per-user sequencing means a scheduled buy and a manual swap cannot collide either.
Horizontally, on Kubernetes, autoscaling from one replica to ten. That works precisely because the ordering constraint is per-user rather than global, so the fleet can grow without any replica needing to know what another is doing for a different account.
This is the practical argument for scoping a lock as narrowly as the correctness requirement actually demands. A global lock would have been correct and unscalable.
Requests are HMAC-signed, rate limits apply per user and per IP, and privileged admin routes sit behind two-factor. A non-custodial wallet cannot lose keys, but the API around it is still worth hardening.
Notifications close the loop, pushing updates translated into nineteen languages so a user hears about a completed swap in their own.
A wallet backend serving 16+ chains with autoscaling from 1 to 10 replicas and push notifications translated into 19 languages.
| Chains | 16+ |
|---|---|
| Routing | Six DEX aggregators quoted in parallel |
| Selection | Best route net of fees, gas and slippage |
| Concurrency | Per-user sequencer inside a database transaction |
| Also settles | Cross-chain bridging, cron-driven DCA, payouts |
| Scaling | Kubernetes HPA, 1 to 10 replicas |
| API security | HMAC signing, per-user and per-IP rate limits, admin 2FA |
| Notifications | Push in 19 languages |
Scope the constraint as narrowly as correctness allows. Gaya Wallet sequences swaps per user inside a database transaction, so two concurrent requests from one account cannot both read a stale balance. Different users still execute in parallel, so the guarantee costs nothing in throughput.
Because routing quality varies by chain, token and trade size, and no single aggregator is best at everything. Quoting several in parallel and picking the winner net of fees and gas recovers value that a single-aggregator integration silently gives away on every trade.
The route that leaves the user with the most after costs, rather than the one advertising the best headline rate. A quote that ignores gas and aggregator fees can lose to a nominally worse rate, particularly on smaller trades where fixed costs dominate.
Yes, and that is the point of scoping it per user. Because no replica needs to coordinate with another about a different account, the fleet autoscales freely. A global lock would also be correct and would cap the whole system at one worker.
Rewards, referrals and payouts across four chains.