BarnBridge Standards and Disclosures
Preamble
BarnBridge is committed to upholding the highest standards in all we do. We go through multiple layers of internal and external audits on our code base prior to release, offer bounties for errors that are detected, and strive to provide the highest levels of engagement and service to our growing community.
In that vein, we have outlined a set of disclosures to support a base level of understanding and transparency into the risks associated with using our products and platform. One of our core beliefs is ensuring our users and stakeholders have all the information they need to make informed decisions. This is but the first step in an ongoing initiative to provide greater transparency and richer information around our products and services.
Barnbridge co-developed these standards and disclosures with the Opium Network, who will also be adopting them. We also received input and feedback from Aave and the DeFi Alliance. We will continue to work with the DeFi Alliance to further iterate around DeFi-wide standards and tools that we hope the wider DeFi community will find of value.
We welcome feedback from the BarnBridge and wider DeFi community on these disclosures and other information they would like to have access to. We encourage other teams working in the DeFi space to adopt, leverage, or introduce their own set of standards that would support improved transparency across the decentralized finance space.
Product Risk Disclosures
We have defined two broad categories of risk disclosures:
- Quantitative risks, and
- Qualitative risks
Quantitative Risks
- Risks to realizing expected returns. Factors: Probability of Occurrence vs. Impact of Occurrence
We would like to introduce a very simple but at the same time very powerful representation of risk factors for specific investment/pools/risk tranches. We place risk factors in the probability vs. impact map in four categories:
- Low probability, Low impact
- Low probability, High impact
- High probability, Low impact
- High probability, High impact
It is a simple way to view risks and their impact on P&L, while having a way to estimate the probability of an event occurring. These risks would be self-reported by our team or others that may adopt this model. Investors will still need to do their own due diligence.
Let’s consider an example using a tranched AAVE interest rate pool with a Senior tranche and a Junior tranche, that is denominated in USDT. The senior pool has a fixed 8% return and the junior pool gets the remaining yield with 5x leverage.
The Author may want to describe and define at least three risk factors:
- The AAVE smart contract risk
- The USDT solvency risk
- The AAVE floating rate risk
2. Leverage exposure
Leverage ratio of an asset pool relative to the underlying collateral
- Low: 0–50%
- Medium: 50% — 100%
- High: 100% — 200%
- Very High: Above 200%
3. Stress Tests
Where applicable we will share stress test¹ information on potential extreme loss events², the probability of such events occurring, and the expected financial impact of various hypothetical scenarios that lead to losses of:
- 25%,
- 50%, and
- 100% of funds
When applicable we provide simple payout charts (Scenario vs P&L), in this case we would analyze the effective Aave rate (resulting from the floating AAVE rate during the period) at the end of the period versus the P&L for the corresponding pools
Qualitative Risks
- Main risks — General summary of risks
- Exposure factors — Define the factors assets generally expose investors to
- Outlier Events — Potential outlier events that could induce extreme losses
Protocol Technical Standards — ERC-20/ERC-721
Our platform employs both ERC-20 and ERC-721 standards. These standards are the most widely used across the Ethereum ecosystem. They form the foundations of interoperability and composability across the decentralized finance ecosystem.
Our Junior Tokens are ERC-20 compatible since they are fungible. Secondary markets can offer and trade our tokens on decentralized platforms and other proprietary forums without permission.
The Senior BOND tokens are ERC-721, non-fungible (NFTs), but transferrable. One could sell these tokens before their maturity date at a discount to someone who is willing to wait until the end to claim the principal plus the guaranteed reward.
BarnBridge may build or support a third-party to build a marketplace for trading Senior BOND Tokens. The pool is permissionless so any entity can build marketplaces or incorporate our tokens into an already existing venue.
Term Definitions and Nomenclature
One of the most common forms of credit enhancement in CDOs is subordination of junior tranches. In the multi-tranche or senior/subordinated CDO, the subordinated or junior tranches support the senior tranches. The issuance proceeds from debt and equity are used to purchase collateral (assets) generally with a principal balance equal to the rated debt amounts (liabilities) plus the equity share. Since the equity is not typically rated, the asset pool supporting the rated liabilities is greater than the rated liability amounts. Thus, there is a loss amount that the assets can sustain without immediately affecting any of the rated liabilities.
The payment priority waterfall in the transaction prioritizes the payments to each class of debt holders. CDO payments are typically paid sequentially with the seniors made whole first followed by the more subordinated tranches. Thus, holders of the senior debt tranche have priority of payment over the holders of any junior debt tranche. As a result of their subordinate status, the junior debt tranches generally are rated lower than the senior debt. However, the junior debt holders are compensated for the additional risk by being paid a higher interest rate.
Below is a list of product attributes, terms, and definitions we will use going forward:
Conclusion
We look forward to your feedback and input on ways to improve these standards over time.
Nothing we have discussed here should be seen as investment advice.
Footnotes
¹ Stress Test: Defined in Table 3
² Extreme Loss Event: Defined in Table 2
