Socket smart contracts are aggregators of DEXs, DEX aggregators & bridges. The key highlight of Socket’s smart contract architecture is that we choose modularity over upgradability. Once a module is deployed it can only be paused by the owner incase of bugs and nothing else, everything is immutable.
Users interact with Socket’s Registry.sol contract to initiate a bridging transaction.
Every DEX & Bridge has different functions to initiate actions. The Implementation contracts (Impls) act as a middleware to interact with the DEX/Bridge contract functions. Once a route is added to the registry, the route data is immutable and it points to addresses of respective DEX and Bridge Implementations.
No proxies, immutable modules, socket's modularity pattern doesn't add any additional trust assumptions
When a user makes a transaction, they send tokens to the Registry. They also send callData for the bridging route. This data can be generated from the /build-tx endpoint or independently from the API.
The Registry decodes the userRequest callData and checks if a MiddlewareRequest has been added in the callData. If there’s none, this implies the route doesn’t involve a swap and it can proceed directly to bridging.
If a MiddlewareRequest is specified, the Registry will identify the DEX’s id and make a call to its Impl contract and initiate a swap. The swapped tokens are returned to the Registry.
Then, the Registry checks the id of the BridgeRequest to identify which bridge the route utilises.
It then calls the Bridge Impl contract and initiates a bridging transaction with relevant function arguments decoded from the initial callData sent by the user. This initiates the bridging process and the user is expected to receive funds on the destination chain.