# Technical Protocol Overview

## GRID ($M Extension)

<mark style="color:orange;">`Grid.sol`</mark> (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:

1. 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*.
2. 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*.
3. 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&#x20;*****GRID*****.**

{% hint style="success" %}
Option 3, the JustMintIt extension, is the preferred method for acquiring *GRID*.
{% endhint %}

<figure><img src="https://1266178917-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA6SctLA8Jk5AmSR0T6fL%2Fuploads%2FQFv12mvcNqyDzrV2DTyd%2Fjmi%20beige.png?alt=media&#x26;token=a0a6649b-2d6d-4833-9318-a67e29f3ccbd" alt=""><figcaption></figcaption></figure>

```
// JustMintIt contract to come
```

### Burning 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.

<pre><code><strong>// JustMintIt contract to come
</strong></code></pre>

***

## sGRID Yield Vault

s*GRID* 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.

&#x20;*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.

{% embed url="<https://docs.centrifuge.io/developer/protocol/overview/>" %}

<figure><img src="https://1266178917-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA6SctLA8Jk5AmSR0T6fL%2Fuploads%2FXLca1uYRlRe3b1TSRy9x%2Fyvf%20tan.png?alt=media&#x26;token=30b45c4b-bd8f-46a0-835c-813c57a0ca7c" alt=""><figcaption></figcaption></figure>

### Staking

Users can stake *GRID* to receive *sGRID* ("staked *GRID*") at the current published NAV price. Staking is a synchronous ERC4626 deposit operation.

```solidity
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.&#x20;

DayFi uses an asynchronous ERC7540 redemption mechanism in the <mark style="color:orange;">`OpenQueue.sol`</mark> 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.

```solidity
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](https://docs.dayfi.com/solution-overview/underlying-assets-and-revenues).

### 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.

{% embed url="<https://docs.centrifuge.io/developer/protocol/architecture/hub/>" %}

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 <mark style="color:orange;">`DeedPollManager.sol`</mark>. 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.

```solidity
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

<figure><img src="https://1266178917-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA6SctLA8Jk5AmSR0T6fL%2Fuploads%2FvuU4XlO3nulj1SaTMuYa%2Fnav%20tan.png?alt=media&#x26;token=7fdff91a-8673-4140-9667-ede3ad891574" alt=""><figcaption></figcaption></figure>

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 <mark style="color:orange;">`SimplePriceManager`</mark> below).

{% embed url="<https://github.com/centrifuge/protocol/blob/main/src/managers/hub/SimplePriceManager.sol>" %}

We implement a contract, instantiated on each spoke, for reporting NAV values back to the hub. <mark style="color:orange;">`NAVReporter.sol`</mark> will make calls to the balance sheet to retrieve stablecoin balances and the <mark style="color:orange;">`DeedPollManager.sol`</mark> 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*.

```solidity
function reportNAV() external returns (uint128 netAssetValue);
```

### Protocol Fees

The fee splitter contract, <mark style="color:orange;">`DaylightFeeRouter.sol`</mark>, accepts inflows from onramped revenues, and takes a protocol fee (in basis points) from those inflows, directing it to the <mark style="color:orange;">`fee_earner`</mark> address. The protocol fee is currently set at `12%` and is modifiable by governance.   &#x20;

```solidity
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.&#x20;

{% embed url="<https://docs.m0.org/home/technical-documentations/m-portal/overview/>" %}

{% embed url="<https://docs.centrifuge.io/developer/protocol/guides/bridge-share-tokens/>" %}

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.

***

## Policy Checking

We plug into [Predicate](https://predicate.io/)'s onchain registry of high risk and sanctioned wallet addresses to blacklist them from interacting with the broader DayFi ecosystem. Predicate will maintain GRID and sGRID blacklists to block transfers and freeze sanctioned addresses at the smart contract level. Common use cases such as AML and CFT compliance are supported, but Predicate also support programmable policies for bespoke use cases.