Proposal: Add Trueflation to CPI calculation

[ducc]

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.

[Guz_MassAdoption]

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

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

[sunbreather]

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

[pascal-merkleplant]

Great proposal!

A few notes:

@ducc

a new medianizer function which gives equal weight to Trueflation and the three PCE oracles combined

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?

@ducc

and takes the median of the two normalized values

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!

@ducc

running a “trial period” for Trueflation […] of at least 6 months before full adoption

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.

[ducc]

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.

[pascal-merkleplant]

@ducc

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

Totally agree. Well put

@ducc

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

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.

@ducc

AMPL long relied on only two data providers for both its target price and CPI oracle and it never experienced serious disruption to either

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

[pascal-merkleplant]

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).

[ducc]

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.

[pascal-merkleplant]

@ducc

Normalization takes care of that.

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)

@ducc

I think there need to be more safeguards to ensure that we have two fresh values that are in line with reasonable expectations.

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.

@ducc

Ampleforth create or fund the development of its own CPI oracle

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.

[Richard_Meng]

I agree, Kudos to @ducc ! We do need multiple data resources to avoid potential risks.

[Brandon]

Love to see this discussion, thanks @ducc.

We currently use the PCE but I don’t think anyone would say we have any particular allegiance to it. We just care about getting some measure of stable value, denominated in a currency of today, through time.

The price target is computed in the Supply Policy, and it uses a base value in the PCE system in order to do so: ampleforth-contracts/UFragmentsPolicy.sol at 0de7c94d884491c9f0f93cd6643aa05c73257a84 · ampleforth/ampleforth-contracts · GitHub

If we start incorporating other sources, I could see taking a page from @pascal-merkleplant 's playbook and moving away from the “PCE domain space”. I might suggest translating each individual metric into “2019 dollar space”. So we’d have a “PCE → 2019 dollar value today” function, and a “Truflation → 2019 dollar value today” function, then upgrade the code to work with those.

They could match on launch day, but we should expect these two measures will diverge over time in some fashion. So no matter what, I think we will eventually run into the problem of sudden price target changes if one of the measures is a no-show.

If we start fudging the translation function over time based on divergence, then we lose the signal from the added data feed. We can add logic to try to be smart about it, like reusing old values if one is missing, but that adds some more subjectivity. So it’s possible, but requires some explicit design decisions and is not an automatic drop-in type project.

To help clarify some of the framing here, I see two distinct axes of “decentralization”.

Decentralizing the data sources, which helps remove trust on particular agencies like the BEA.
Decentralizing the data delivery method, which helps reduce trust on Chainlink, Tellor, or other providers.

It sounds like Truflation helps with one axis (data source), but not necessarily in the other (delivery). This is a design tradeoff.

On a somewhat higher level… I’m not personally too concerned with potential political influences hurting the PCE data quality right now. I think it’s true that it probably understates the cost of living in the US by not incorporating US Health care, US cost of Education, or cost of oil, for example. But Ampleforth has a more global context, and these are actually good things as they are now.

I don’t think it really matters that the price target is “The 2019 US Dollar”. It could just as easily be 0.97 2019 Euros. It only matters if it’s “stable enough” to be useful for denominating contracts. If oracle measurement diverges from an accurate measure of the 2019 dollar, but it happens very slowly over time, no big deal. It’s still probably more stable than fiat currencies or a basket of commodities, which is an interesting option that doesn’t rely on any authorities.

[srust99]

at truflation we are now aggregating on a daily basis price information and changes across 18M items from 40+ different sources and make this available on ETH, AVAX, BNB and MATIC. Would love to engage and see how we can support this initiative.

[dayiel]

Hi all, I’m joining on behalf of Truflation to answer your questions and see if we can deliver what you need to diversify your index .

We do a lot of customization and work on new forms of data distribution (API) and subscription models.

• We can benchmark the index to 2019.

• We can offer you a custom API rather than go through Chainlink if it is an important factor for Ampleforth’s resilience

• Our devs can help your admins test the historical data and discuss options for gradual incorporation.

You can contact our dev Joseph Wang on Truflation Discord or TG (@joequant)
And also discuss stable montly subscription pricing with our biz dev Kalcel (@kalcel on TG).

Let me also paste an answer from Joseph to some of the discussion points:

"Thanks for the feedback. We are putting a great deal of effort in
using the truflation infrastructure available to new developers.
Because we are very active at incorporating new features, responding
to feedback from users, and taking advantage of new technology, our
software has been rapidly advancing.

Also because we are rapidly introducing new features, our
documentation can become rapidly out of date, and copies of obsolete
documentation and information may exist in the web.

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

All contracts for truflation consist of verified contracts on
etherscan. Our mainnet oracle has not had very much traffic yet,
but we are working with partners and developers to increase
traffic and usage of mainnet, and would be very happy to support
new users.

The list of supported network is available at

https://github.com/truflation/quickstart/blob/main/network.md

Our contracts are available throughout several mainnets, and in
talking with partners we have found more interest in our BSC and
polygon networks than ethereum mainnet. However, the level of
interest may change after the ethereum Merge.

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

The truflation oracle supports a large number of testnets, and
our data is available through any network which is supported by
chainlink.

Our example code was originally developed on rinkleby, but we are
moving to goerli as our main testnet.

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).

We think that this functionality can easily be supported by our
oracle system."

[Brandon]

Thanks for dropping in @srust99 and @dayiel, it’s very encouraging to see proactive support.

I’d love to explore this more when the time is right. The genesis team is currently occupied with the rollout of SPOT. However, it doesn’t need to block on any one team. If anyone else in the community is motivated and wants to help push this forward that can still happen, perhaps funded through a DAO grant.

[srust99]

thank you for the feedback Brandon. What would next steps look like working with the DAO and securing a grant to support the outline above? We would love to validate this further, engage the community and convert this into reality, hopefully with the DAO grant? thank you

[srust99]

Is this a good time to circle back around on this question?