Contract Architecture
How Socket smart contracts work
- 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.solcontract 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-txendpoint or independently from the API. - The Registry decodes the
userRequestcallData and checks if aMiddlewareRequesthas 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
MiddlewareRequestis specified, the Registry will identify the DEX’sidand make a call to its Impl contract and initiate a swap. The swapped tokens are returned to the Registry. - Then, the Registry checks the
idof theBridgeRequestto 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.
Last modified 2mo ago