2026-08-03
Bridging is a rough spot for crypto tax tools generically, and it's worth being specific about why: a bridge isn't one on-chain event, it's two, minutes apart, on two different chains, sent from an address that usually isn't even the one that receives the funds on the other side. Nothing about either half looks like a matched pair unless you already know to associate them.
We added Synapse's bridge on both Ethereum and Base. It splits cleanly into two directions, each with its own pair of events:
bridge_deposit - either a TokenDeposit
(bridging a token Synapse holds directly) or a TokenRedeem (burning a
Synapse-wrapped token to bridge it back). Both decode the token and amount
straight from the event args.bridge_fill - either a TokenMint
(receiving a Synapse-wrapped version of the asset) or a TokenWithdraw
(receiving the underlying token directly from the bridge's reserves).That's four distinct events collapsing into two categories, which is the useful part: whether your funds left as a redeem or a deposit, or arrived as a mint or a withdraw, mostly depends on which specific asset and route Synapse used under the hood, not on what you did. What matters for your records is the direction - money left this chain, money arrived on that one - and that's what the category reflects.
One thing we didn't try to do: stitch the two legs of a single bridge together into one combined event. Each leg decodes independently, correctly, on its own chain, from its own transaction. Matching them into a single logical transfer means correlating across two separate chains' transaction histories by amount, token, and rough timing - a real feature, but a different and harder problem than classifying what a given transaction did, and one we'd rather build deliberately later than bolt on as a guess now.
Same disclaimer as always: this labels what happened - a deposit leg or a fill leg, on which chain - it doesn't tell you what it means for your taxes.