Teller Protocol Diamond

Structure
This is the main diamond contract where all facets of the protocol can talk to each other through a shared storage interface. The ITellerDiamond contract itself works by importing all of it's facets as dependencies. See below:
1
abstract contract ITellerDiamond is
2
    SettingsFacet,
3
    PlatformSettingsFacet,
4
    AssetSettingsDataFacet,
5
    AssetSettingsFacet,
6
    PausableFacet,
7
    PriceAggFacet,
8
    ChainlinkAggFacet,
9
    LendingFacet,
10
    CollateralFacet,
11
    CreateLoanFacet,
12
    LoanDataFacet,
13
    RepayFacet,
14
    SignersFacet,
15
    NFTFacet,
16
    EscrowClaimTokensFacet,
17
    CompoundFacet,
18
    UniswapFacet,
19
    IDiamondCut,
20
    IDiamondLoupe
21
{}
Copied!
In the Teller Protocol, each Facet contains function helpers that come from its respective Library or libraries. Each Library contains not only function helpers to assist the facets, but also a storage function caller. Here's an example of our LoanDataFacet
1
// SPDX-License-Identifier: MIT
2
pragma solidity ^0.8.0;
3
​
4
// Libraries
5
import { LibLoans } from "./libraries/LibLoans.sol";
6
​
7
// Storage
8
import { Loan, LoanDebt, LoanTerms } from "../storage/market.sol";
9
​
10
contract LoanDataFacet {
11
​
12
    function getLoan(uint256 loanID) external view returns (Loan memory loan_) {
13
        loan_ = LibLoans.s().loans[loanID];
14
    }
15
​
16
    function getLoanEscrowValue(uint256 loanID)
17
        external
18
        view
19
        returns (uint256)
20
    {
21
        return LibEscrow.calculateTotalValue(loanID);
22
    }
23
}
Copied!
Note: this example does not resemble our actual file on the Teller protocol, but rather a simplified version.
In this example, our LoanDataFacet uses 2 functions that call from the LibLoans and the LibEscrow library, respectively:
getLoan directly calls the LibLoans storage function s() which gets our loan data back after we pass our loanID
getLoanEscrowValue directly calls the LibEscrow library function calculateTotalValue to calculate the loan escrow value using loanID
Next, we'll look at how storage works.
Storage
The way diamond storage works is that we add or read data to a struct that is stored in a hashed position slot by calling a function. Let's call this function store(). We shall take a look at our market.sol storage file, since it's the most popular one in our Teller protocol.
1
struct MarketStorage {
2
    // Holds the index for the next loan ID
3
    Counters.Counter loanIDCounter;
4
    // Maps loanIDs to loan data
5
    mapping(uint256 => Loan) loans;
6
    // Maps loanID to loan debt (total owed left)
7
    mapping(uint256 => LoanDebt) loanDebt;
8
    // Maps loanID to loan terms
9
    mapping(uint256 => LoanTerms) _loanTerms; // DEPRECATED: DO NOT REMOVE
10
    // Maps loanIDs to escrow address to list of held tokens
11
    mapping(uint256 => ILoansEscrow) loanEscrows;
12
    // Maps loanIDs to list of tokens owned by a loan escrow
13
    mapping(uint256 => EnumerableSet.AddressSet) escrowTokens;
14
    // Maps collateral token address to a LoanCollateralEscrow that hold collateral funds
15
    mapping(address => ICollateralEscrow) collateralEscrows;
16
    // Maps accounts to owned loan IDs
17
    mapping(address => uint128[]) borrowerLoans;
18
    // Maps lending token to overall amount of interest collected from loans
19
    mapping(address => ITToken) tTokens;
20
    // Maps lending token to list of signer addresses who are only ones allowed to verify loan requests
21
    mapping(address => EnumerableSet.AddressSet) signers;
22
    // Maps lending token to list of allowed collateral tokens
23
    mapping(address => EnumerableSet.AddressSet) collateralTokens;
24
}
25
​
26
bytes32 constant MARKET_STORAGE_POS = keccak256("teller.market.storage");
27
​
28
library MarketStorageLib {
29
    function store() internal pure returns (MarketStorage storage s) {
30
        bytes32 pos = MARKET_STORAGE_POS;
31
        assembly {
32
            s.slot := pos
33
        }
34
    }
35
}
Copied!
This file, like the previous file, has been compressed for ease of understanding.
Our MARKET_STORAGE_POS is the hash of our position string
The store() function in the MarketStorageLib returns our MarketStorage at the position we initialized before
The MarketStorage is a heavy struct with multiple mappings to interfaces, primitive data types and other structs
So, now that we understand this, how do we call this function to update or read data? Well, it's simple really! Let's head to a simple function in our LibLoans library called loan(), which simply returns our loan data:
1
function s() internal pure returns (MarketStorage storage) {
2
        return MarketStorageLib.store();
3
    }
4
​
5
		/**
6
     * @notice it returns the loan
7
     * @param loanID the ID of the respective loan
8
     * @return l_ the loan 
9
     */
10
    function loan(uint256 loanID) internal view returns (Loan storage l_) {
11
        l_ = s().loans[loanID];
12
    }
Copied!
Let's go through this step by step
loan() function takes in the loanID as a parameter and returns a struct of type Loan (defined in market.sol) with the help of our s() function
the s() function calls our MarketStorageLib.store(), which if you remember it returns our MarketStorage struct stored at our hashed slot
Now that our MarketStorage is returned via s(), we also return the specific loan by adding .loans[loanID]
That's really our Diamond Structure and Storage in a nutshell! Since our Diamond pulls in all of its Facets via Inheritance, calling any of our facet is still calling our Diamond Contract's address.
Intro to Diamond Contracts
Next - Facets (aka mini-contracts)
Market
Last modified 11mo ago
Copy link
Contents
Structure
Storage