Inter Protocol Vaults: Contract Implementations

Protocol Reserve

The Protocol Reserve acts as the accounting hub of the protocol and maintains assets earned as fees or contributed in other ways. See,

The Protocol Reserve has no end user facing elements. It primarily acts to manage accounting functions of the protocol. These include:

  1. Hold assets from protocol fees such as IST from Stability Fees or collateral assets taken from Liquidation Penalties
  2. Hold other assets contributed via asset transfers. For example, an external party could raise funds to contribute directly to the Reserve
  3. Track shortfalls from unsuccessful liquidations
  4. Burn IST to reduce shortfall 1:1 through a governed API call

This fourth item is a function that the Economic Committee can call on the Reserve contract. Since the action is not time-sensitive, the Economic Committee may choose to require a signaling vote from BLD Stakers before executing this authority.

3 Likes

Decentralized Oracle Network and Price Feed

The Vaults contracts rely on a robust price feed for accepted collateral. A decentralized oracle network composed of 5 Agoric validators with Chainlink node operation experience, led by Simply Staking, has been created that can support this effort.

Price submission by the node operators reaches the fluxAggregatorContract which takes a median of its inputs and provides a price feed that is consumed by the Vaults contracts. Oracle node operators may be added or removed from the network based on guidance from Simply Staking, with the Economic Committee acting in a temporary capacity as the executor of that guidance.

5 Likes

Contract Deployment Options

Agoric OpCo has also spent considerable time testing contract deployment with multiple approaches:

  1. Separate contract installation and deployment from chain upgrade, as expected for future third-party contract deployment
  2. Integrated installation and deployment of the Inter contracts, as was done with PSM installation

Approach #1 in practice is more complex than will be required for third-party contracts because Inter contracts get privileged authority to mint native IST. Thus, it entails some execution and governance fatigue risks, and takes longer to complete.

Approach #2 reduces the cost and effort of deployment, but requires that the Inter Protocol community determine and recommend the specific code and configuration (e.g., in a signaling proposal) to include with the platform upgrade. The community should consider both options and decide which is best.

4 Likes

Next Steps

The Vaults release is close to reaching its final production-readiness milestone, and now is the time for the community to prepare for the discussions and governance activities that would upgrade the Agoric chain to add Vaults to Inter Protocol.

To kick off the launch process, members of the community should take the lead on next steps and:

  • Participate in discussions in the Community forum, and deliberate on which approaches outlined above will be best for the future stability, decentralization, and success of Inter Protocol.
  • Stake your tokens to ensure that you are ready to vote as on-chain proposals go live during the run up to launch.
  • Stay tuned to community spaces like Twitter and Discord throughout the month of May for notifications about critical launch milestones like testnet exercises and on-chain governance proposals.
  • Participate in on-chain governance by creating and voting on proposals important to launch.

The BLD Staker community decides what will happen next on the Agoric chain and Inter Protocol and drives the launch of mainnet-1b and Vaults. As core developers prepare to cut the next release of the Agoric SDK, it is up to the community to prepare for the next launch in the Agoric Ecosystem.

4 Likes

Thank you, @rowland. Well written and informative.

Concerning the path forward, highlighted in this post: DCF would be supportive of approach #2 (above), that is, integrated installation and deployment. That option is the most time and cost efficient.

In terms of timing, given this chain of posts and your previous on the 1B release, I think we have the beginnings of a discussion that would support the launch of a signalling proposal, and we would be happy to help with that. The community does need to weigh in on configuration issues and parameter controls, but that too can be addressed in the signalling proposal. If we consider this latest thread as the starting period for the discussion, that means there should be a 5 days wait (the discussion period) before moving to the signalling proposal. If anyone has any objections to that process, please do speak up!

4 Likes

Hi Rowland. Thanks for the update! Exciting to see us getting closer to the Vaults launch!

If we proceed with Approach #2, which I see that @ricDCF has supported, is the “specific code and configuration” baked into the binaries for the release? Are we able to change this configuration later through governance proposals, or do changes require network upgrades?

DC

3 Likes

The security assessment of Vaults is now available at Agoric - Security. This security review is a key milestone for production readiness of the platform.
The assessment team from Atredis Partners surfaced 1 low severity and 1 informational issue.
If you’re interested in learning more about the Vaults contracts or want to review the full security assessment read more here.

3 Likes

Future upgrades to the contracts can occur without a chain upgrade! A big part of the platform work that went into this release was enabling that capability. Note that those upgrades will still require a chain vote (limited to executing the contract upgrade).

After this release, only upgrades to the Agoric VM will require chain upgrades.

2 Likes

Validatrium supports cost and time efficient approach

2 Likes

That’s great. We voted in support of the signaling proposal that advocates this approach.

DC

3 Likes

We (knowable.vc) have voted ‘yes’ on Prop32. It’s outside of our wheelhouse, but we have confidence in Rowland and the OpCo to responsibly deliver a mechanistically secure, well-configured, and well-audited update, and we have yet to see any dissenting opinions.

3 Likes

Awesome writeup - thanks @rowland. I am supportive of the integrated installation (option 2) for expediency.

Regarding the oracle implementation, there are a few areas I am curious to learn more about!

1. Will the data be coming from an official Chainlink data feed?

In the Agoric dev docs, I see an officially sponsored price authority and Any API mentioned. Are node operators submitting prices to the Agoric oracle network the same way they would the Chainlink network, pulling prices from the Any API and sending the Agoric network, or something else?

If the solution leverages official Chainlink data feeds, which one(s) is the team planning to use at launch? If I search for ATOM, I can see pricing is available from three networks - Arbitrum, BSC, and Moonbeam, each with a slightly different oracle operator set. Will this solution leverage one of these existing feeds, create a new feed, or something else?

