Stables Nest (nSTBL)
In order to mint nSTBL, you will need to provide ETH on the Polygon chain
The Polly stable nest provides a way to diversify counterparty risk on stable assets while the underlying assets put to work earning yield on various trusted yield farming protocols. Decentralized and non pegged stables will be used where yield is available.
Objective To provide exposure to a diversified basket of stable coins with a focus on yield and decentralization.
By spreading risk over a number of coins, you reduce the impact of problems any single tokens face. Since the nest does not automatically rebalance, one stable losing its peg would not affect the other tokens in the nest.
By focusing on decentralized stables, you also reduce exposure to regulatory risk and do not rely on central issuers to continually act as they should.
Tokens will be deposited in a variety of protocols to earn yield on them, swapping strategies regularly to maximize the yield earned.

Initial Composition

The nest will start with a mixture of centrally issued and decentralized stable coins because liquidity and yield options are limited for some decentralized options or they are too new to meet the criteria for inclusion.
To provide a greater yield farming return, USDC and USDT, which are centrally issued, are included.
Over time, we expect the weightings of these coins to be reduced in favor of decentralized alternatives once they are sufficiently mature and have yield strategies that are suitable for a stables nest on polygon.
The starting composition is:
  • 40% RAI
  • 30% DAI
  • 15% USDC
  • 15% USDT

Token Inclusion Criteria

For a project to be included in the Polly Stable Index, it must fit the below criteria in order to reduce the risk of the index and fit the desires of the community.
Be a Stable token project available on the Ethereum blockchain or Polygon. Be in liquid markets and being used in different lending protocols The protocol must be running for 6 months before qualifying to be included in the index In the event of a safety incident, the team must have addressed the problem responsibly and promptly, providing users of the protocol a reliable solution and document a detailed, transparent breakdown of the incident. Must be sufficiently decentralized and/or collateralized

Strategy

It is possible for the underlying tokens to utilize strategies that will earn yield, maximizing value for nest holders, who benefit from this productivity without having to perform any actions themselves. These strategies will be added to and changed over time to take advantage of new opportunities or to maximize the yield earned.
To start with, available strategies will be
  • Kashi
  • AAVE
  • CREAM
We are aware of the recent problems the CREAM protocol has encountered and will proceed with caution, favoring other projects for yield until we are sure the risk has been sufficiently lowered.

Management

The Nest is maintained quarterly in two phases.

Determination Phase

The determination phase takes place during the final 2 weeks of the quarter. During this phase the changes needed for the next reconstitution are determined. Strategies and allocation % will be revisited in order to reach the balance between decentralization and having the most optimal yet secure yield possible for those stables. Proposed changes will be published on the governance forum for 1 week then a governance vote will run for the community to approve changes.

Reconstitution Phase

In the two weeks following a successful vote, the index components will be adjusted as per the instructions published during the final 2 weeks of the quarter.

Emergency Maintenance

The multisig holders are authorized by the community to re-balance indexes outside the usual schedule during moments that they collectively deem to be critical emergencies. This clause will allow for quick re-balancing in the event of a protocol or index being in danger of failing.
An example of when this would be utilized would be if a stable coin begins losing its peg/ becoming insolvent, or a protocol suffers an exploit that is not dealt with sufficiently. These scenarios may be time sensitive and require immediate resolution. Thus the team may decide to act without warning and explain their actions in a governance forum post afterwards, or if there is deemed to be time, an emergency governance vote will be posted.
This is intended as a safety mechanism only, to prevent loss of users funds and as such would be a power exclusively exercised under extreme circumstances.
Last modified 1mo ago