3. Mechanics of HocDao
Last updated
Last updated
The (soon-to-be) decentralised Hoc Protocol allows users to generate HGBP by leveraging real-world assets as collateral. The protocol is managed by holders of the HocDao's governance token HOC. The initial rate charged to HGBP borrowers will be 3% per annum on any disbursed amount. Users will also receive 3% per annum in HOC rewards (Section 3.2). It is important to note that any interest rate offered to RWA borrowers is fixed during the term of their NFT smart contract.
Once the owner has created an NFT based on their RWA (Section 2), the NFT owner is able to lock their asset in a smart contract and borrow HGBP against the value of the underlying RWA. The loan-to-value (LTV) ratio will be defined by Hoc Governance and is based on diligent profiling of the underlying asset class. There is a fixed maximum of 70%.
Upon locking their NFT in the Hoc Protocol, the RWA owner could drawdown any amount of HGBP up to the combined limit of any NFTs they may have locked. The HGBP interest rate is charged in HGBP and accrued per block. No maturity dates are defined, allowing RWA owners to borrow against their assets in perpetuity. According to our beta test, this process can be completed significantly faster than the equivalent traditional CeFi processes.
The Hoc Protocol will provide rewards to borrowers in HOC tokens. Effectively, these tokens act to offset the HGBP borrowing rate. These rewards are calculated as a certain percentage of the value of the total HGBP borrowed by the user, and added to the the borrowers balance on a block by block basis (much like the HGBP interest). The initial rate for these HOC rewards will be 3% per annum on HGBP value drawdown (initially assuming HOC is £1).
The borrowing rate percentage, or the HGBP borrowing rate (HBR), can be changed via the governance procedure. In increasing these rates, Governance can discourage further HGBP supply being minted. If the open market price of HGBP decreased from the peg, then such action will generate upward price pressure back to £1.
To repay borrowed HGBP, a borrower can acquire HGBP via the open market and make a repayment within the DApp.
Should the same borrower have more than one NFT locked into the Hoc Protocol, they are able to select which NFT they would like to reduce the amount borrowed against. This is important to ensure that borrowers with multiple RWAs can unlock their NFTs seamlessly.
When an NFT no longer has any HGBP borrowed against it, the borrower is able to withdraw it from the Hoc Protocol Vault. This vault will automatically close and the borrowing rate expire.
Once the amount is paid back, the Hoc Protocol will burn the minted HGBP. Consequently, HGBP is always over-collateralised by RWA. The earned interest HGBP would accrue to the protocol treasury wallet which is drawn upon as determined by Hoc Governance. This pool of HGBP will never be taken as a profit by the Foundation or any other entity.
In the instance of default of the repayment of the HGBP drawdown and in accordance with the parameters of the smart contract between the borrower and the Hoc Protocol, the Protocol shall seize the NFT and close the vault, unlock the underlying property via the trusted 3rd party service provider and sell this property on the market. The recovered fiat will then be placed into a reserve pool (part of the wider collateral pool), providing an element of fiat backing to HGBP. This pool may be accessed and utilised by the community, so long as the value of all HGBP in circulation (including the defaulted HGBP) does not exceed the value of RWA in the collateral pool. HocDao aims to have a 30% buffer minimum to prevent this course of action.
The Hoc Protocol will launch a HGBP staking facility.
HGBP holders (including borrowers) may elect to stake some, or all, of their HGBP from time to time by transferring it to an HGBP staking contract. See Figure 3, Item 1. All HGBP staking will be kept and managed on corresponding blockchains, providing auditable and transparent records for users. HocDao aims to maintain higher staking rates compared to CeFi alternatives, such as high street banks.
The Hoc Protocol will transfer staking rewards to the user. See Figure 3, Item 3. Staking rewards will be received in HGBP + HOC and calculated as a percentage of the total HGBP value staked by the user:
The initial standard rate for these HOC rewards will be 3% per annum paid in HGBP + 3% per annum paid in HOC, calculated on HGBP value staked (and assuming HGBP is £1).
Additionally, one may elect to stake their HGBP, along with an equal amount of USDC, into a staking pair of HGBP/USDC. In this way, such a user can help to support a primary liquidity market for HGBP. As such they will be rewarded with 3% HGBP + 6% HOC per annum, applicable on the total value of (HGBP + USDC) staked.
At launch, the entirety of any interest HGBP paid back into borrowing vaults will be used to pay the HGBP staking reward rate. All earned revenue will thus be entirely distributed to those who buy and stake HGBP.
The exact percentage of staking rewards percentage, or the HGBP Staking Rate (HSR), can be changed by Governance: In manipulating these rates, there will come systemic economic effects too:
• Increasing the HGBP Staking Rewards will increase the open market demand for HGBP. If the open market price of HGBP has broken downwards from the £1 peg, then such action will generate upward price pressure back to peg.
• Decreasing the HGBP staking rewards will decrease the open market demand for HGBP. If the open market price of HGBP has broken upwards from the £1 peg, then such action will generate downward price pressure back to peg.
HOC Governance may decide to burn an amount of HOC from Treasury (at HOC market value), in order to mint HGBP from it.
If the value of 1 HGBP rises above 1 GBP, Governance can then sell this HGBP into an open market HGBP/stablecoin pair, as a more direct way to decrease the HGBP price back down to £1, as compared with just changing the HSR. Whatever stablecoin acquired from this action can sit in treasury, preserving value as best as possible. These liquid funds can be deployed for future community needs, such as to increase the price of HGBP in case it would fall below £1. This is applied given that the value of all HGBP in circulation does not exceed the value of RWA in the collateral pool.
Upon launch, it is necessary to mint a certain amount of HGBP from HOC in order to have enough HGBP in the ecosystem to service initial borrower debt obligations. HocDao will try to ensure a total collateral pool buffer of 30% (total RWA value is maximum 70% LTV), meaning that we have a large margin in order to prevent HGBP value exceeding total RWA value.
The Hoc protocol is uniquely placed in that it is able to offer 3 layers of defence to the £1 peg of HGBP:
Stability is supported broadly by a cornerstone to the collateral pool, made up of prime, central London real-estate. Stable assets collateralising a stablecoin.
Stability is also actively managed by Governance, via staking (HSR) and borrowing rate (HBR) manipulation, influencing supply and demand. And if all else fails, Governance may intervene by minting HGBP from HOC treasury and selling it onto the open market, or using alternative treasury funds (derived from earlier selling of such HGBP, or from defaults).
We are unique in offering all three of these safeguards.
Once at sufficient scale, the HoC Foundation will aim to build a pool of GBP that will back, relative to the total collateral pool, a small amount HGBP. Bearing in mind the relatively uncontested that stablecoin regulation incorporating liquid capital reserves requirements is coming very soon, we feel this is necessary to consider now. Also, noting recent research and to paraphrase, we are of the opinion that:(footnote) Additionally, we feel such a reserve adds an additional line of defence for HGBP's peg, on top of the three in Section 4.10, as the stablecoin will be directly convertible to GBP within the Protocol for the community as a whole, individual users, or both. We thus work towards a future collateral pool that looks like this:
