Proposal: Add Trueflation to CPI calculation

The goal of this proposal is to stimulate a conversation about renovating the CPI oracle.

AMPL is designed to be a censorship resistant unit of account with a price targeting the inflation-adjusted 2019 dollar. The target price for AMPL is determined by oracles querying the Personal Consumption Expenditures (PCE) index from the U.S. Bureau of Economic Analysis (BEA). Currently we have three oracles -Ampleforth, Chainlink, and Tellor- which provide identical oracle rates from the PCE and are medianized to provide the single CPI oracle as seen on the Ampleforth oracle dashboard.

There have been several previous discussions in the Ampleforth Discord about methods to further decentralize or otherwise improve the CPI oracle. @Brandon made a strong case that the PCE is currently the most trusted and highest quality data for tracking consumer purchasing power, and that other options have previously not been available for AMPL to use. However, many community members like myself have expressed misgivings about the price target being solely reliant on an agency of the US government which may have perverse political incentives to artificially manipulate inflation values. Relying on a single data provider limits the decentralization of AMPL, as a single bad actor could potentially ruin the target price and damage AMPL’s reputation. The narrative of AMPL as a truly denationalized unit of account can only be strengthened by adding indices of inflation which are determined by free market actors rather than government agencies.

I have found what I believe to be an acceptable free market supplement to the PCE, which is the Trueflation index, powered by Chainink. Rather than go into an extended description of Trueflation here, I’ll just link their white paper, website, dashboard, and Chainlink market page. In summary, Trueflation aims to correct what it sees as issues with the Consumer Price Index (CPI) from the U.S. Bureau of Labor Statistics (BLS) and replace it with a “true” inflation index independent of possible political manipulation.

To add Trueflation to the CPI oracle, the DAO would need to set up:

  1. A contract to query the Trueflation oracle
  2. A normalization factor to scale it to the PCE
  3. A new medianizer function to combine PCE and Trueflation (optional)

Ampleforth already pays Chainlink for two oracle feeds, so this would be a relatively simple integration. The current Trueflation cost per query is 0.01 LINK, plus gas. This is a minimal addition to the current AMPL oracle costs, although there is always the possibility that they may raise their prices in the future.

Addition of Trueflation to the AMPL target price also opens a great opportunity for marketing during a period where inflation is a hot topic. A narrative promoting AMPL as an inflation-proof unit of account could be a powerful stimulus for AMPL adoption amid growing interest in algorithmic and inflation-proof stablecoins. Engagement with the Chainlink community and combined advertising with Trueflation could also stimulate renewed interest in AMPL.

Risks:
Trueflation is a new service and does not have a long-established track record of supplying on-chain data like the existing PCE oracle.
Trueflation increases the oracle “attack surface” of AMPL.
Any aberrant values from Trueflation could potentially skew the target price and lead to rebases which do not accurately reflect demand.
Trueflation currently reports higher inflation values than the PCE and this may lead to increasing divergence between the oracles over time.

I believe that these risks can be minimized by running a “trial period” for Trueflation on their Rinkeby testnet node for a period of at least 6 months before full adoption. We can monitor all of the on-chain data from Trueflation and review it after a few months to ensure that their reporting is reliable.

In terms of oracle “weight”, one option is to add Trueflation directly to the CPI pool, which would give it a weight of 1/4 in the medianizer. Because the three other oracles always report the same value, this would have no effect on the actual target price because the median will always be chosen from one of the PCE oracles. Instead, I propose that we create a new medianizer function which gives equal weight to Trueflation and the three PCE oracles combined, and takes the median of the two normalized values. This would also allow Ampleforth to integrate any additional free market inflation indices which may be created in the future.

Sustainability:
Funding for the Trueflation oracle can be added to the same allotment of Forth DAO treasury funds which are used to pay current oracle fees. These can be raised annually through the Forth mint function, or funds could be set aside for Link staking or yield farming to generate a self-sustaining supply of Link in order to pay for the oracles in perpetuity.

Conflicts of interest:
I currently own Chainlink tokens (14% of my crypto portfolio), however I don’t think this proposal will have any appreciable affect on Chainlink’s price given the relative market capitalizations of AMPL and Chainlink. I have no other associations with Trueflation or Chainlink.

