Technical Protocol Overview
GRID ($M Extension)
Grid.sol (inheriting from M0’s MYieldToOne contract) is the gateway to the DayFi ecosystem. As an M-extension, it benefits from the liquidity across the entire M0 ecosystem.
Minting
GRID can be obtained in several ways:
Approved minters in the M ecosystem can mint new M. These minters are trusted intermediaries that keep the reported amount of US dollars in reserve to provide a backing for M. Minting/Redeeming can be arranged with the minters directly, but requires a KYB process. M can then be wrapped for GRID.
Swapping against deep onchain liquidity pools for M. This is the easiest way to obtain M. The only downside is the possible slippage incurred, depending on the trade volume. M is then wrapped for GRID.
JustMintIt Extensions allow traders to place open orders from STABLE <> GRID that solvers come and fill by swapping the STABLE for M. This gives traders instant liquidity at a better price than they’d obtain by swapping through onchain pools, and backfills the missing M deposit. This is the preferred method for acquiring GRID.
Option 3, the JustMintIt extension, is the preferred method for acquiring GRID.
// JustMintIt contract to comeBurning GRID
GRID can be unwrapped for M, which can then be swapped for stables such as USDC or USDT. Additionally, approved minters with M0 can redeem M directly.
// JustMintIt contract to comesGRID Yield Vault
sGRID is the reward-accruing version of GRID, and is the world's first global electricity asset. sGRID earns rewards from GRID M emissions and the protocol's physical energy infrastructure.
sGRID is an ERC7540 (sync deposit & async redeem) token, earning yield from distributed energy systems and base M treasury yield. It is built on the Centrifuge's v3 architecture.
Staking
Users can stake GRID to receive sGRID ("staked GRID") at the current published NAV price. Staking is a synchronous ERC4626 deposit operation.
IBaseVault sGridVault; // sGridVault is instance of sync deposit vault on Centrifuge
uint256 sGridShares = sGridVault.deposit(gridAmount, receiver);Unstaking
Users can redeem sGRID to receive GRID at the current published NAV price.
DayFi uses an asynchronous ERC7540 redemption mechanism in the OpenQueue.sol contract. This contract accepts incoming redemption requests in FIFO order, and manages accounting for request approvals in an efficient manner using a moving cursor mechanism that clears every request before the cursor and rejects everything after it.
Redemptions are subject to a timelock, and open every 30 days.
Requests cannot be canceled, but rather they can be recovered if not approved after liquidity has been distributed.
function requestRedeem(
uint256 shares,
address receiver
) external returns (uint256 requestId);
function redeem(uint256 requestId) external returns (uint256 claimableAssets);This contract interacts with the balance sheet directly to take custody of and distribute shares and assets. It also employs a reserve/unreserve lock through the balance sheet to ensure no concurrent accesses on the balance sheet can pull deposited funds meant for redemption through the queue.
In the future, the redemption queue will utilize an auction-based mechanism for queue priority, as defined in the QEV section.
Pool Management
Centrifuge provides the infrastructure for deploying and managing DayFi pools. Operating with a hub-and-spoke model, Centrifuge’s V3 protocol allows for pool management to occur on a “hub” chain, while accepting deposits and redemptions in vaults on a number of chains. This simplifies management by consolidating it on a single chain, while giving investors a more convenient way to invest from whatever chain they are on. The DayFi Hub resides on Ethereum mainnet. DayFi’s first spoke is deployed to Plasma.
Pool management entails:
Setting the NAV/share values across all vaults.
Granular balance sheet management and access control functions.
Centrifuge vaults work with any ERC20 asset. In DayFi, GRID is designated as the sole deposit asset that can be exchanged for sGRID.
DeedPollManager
Each PPA has a corresponding Tokenized Deed Poll, recorded as a controllable electronic record under Article 12 of the Uniform Commercial Code. The SPV, as title-holder, issues this uniparty instrument assigning the economic proceeds (but not ownership) of the PPA to the Daylight vault. The Tokenized Deed Poll is represented onchain as an ERC721 token. This structure allows the vault to hold a bearer-style economic interest in the underlying infrastructure while the SPV retains legal title.
A tokenizing agent, currently Anode Labs, Inc., will mint Tokenized Deed Polls using DeedPollManager.sol. This NFT is then deposited in the Centrifuge balance sheet as collateral in order to borrow against it up to the agreed project amount in the PPA agreement.
function mintDeed(
uint128 loanAmount,
string calldata ipfsHash
) external returns (uint256 id);Onchain NAV Calculations
NAV values can be set through the Hub on one chain, such that prices can propagate to all the vaults on every chain our pool is deployed on. NAV computation is deterministic and is a function of several inputs:
Recognized revenues, less protocol fees, recorded in the open queue instances
Asset carrying value, tracked by the deed poll managers
Stablecoin balances, held on the balance sheets
These inputs arrive on several chains. These inputs are consolidated on the hub chain, and broadcast to each pool instance on all chains. Centrifuge provides a contract to handle this tallying and broadcasting from the hub chain (see SimplePriceManager below).
We implement a contract, instantiated on each spoke, for reporting NAV values back to the hub. NAVReporter.sol will make calls to the balance sheet to retrieve stablecoin balances and the DeedPollManager.sol to calculate the current carrying value of the assets in the portfolio, based on a linear depreciation across their useful life. A crosschain message with the new (spoke-level) NAV is then sent to the Hub, where it is tallied and propagated back to all the spokes as the updated NAV / sGRID.
function reportNAV() external returns (uint128 netAssetValue);Protocol Fees
The fee splitter contract, DaylightFeeRouter.sol, accepts inflows from onramped revenues, and takes a protocol fee (in basis points) from those inflows, directing it to the fee_earner address. The protocol fee is currently set at 12% and is modifiable by governance.
function setFeeRate(uint128 _feeRate) external onlyOwner {
require(_feeRate <= MAX_FEE_RATE, MaxFeeRateExceeded());
feeRate = _feeRate;
}
function acceptInflows(uint256 amount) public onlyOwner {
asset.transferFrom(msg.sender, address(this), amount);
_takeFees(amount);
}
function _takeFees(uint128 amount) internal returns (uint128) {
uint128 fee = (amount * feeRate) / 10_000;
asset.transfer(fee_earner, fee);
return amount - fee;
}Bridging
Bridging is predicated on canonical instances of token assets on each chain. DayFi utilizes the default bridging infrastructure used by M0 and Centrifuge. M0 currently uses Wormhole for bridging, and Centrifuge uses LayerZero. When a DayFi instance is deployed on a new chain, they are declared as the instance to interact with for any crosschain actions. Refer to M0 and Centrifuge’s technical documentation for more information on their implementations.
Centrifuge goes a step further by using global pool and share class IDs as the canonical identifiers for share assets, differentiating which chain the assets are being transferred to by the chain ID.
Price Feed Oracles
Chronicle is DayFi's current price feed oracle provider. These oracles make price feeds available to lending markets and other DeFi protocols for composability. Chronicle makes this available by deploying a contract which supports the expected interfaces for a number of markets.
Last updated
Was this helpful?