DOT Diagram

DOT Diagram of Lighting Cat

The DOT diagram of Salus Lightning Cat is used to display all the smart contracts included in the entire contract project, the inheritance relationships between contracts, the functions and variables in each smart contract, and their visibility.The DOT diagram of Lightning Cat can assist developers and auditors in gaining a better understanding of the structure and logic of smart contracts, thereby improving the efficiency of smart contract security audits.

Analyzing DOT Diagram

Using the example of Uniswap's SwapRouter, the DOT diagram generated by our Lighting Cat tool is displayed as follows. You can see many rectangular boxes and arrows.

From this DOT diagram, it is evident that the SwapRouter project comprises a total of 34 contracts. Each rectangular box represents a contract, such as IERC20Permit, IWETH9, IUniswap V3Pool, SwapRouter, and LowGasSafeMath, among others.

What is rectangular boxes？

Each rectangular box in the DOT diagram lists the contract name, functions, variables, and their visibility for each contract. For example, the SwapRouter contract includes five public functions, three private functions, and two private variables.

Regarding functions, let's take the example of the uniswapV3SwapCallback(int256,int256,bytes) function. "uniswapV3SwapCallback" represents the function name, and "int256,int256,bytes" represents the three input parameter data types of the function, namely int256, int256, and bytes, in that order. On the other hand, the exactInputSingle function takes a structured data type called ISwapRouter.ExactInputSingleParams as an input, which is defined within the contract, unlike basic data types such as uint256.

As for variables, the DOT diagram showcases the variable names, such as DEFAULT_AMOUNT_IN_CACHED and amountInCached.

What is arrows？

The arrows between two rectangular boxes in the DOT diagram represent the inheritance relationship between the two contracts. Due to the large size of the Uniswap SwapRouter contract project and the complexity of the inheritance relationships between contracts, we will focus on explaining selected key points.

As shown in the diagram below, the SwapRouter contract inherits from six contracts. The LowGasSafeMath contract neither inherits from any contract nor is inherited by any other contract. The PeripheryPaymentsWithFee contract, inherited by the SwapRouter contract, inherits from two contracts: the PeripheryPayments contract and the IPeripheryPaymentsWithFee contract, and both of these contracts inherit from the IPeripheryPayments contract. Both the PeripheryPayments contract and the SwapRouter contract inherit from the PeripheryImmutableState contract. The PeripheryImmutableState contract, in turn, inherits from the IPeripheryImmutableState contract.

In the rectangular box representing the PeripheryPaymentsWithFee contract, there is another rectangular box under the "Public Functions" section that displays the following:

● 'unwrapWETH9(uint256,address)' collides in inherited contracts IPeripheryPayments, PeripheryPayments where PeripheryPayments is chosen.

● 'refundETH()' collides in inherited contracts IPeripheryPayments, PeripheryPayments where PeripheryPayments is chosen.

● 'sweepToken(address,uint256,address)' collides in inherited contracts IPeripheryPayments, PeripheryPayments where PeripheryPayments is chosen.

The reason for this collision is that IPeripheryPayments is the interface contract for PeripheryPayments. An interface contract is a contract used to define function signatures without implementing them. The PeripheryPayments contract inherits from the IPeripheryPayments contract and implements the unwrapWETH9, sweepToken, and refundETH functions.

When a function conflicts in two inherited contracts, our Lightning Cat's DOT diagram can also indicate that the functionality of this function will be executed based on the implementation of the inherited contract.