Code Organization & Conventions

Angle Protocol comprises different modules with different smart contracts. There are however some contracts which impact all modules and some conventions which are common everywhere.
Fixed Point Math
Solidity does not handle float numbers. To account for the fact that in some occasions floats are needed, the protocol needs to define a base. The protocol generally uses three different bases:
BASE_TOKENS (also simply called BASE in some contracts): this base is equal to 10^18 and is the base used for the tokens of the protocol.
BASE_PARAMS: this is the base used for all the parameters and fees of the protocol. This base is equal to 10^9. For instance, if fees taken on a transaction are BASE_PARAMS / 100, then this means that 1% transaction fees have been taken on the transaction. The reason for using a different base for parameters is to be able to store them as uint64 rather than as uint256 to avoid overflows.
BASE_INTEREST: it is equal to 10^27 and is used for elements on which we need a high precision like interest rate computation
Decimals
To be consistent with the BASE_TOKENS chosen when computing numbers, it has been decided that all the agTokens (stablecoins of Angle) would involve 18 decimals.
Contrary to that, the sanTokens which are the tokens given to SLPs of the Core Module are in the base of the collateral they correspond to. For instance, for the USDC collateral used for the agEUR stablecoin, the sanUSDC_EUR are in the base of USDC and the tokens have decimals = 6.
Error Messages
To gain some size in the smart contracts and enable higher values of the compiler on big contracts, the error messages in the smart contracts are sometimes displayed as figures.
These figures are mapped to a corresponding error message file corresponding to each module.
The error messages for the Core Module can for instance be found here:
errorMessages.json
3KB
Code
Error Messages of the Core Module Angle Protocol
In other situations, the protocol relies on custom Solidity error messages defined in each contract.
Governance Attack Minimization
The idea with Angle Protocol is to minimize in the end the role of governance, and to eliminate the need in trusted human intervention.
To the extent possible, the current design of the smart contracts thus tries to minimize the impact a wrongdoing of governance could have on the protocol.
For instance, whenever a new reference is created in a contract, a zero address check is performed.
Smart Contracts Upgradeability
A majority of Angle's smart contracts are upgradeable.
The reason for having upgradeable smart contracts is that external contracts interfacing themselves with Angle should not see the endpoint to which they point to change. Besides, Angle is a brand new protocol and DeFi is in its early days. As such, it's important for the protocol to have the means to remain on the edge and incorporate new findings and improvements.
The upgrade logic of the protocol is that of the Proxy Admin and TransparentUpgradeableProxy contracts of OpenZeppelin. The code of most contracts of the protocol therefore corresponds to OpenZeppelin proxies pointing to an implementation.
Governance only can vote to upgrade smart contracts.
The ABIs of these OpenZeppelin contracts can be found here:
TransparentUpgradeableProxy.json
3KB
Code
TransparentUpgradeableProxy ABI
ProxyAdmin.json
3KB
Code
ProxyAdmin ABI
🔑 Access Control
To make sure that functions of some contracts of the protocol can only be called by the desired contracts or addresses, Angle Protocol uses across all its modules and contracts access control to define the system's contracts responsibilities. Depending on the contracts, either OpenZeppelin library or a custom library is used.
The system has many different roles, some can be found in different contracts. There are however two main roles which are present almost everywhere: the GOVERNOR_ROLE and the GUARDIAN_ROLE.
Depending on the module, different contracts are used to maintain the integrity of these roles. For instance in Angle Core Module, this takes place at the level of the Core contract, while in the Borrowing Module it takes place at the level of the CoreBorrow contract.
GOVERNOR_ROLE
Powers
The GOVERNOR_ROLE is the most powerful one of the protocol, it can be used to change a multitude of protocol parameters unique to each contract (fees, oracle windows, ...), as well as to grant and revoke roles in some contracts. It can also be used to upgrade smart contracts through the ProxyAdmin.
While at launch, this role was belonging at launch to the Timelock in the Core Module, it now belongs to Angle Governance Multisig.
This role can however most of the time be supported by different addresses, and the Governance Multisig is generally able to grant this role to new addresses.
One thing to keep in mind is that even though powerful, the multisig and more generally the GOVERNOR_ROLE cannot do anything it wants on the protocol. In particular, in the Core Module for instance, the GOVERNOR_ROLE cannot mint or burn stablecoins and sanTokens, it cannot open or close perpetual positions, and it cannot withdraw more than the surplus of the protocol.
Setup
The role of the Governor Multisig with the GOVERNOR_ROLE is simply to push the button and execute/implement decisions that were voted by veANGLE holders (ANGLE holders which locked their token).
This multisig is a 4/6: 3 Core Team members (Pablo Veyrat, Guillaume Nervo and Picodes) and 3 influential actors of the ecosystem (Julien Bouteloup, 0xMaki, and SebVentures).
For more details on how voting takes place within Angle Protocol you can also check this page.
ANGLE Distribution Recap
As this multisig and the governor role are governed by veANGLE holders, and as veANGLE can simply be obtained upon locking ANGLE tokens, it is important to have in mind the ANGLE distribution.
The 1,000,000,000 ANGLE tokens have been directly issued at the creation of the contract. These tokens have been allocated across different contracts and addresses. Current distribution of the ANGLE token can be found here. The allocation was set as follows:
40% to the AngleDistributor contract: this contract handles weekly reward distribution through liquidity mining.
18% to the DAO Treasury (= the Governance Multisig). In the tokenomics, DAO Treasury is supposed to control 20% of the tokens, 2% were put in a multisig controlled by the Core Team (called the AngleMaster) to get more flexibility when it comes to implementing things like Olympus Pro.
36% to the AngleMaster contract. This contract is a 2/3 Gnosis multisig controlled by distinct Core Team members of the protocol (the 3 co-founders of the project). The idea of this multisig is that it has control of funds to be sent to the vesting contract, and it holds the reserves of the funds that are kept for future strategic partners of the protocol
5% to the Vesting contract. In order to reduce the exposure of the funds potentially at risk in this contrat (this contract has been forked from Maker's DssVest), not all the 18% of the tokens that have to be distributed to the team + early backers + advisors have been initially put in this contract. The `AngleMaster` will regularly transfer tokens to this contract.
1% to Wintermute, our partner in charge of market making in centralized exchanges
For more details on ANGLE distribution and on the governance multisig, you can check this section of the doc.
GUARDIAN_ROLE
The GUARDIAN_ROLE is designed to enable quick feature shutdowns and allow the protocol to react rapidly to unforeseen events. It can for instance shut off some protocol functionalities.
Still, this role is not able to withdraw funds from a collateral pool, to manipulate oracle prices by changing references to oracles or to add new strategies that will be able to withdraw funds from the protocol.
Generally speaking, Angle Protocol interactions cannot be undone by this GUARDIAN_ROLE, and this role does not give access to any user funds. On a side note, all the actions that can be taken by the GUARDIAN_ROLE can also be taken by the GOVERNOR_ROLE.
The GUARDIAN_ROLE is held by a 2/4 Gnosis Multisig controlled by Core Team members of the protocol (the same as in the Governor multisig plus teddav).
More details about the GUARDIAN_ROLE can also be found here.
⏭️ Next
Beyond these conventions, there are some contracts which are common and useful everywhere in the protocol across the different modules. This is notably the case of the AgToken, the Router and of all the governance smart contracts.
Auto-Leverage and Capital-Efficiency in the Borrowing Module
Next - Governance and Cross-Module Contracts
Governance Contracts
Last modified 10d ago
Copy link
Contents
Fixed Point Math
Decimals
Error Messages
Governance Attack Minimization
Smart Contracts Upgradeability