I welcome any feedback or criticism in the spirit of making AMPL more robust.

8 Likes

Big fan of Trueflation and what they’re working on.

I would support this proposal if escalated to a Signal vote.

1 Like

Great proposal ducc, sounds like a great idea. A test run at the very least wouldn’t hurt at all.

Great proposal!

A few notes:

As pointed out in the proposal, this would make Ampleforth less resilient against Oracle failures. If Chainlink’s Trueflation oracle would deliver faulty values they would be taking into the price target computation nevertheless. This does not happen in the current oracle architecture, in which at least 2 of 3 oracles would need to deliver faulty values.

I have to say I do not like the idea of Ampleforth being so dependent on Chainlink, or for that matter on any single oracle provider. With two different oracle providers, Ampleforth can at least use the average and dampen the effect of faulty values.

Q: Would it be feasible for the Team to run its own Trueflation oracle or does anyone know whether Tellor plans on providing a Trueflation oracle too?

So we would add a second layer to the current oracle architecture, which would then look like this:

CPI Value = Median(
  Median(PCE_Oracle1, PCE_Oracle2, PCE_Oracle3), 
  Median(Trueflation_Oracle1, ...), 
  ...
)

I’m definitely in favor of upgrading the architecture to be able to support different inflation indexes!

I like the time horizon. While I do support the proposal, I do not think there is too much time pressure. Ampleforth’s price target calculation is the heart of the protocol and updates should not be implemented in a rush.

3 Likes

Thanks pascal, I largely agree. I think it will be awkward moving from one data source with three providers to two data sources with four providers, no matter how it is structured.

It’s important to note that Trueflation and the Chainlink CPI oracle network are two distinct data providers that both use the Chainlink code architecture, so I don’t think it’s fair to say we’re becoming “overly reliant” on Chainlink. They are independent from a data supply perspective. One could argue that both Chainlink data feeds are potentially vulnerable to similar code exploits but Chainlink’s code is open source and has been thoroughly battle tested.

I hope we would eventually onboard a third inflation index which would provide a lot more resiliency to a median function. However, we can also be comforted by the fact that AMPL long relied on only two data providers for both its target price and CPI oracle and it never experienced serious disruption to either. Which is not to say it can’t happen, but I view it as relatively unlikely.

I see this proposal as a marginal improvement which puts us on a trajectory away from government-controlled data towards free market data, and certainly not a final state for the protocol.

2 Likes

Totally agree. Well put :100:

The problem I wanted to raise was not about Chainlink itself, but rather the usage of just one oracle for the Trueflation value. This single value would always (as long as no additional oracle of any sort is introduced) be part of the average calculation for the price target.

The recent introduction of Tellor as a third oracle increased Ample’s oracle decentralization and the security of the price target calculation. By adding a single Trueflation oracle with a “higher” priority, the inflation data quality increases (Note: This is an assumption, I do not understand enough of CPI calculations to be sure about this) but the resilience against faulty values decrease back to the point when Ample used “only” 2 oracles.

I agree. Just wanted to have stated my concerns. I totally support starting to work on a testnet trial :100:

1 Like

Some more context and open questions I want to add to the discussion:

1. Should Ampleforth define its own inflation index?

Currently, Ampleforth uses the PCE as the inflation index. By adding some other index, such as Trueflation, Ampleforth would effectively start to define its own inflation index. The current proposal seeks to define Ample’s inflation index as average(PCE, Trueflation) (Note that the median of two values is the average).

Independent of the indexes themselves, I think it should be carefully considered whether Ample should define an own inflation index instead of always using “the best one”.

One challenge for creating an own index is how well it can be defined.
If Ample’s inflation index is composed of two (or more) other indexes, what should be done in case one of the index’s values fetched on-chain is provable faulty, e.g. stale?

  • Falling back to only using the other index could lead to sudden heavy price target changes that could disrupt markets.
  • Not executing the rebase, as Ampleforth currently does if the oracle data is invalid, would decrease the protocol’s resilience because the probability of invalid oracle data only increases with every new index added.
  • Using the last known correct value for the missing index would lead to a supply adjustment that’s not “correct”. The protocol would adjust the supply based on the heuristic that the last cached value did not change “too much” in comparison to the current real value. One could argue that this approach does not follow Unix’s idea of “fail fast”.

