Engineering the multichain app

We recently upgraded the Splits app from multichain-optional to multichain-first. Will Collier from Decent asked what the engineering lift looked like, so Splits teammate Mike Howard jotted down a few notes on the process that we’re sharing today.

Before times#

The app was siloed by network, which wasn’t an ideal user experience. Say you wanted to look at Optimism — you couldn’t simultaneously see your Splits activity from Ethereum mainnet. Once you selected a network, everything in the app operated within it. As Abram explained in the multichain announcement:

L2s are not an afterthought; increasingly, they are the default for the builders and creators who use Splits. The problem is that as L2 activity grows, people struggle to get the full picture of their earnings across all these networks.

We had a separate subgraph that indexed events for each network, and depending on the network selected in the app we queried one of those subgraphs. The subgraphs were identical (although with different data for each network), so the queries were identical and just the data loaded was different.

Happier future#

Once we decided to change the app experience, the challenge was reorganizing data in our client. We wanted to unify the view for users, so they would see a single number for their total balance across all networks (among other aspects). But we still had to manage data separately by network behind the scenes, since users can only perform a transaction on one network at a time — they have to withdraw funds from Base, Optimism, etc. separately.

Our task was figuring out the right storage and display for this information. Here’s what we came up with: We still have one subgraph per network, but now we never query them directly. Data from each subgraph gets piped to a database we control. Our own GraphQL API is layered on top of this database. We can query all the same subgraph data as before, but we can do so across multiple networks in a single query.

Step by step:

• Goldsky subgraphs index event data for all of our contracts. We run one subgraph on each network we want to support in our app.
• Goldsky’s mirror feature takes the data from each of those subgraphs and pipes it to our own database, which we manage.
• We are using AWS Aurora for our database. It automatically handles scaling up and down for us as more or less data is written, and more or less data is being read by the app’s users.
• We run our own GraphQL API (using Apollo Server and AWS ECS) on top of the database.

The Splits application can now query our GraphQL API and fetch all the same data as before, only now it can do so in a single request instead of having to query multiple subgraphs. It’s much simpler to fetch all the Splits across all networks that your wallet controls, is a recipient of, etc. We’ll be updating our SDK to use this new GraphQL API as well. Users can generate an API key through our app to get access. (If that sounds exciting, get in touch!)

The most substantial changes were to the backend, so that’s the primary focus of this post, but of course the frontend was impacted as well. Our frontend architecture largely remained the same; we’re still using Redux for state management. But instead of storing account data just by address — {address: data...} — we store it per-chain as well — {chain: {address: data...}}.

Testnet mode#

Debugging and dry runs are crucial to ensure any system is working as intended, so we felt that testnet support was a must. After all, we need it ourselves.

By default the Splits app only shows mainnets, but you can toggle into testnet mode (go to Settings). With the multichain view it was important to keep testnet data, balances, etc. separate from legitimate funds.

Devs, if there’s anything else we can do to improve your experience, reach out via Farcaster or Discord 🫡

We’re excited to keep building financial infrastructure for onchain teams and creators. Making it simple and easy to see what’s happening across various networks is important. The reality today and going forward is that people use several different chains to suit their various purposes. As heavy users of the Splits app, the improvement is tangible to us, and we hope it will be to you too.