Omnichain
When we started Aarc, crypto applications and user funds were spread across different networks. A user often had to bridge funds before using an application on another chain.
Our first product joined those steps. It let an application accept funds from another chain and route them into the contract the user wanted to use. The aim was not only to transfer an asset. It was to complete the deposit that came after the transfer.
That required more than one route. The system had to account for the source network, destination network, token, bridge or liquidity path, and the call to the destination contract. We also built the ordinary parts around it: an API, documentation, a dashboard, and support for teams doing the integration.
The word “omnichain” was broad. It could describe the same application deployed on many chains, or an application that could use funds from many chains. These are not the same thing. Deploying code in more places does not by itself join the liquidity or remove the steps a user has to take.
Aarc later moved from application deposits toward fund infrastructure. The earlier product and the later one share some plumbing: assets have to move between systems and arrive in the place where they can be used. The customer and the operating requirements changed. The movement of money remained.