2. How should an update to Ampleforth’s inflation index be introduced?

Assuming an update introducing a new inflation index would lead to a “heavy” change in the price target, how should such an update be introduced.

A sudden change to Ample’s price target could disrupt markets, e.g.

  • Already materialized interest rates through Buttonwood’s Mooncake lending market would be retroactively changed.
Correct?

At least I think so because the stables received through selling A-Tranches would not be enough to re-purchase the same number of A-tranches - already paid interest rate leading to an effectively new interest rate? Please correct me if I’m wrong.

  • SPOT’s peg stability would be disturbed as SPOT would need to adjust to the sudden “heavy” price target change.
  • “Ample borrows like a stablecoin” would be broken for borrowers having open debt in the Aave lending market during the update.

I guess the easiest way would be to introduce the new index over time by slowly increasing the index’s weight in the computation. This would smoothen the price target change over some time. However, this would also introduce new lending-borrowing strategies/games because the “upcoming inflation” would be (more accurately) computable.

3. The Trueflation API is not publicly accessible (link)

This means Ample (for as long as Trueflation’s daily updated data is private) could not utilize any other oracles providing the Trueflation value. This makes the Trueflation index arguably less decentralized than PCE, for which Ampleforth managed to utilize three different oracles.

Other stuff:

  • Trueflation’s Ethereum mainnet oracle handheld 5 data requests so far (link). The contract is not verified on Etherscan.

  • The only Ethereum testnet version of Trueflation is on Rinkeby. Ample’s Rinkeby contract seems to be defunct, see GitHub Issue.

  • Ampleforth’s MedianOracle implementation supports defining a time that has to pass before an oracle report is usable (see here). This time buffer could be utilized by monitoring tools to react to “unreasonable” Trueflation values. The CPI oracle’s current time delay is 24 hours, the market’s oracle 1 hour (check the reportDelaySec field on the contract page).

I don’t think your concern about the immediate change in price target is founded. When we apply the normalization factor to Trueflation to scale it to the CPE, we just set the first value reported by Trueflation as equivalent. Normalization takes care of that. So you’d start with the same target price but over time you’d evolve a discrepancy between Trueflation and the CPE, and AMPL would take the average value. The target price would only change gradually over time, and we could also limit the number of oracle updates from Trueflation to match the CPE publication so everyone knows when the target price is expected to update. That addresses your concern about platforms that depend on a reliable target price like Mooncake.

I’m more concerned about what you mentioned where if one oracle fails to report, you would get a rapid change in target price. I think there need to be more safeguards to ensure that we have two fresh values that are in line with reasonable expectations. Unfortunately I’m not a solidity coder so the best I can do is ask the more technical people their suggestions.

I disagree that the PCE is more decentralized than Trueflation just because there are three oracle providers passing along what the API reports. Neither is decentralized because each oracle originates from a single data provider. The PCE oracle has redundancy, not decentralization. Trueflation has no redundancy. Decentralization of the oracle would come from combining multiple data sources, which is what this proposal is attempting to start.

And although this is beyond the scope of this proposal, I’d love to see Ampleforth create or fund the development of its own CPI oracle to provide more protection of the target price.

You are right. Introducing a new index that is normalized to Ample’s current inflation index does not introduce heavy price target changes.

But removing an index would still do, correct? (Assuming a long enough time frame in which the indexes drifted apart)

It’s impossible to have a 100% assurance that each index value will always be there when needed. I’ll strongly advocate having well-defined failure modes if data is missing.

I think that’s what we are doing here already by adding a second index!

The CPI value received by Ample’s supply policy, which calculates the price target and the rebase’s supply delta, will be a new “Ampleforth Inflation Index” as soon as it’s not only the PCE anymore. The difference may not be significant in the beginning, due to Trueflation and PCE not drifting further apart too fast, but over a long enough timeframe the proposed CPI value will become unique.