Inter Protocol Vaults: Contract Implementations

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!


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?



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.


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.


Validatrium supports cost and time efficient approach


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



We ( 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.


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:


The Mainnet 1B release is now available and a separate thread has been created for discussion around testing and milestones.

1 Like

Hey, I’d like to chime in as one of the people working on coordinating the oracle network supporting IST’s vaults. Responding to your questions below:

  1. The oracle solution does not in any way use an existing official Chainlink feed, and instead uses the open source Chainlink software to submit prices to aggregator smart contracts on Agoric. The contracts cannot be changed by any admin user, only governance. The oracle set is initially a set of 5 Agoric validators who are also experienced in Chainlink node operation on other networks.

Each node operator queries a set of API providers on their backend, and they all submit their median price to each round of the data feed. New rounds are triggered either after 10 mins of inactivity or if a node operator has detected a 1% deviation off chain. We’ve distributed the various API providers across the set of oracle operators, so as to have the least overlap possible, to minimise API provider risk.

2-3. There are talks ongoing to ensure the oracle feed for liquid staked tokens are as robust as possible.

  1. Currently our team at Simply Staking is coordinating the bootstrapping of the oracle network set, maintaining the software and working as a manager of the oracle network (we do not have any on-chain powers, just off-chain coordination, dev work, monitoring/alerting and support).

We are currently in this position as we feel it is critical to ensure the stability and quality of the feeds being used for IST, after many years working on official Chainlink feeds.

The software being used is all open source and documented, being the Chainlink node, monitoring software for the oracle operators and the custom Agoric<>Chainlink middleware. In the long term, it is in the best interest of the network to have a more decentralised approach to oracle set maintenance and monitoring, so we’re happy to support this direction. We’re doing our utmost to upkeep documentation and share knowledge to the other oracle operators.



I am Jacques from Simply Staking.
As Simply Staking, we are responsible for monitoring the overall oracle network, including other node operators’ performances and behaviours. To facilitate this task effectively, we have established formal agreements and Service Level Agreements (SLAs) with each individual node operator, outlining their respective requirements and obligations.

I hope this clarifies your question and please feel free to ask any further questions that may arise.

Have a nice day,


Following up on this, oracle operators are expected to have an uptime of 99.9%, and can have up to 10% of their rewards deducted should they not meet this SLA. Repeated breaches and loss in quality of their contribution to the data feeds, will result in the Agoric Committee recommending for them to be replaced.

The committee has in depth monitoring dashboards on data feeds to take these decisions, supported by us when required.