During the hackathon, I’m building a live balance tracking service to make it easier and faster to display and update balances for CoW Protocol users.
Overview
The system works as follows:
-
Subscription
- Users subscribe to an SSE endpoint to track balances and allowances.
- The client provides:
walletAddress, chainId, tokenAddresses.
- Eventually,
tokenAddresses will be replaced by tokenLists and walletAddresses.
-
Instant Initial Data
- The endpoint responds immediately with
initial_balances using cached data.
-
Ongoing Tracking
- The server monitors balances and allowances for the requested tokens.
- Any changes are pushed in real time:
- Balance changes: include the token, old balance, and new balance.
- Allowance changes: include the token, old allowance, and new allowance.
-
Persistent Connection
- The server keeps the SSE connection open, periodically sending PINGs.
- If the client misses a PING, it closes the connection and stops tracking.
-
Graceful Shutdown
- If the user closes the window/connection, the server detects it and stops tracking.
Why This Matters
- Better UX: Balances are always fresh and load instantly
- Efficiency: Significantly reduces node calls
- Infrastructure for Notifications: Cached balances/allowances enable advanced alerts (e.g., when an order becomes UNFILLABLE due to balance/allowance changes)
- Lightweight Clients: Less polling means reduced CPU/battery usage, especially on mobile
- Faster Feedback: Immediate updates remove the polling delay currently present when trading or receiving funds
Plan & Related PRs
Initial Scope
Future Improvements
Misc
Teaser
This is a teaser of what these PRs add

During the hackathon, I’m building a live balance tracking service to make it easier and faster to display and update balances for CoW Protocol users.
Overview
The system works as follows:
Subscription
walletAddress,chainId,tokenAddresses.tokenAddresseswill be replaced bytokenListsandwalletAddresses.Instant Initial Data
initial_balancesusing cached data.Ongoing Tracking
Persistent Connection
Graceful Shutdown
Why This Matters
Plan & Related PRs
Initial Scope
Future Improvements
tokenListsandwalletAddressesto token addresses, reducing required arguments. Users will mostly pass a list instead of individual tokens, leveraging cached mappingsstartTrackingUserin the tracking service, so its resilient to repository failures or broadcasting failures.UserBalanceRepository(like using Moralis)broadcastToUserexposed in the service layer. I just left it for convenience, but probably better to only define very specific methods like the ones we have for notification of balance changes.POLLING_INTERVAL_MSto fit our needs. We could also consider having ways to query more often some tokens than others, similarly to what we do in the UI.Misc
Teaser
This is a teaser of what these PRs add