ConsenSys Diligence and Socket partner for secure Socket Liquidity Layer smart contracts
While smart contract systems of today have the capability to be deployed with permissions, upgradeable proxies, and ways to add extra logic to them, the unique selling point of this technology has always been its ability to remain immutable and predictable after the initial deployment.
Systems with these properties can be used reliably by integrators with strong expectations that they will continue working as expected. From a smart contract security perspective, this allows users and builders to rest easy knowing that the code they are transacting with now will not change and surprise them.
Recently, the ConsenSys Diligence team partnered with Socket to conduct a security assessment of the Socket.tech aggregator smart contract system that leverages exactly these capabilities. The full audit report and details of the assessment can be found here https://consensys.io/diligence/audits/2023/02/socket/.
Socket Liquidity Layer smart contracts aim to make it easier for users to access multiple liquidity like bridges and DEXs for routing assets between chains that are tailored to their needs. It aggregates access to various bridges and DEXs into a single point of contact, the SocketGateway contract.
Smart Contract Architecture
SocketGateway acts as the central contract of the system, which serves as the touch point of all user interaction. It maintains a registry that maps module addresses in the Liquidity Layer to specific IDs.
The two main classes of modules are Routes and Controllers.
- Route: Smart contracts correspond to each bridge and DEX integration, containing the logic for interacting with them. For instance, there may be separate route smart contracts for 1inch, Hop, Across, and Refuel.
- Controller: Smart contracts that house the logic for coordinating cross-chain swaps via route smart contracts, such as cutting fees before bridging, or executing swap, bridge, and gas in a single transaction.
The SocketGateway contract delegates execution to these smart contracts as needed. For example, if a user requests a swap, bridge, and gas refill, the SocketGateway will call the appropriate Controller to execute the request by calling independent Routes such as 1inch for swapping, Hop for bridging and Refuel for gas.
Apart from this, there is a SocketDeployFactory that is responsible for the deployment of new route smart contracts and disabling any buggy ones.
The modules in the Socket Liquidity Layer are designed to be isolated from each other, which means:
- Each bridge or DEX integration, as well as more complicated features, are unique contract addresses and independent.
- Each module can be independently added and disabled via the SocketDeployFactory contract itself.
This gives integrating partners granular control over the available features and allows them to choose their preferred trade-offs. While also keeping bugs isolated from the overall system.
On the SocketGateway, each module contract address is associated with an immutable ID. Meaning,
- That once a module is registered with an ID, it can never be changed
- Any new modules can only be registered with a new ID
- The system can only disable buggy modules
This lets the users trust the system to work predictably for a given set of IDs and the module corresponding to that ID can not be upgraded.
Mapping all modules against specific IDs makes user-side verification of call data a straightforward process. Users can easily audit a group of modules and whitelist only those they trust, which reduces the reliance on Socket APIs for providing call data.
The Socket Liquidity Layer smart contracts were created to strike a balance between extensibility and immutability. After a thorough and productive audit conducted by ConsenSys Diligence, these smart contracts also provide top security.
Since each module can be added independently and verified with an ID that is immutable. Socket can continue to innovate on features via controller smart contracts and expand its reach by integrating new bridges via route smart contracts without disrupting the infrastructure integrators are currently using.
Once integrators have verified the new smart contracts, they can choose to enable the new features or bridges whenever they see fit, essentially giving them the best of both worlds with security embedded.