Also, ~6 months ago I remember seeing a table on the Chainlink site that contained the underlying price sources - (Coinbase, Binance, Coingecko, Uniswap v3, etc), but am no longer am to find it. Would be curious if this type of information is available for the Agoric price feed (perhaps including venues like Crescent and Osmosis)!

2. From the devnet demo it seems like ATOM may be the only asset as launch, but how will bridging/depeg risks for assets like axlETH and gravETH be accounted for?

The ETH/USD price feed is probably the most live/robust, but wouldn’t account for a scenario like Nomad. And price feeds for gravETH and axlETH may have idiosyncracies due to lower liquidity.

3. Will the solution be able to support liquid staking derivatives, like stATOM and stOSMO?

If yes, is the idea to incorporate a price feed into the Agoric oracle network, and pipe this into the fluxAggregator contract? Or is the team considering integrating additional oracles (i.e. Osmosis TWAP) directly to a price authority contract?

4. What is the oracle mechanism for IST? Will assets be quoted in USD, and then converted to the market price of IST?

5. What is the process for adding new assets to the oracle contract? Is this controlled by econ committee governance?

Presumably, community builders (hi :wave:) will be looking to leverage these price feeds for the applications, so I am curious to know how this will work!

6. If official chainlink price feeds are not being leveraged, how is the team thinking about the long-term robustness and decentralization of the oracle network?

This is a bit open-ended, and I’m happy to expound on it. But more so am just looking to understand the future direction and plans!

1 Like

slightly tangential…

oops… those are pretty out of date. I just opened an issue about that. Note that we most likely won’t cover the operational aspects that you’re mostly asking about here, but for the API and such, stay tuned to…

Excellent question! This is what BLD staker governance is all about. As it says in the Inter whitepaper:

Governance determines the approved collateral types

That decision hasn’t been delegated to anything smaller than the whole BLD staker voting process. So to question 5, no, the econ committee can’t add a new collateral type.

So a proposal to bring on axlETH or the like as a Vaults collateral involves discussing such risks to the satisfaction of the BLD stakers.

Recall also from the Inter whitepaper:

2.5 Multiple levels of protection
The Inter Protocol implements several levels of economic protection to ensure that IST remains
100 percent backed, even in the case of a large drop in the price of collateral:

  1. Overcollateralization and Liquidation
  2. Reserve pool and IST fees
  3. BLD issuance

By way of precedent, recall the proposal to add PSM contracts for DAI_axl and DAI_grv:

The Economic Committee also has an important role to play: once the decision to approve a collateral type is made, the EC controls parameters noted above: Mint Limit, Collateralization Ratio, etc. These parameters can be used to mitigate bridge risk.

Again, by way of precedent, recall the discussion of starting small and expanding those limits for the PSM launch:

1 Like

Yes; any asset that can be transferred over IBC works the same way, as far as the contracts and related software are concerned.

How to arrange for reliable oracles is an important consideration in a BLD staker decision to bring on another collateral type. I’m not aware of any plan of record beyond for oracles ATOM, but I think there has been some brainstorming along the lines you note. I’ll let others share any brainstorming they care to :slight_smile:

1 Like

The Inter Protocol treats IST as worth 1 USD axiomatically. It’s up to the surrounding mechanisms to make it so in the market.

Technical detail

There is a technical detail where Oracle prices are reported using an idealized ERTP brand for USD and then converted prices in IST by a “scaled price authority” contract that sits between the Oracles and the vaultFactory. But the scale is configured to 1:1.

1 Like

Thanks for the quick and thorough responses @dckc! I didn’t intend to divert the convo and would be happy to start a new thread to discuss oracle/asset specifics :sweat_smile:

My statement above that an unofficial Chainlink implementation is not robust nor decentralized is phrased poorly. Chainlink is an open source software that anyone can use! Instead, it should say - does the oracle network implement the same sort of slashing Chainlink has for lack of liveness and misreporting?

Also, I should have mentioned this in my original post, but I am super stoked for the Inter Vaults launch! Price Authorities are a really exciting primitive, and I appreciate all of the work that has gone into this! :clap:

1 Like

Hardly diverting the conversation. Very much on topic, I’d say.

Note the folks most knowledge about the meat of your question about oracle operations aren’t immediately available to answer. Please stay tuned.

I just answered some of the other questions based on already published materials: code, whitepapers, etc.

1 Like

Ok cool, thank you again.

To clarify this question, is the process for adding an asset to the oracle network separate from adding an asset as a collateral type on vaults? I see oracleBrand is available on agoricNames on devnet (agd query vstorage data published.agoricNames.oracleBrand) that returns USD and ATOM, and a priceFeed namespace that returns ATOM-USD_price_feed (agd query vstorage data published.priceFeed.children).

If yes, is this also BLD’er governance / an envisioned governance flow? The use case I am thinking of is oracle support for other protocols building on Agoric, that may want to integrate assets not supported on Inter.

1 Like

Ah. Right. I have worked so much with the situation where an Oracle for X is in service to X as a collateral for Inter Protocol vaults that I read that into your question even though it wasn’t there. :slight_smile:

In general, changes to the Agoric chain are decided by the BLD stakers until they delegate to some other process. Each asset in the oracle network is a separate price aggregator contract. Starting such a contract has not been delegated to anything less than the BLD stakers.

We have experience and code (addAssetToVault.js) to support a BLD staker decision to “bring on another asset type for vaults, including starting an oracle contract” using swingset.CoreEval. But we could separate out the “start an oracle contract” part. Hang on… maybe we already did, in fact: price-feed-proposal.js.

We could try it out on devnet if you like. We should probably take the technical discussion to discord and/or github. Speaking of, one particular opportunity is to review a pull request for documentation on swingset.CoreEval:

2 Likes