AMPL Rebase Analytics

What is the Target Price?

The target price is AMPL's oracle-calculated fair value based on the Personal Consumption Expenditures (PCE) index. It represents the purchasing power equivalent of the 2019 USD, ensuring AMPL maintains constant real value over time.

How is it Calculated?

The target price uses a simple ratio formula:

Important: AMPL is NOT pegged to inflation

PCE is simply used as a measuring stick to ensure constant unit value through time. There is no "peg" to CPI, inflation, or PCE specifically. The protocol is designed to maintain purchasing power parity with the 2019 USD, independent even of fiat currency movements.

Impact on rebases:

• When AMPL price > Target → Positive rebases (supply expands)
• When AMPL price < Target → Negative rebases (supply contracts)
• When AMPL price ≈ Target → Equilibrium (no rebase)

About PCE:

The Personal Consumption Expenditures Price Index (PCE) is a measure of the prices that people living in the United States pay for goods and services. It's produced by the Bureau of Economic Analysis (BEA), which is part of the U.S. Department of Commerce.

How Often is PCE Updated?

• Monthly releases: Published at the end of each month
• Oracle updates: AMPL's oracle consumes new PCE data and updates the target
• Timing quirks: Due to how the oracle system works, sometimes the target updates twice in consecutive days at month-end

Why PCE vs CPI?

While similar to the Consumer Price Index (CPI), PCE has some advantages:

• Broader coverage of household spending
• Accounts for substitution (people switching to cheaper alternatives)
• Preferred by the Federal Reserve for inflation targeting

What Happened:

In 2023, the Bureau of Economic Analysis conducted a comprehensive revision of PCE data going back to before AMPL's launch in July 2019. This wasn't just a small adjustment - all values over this timespan were scaled down.

The Smart Contract Problem:

When AMPL launched, the base PCE value (109.195) was hardcoded into the immutable Policy smart contract. This seemed reasonable at the time, but created a challenge when the BEA revised historical data:

• What the target should be: (120.550 / 103.422) = $1.16
• What the protocol calculated: (120.550 / 109.195) = $1.10
• Discrepancy: ~$0.06 (5.5% error)

The Solution:

Rather than accept this permanent discrepancy, the AMPL team proposed:

• Remove the baseCpi constant from the immutable Policy contract
• Add a governable scaling factor to the CPI oracle (on the protocol's periphery)
• Update the scaling factor to align with revised BEA data
• This insulates the core Policy contract from future oracle changes

Lessons Learned:

This event highlighted the challenges of using real-world data sources in immutable smart contracts. It also demonstrated AMPL's governance flexibility - being able to adapt the protocol's periphery (oracles) while keeping the core policy logic untouched.

Understanding the Toggle:

The "BEA Revised" toggle in the Historical Data Table lets you compare original vs. revised PCE values for each rebase event.

What You See When You Toggle:

Why the Target Doesn't Change:

You'll notice that when you toggle the CPI values, the Target price stays the same. This is intentional and correct because:

• The table shows historical snapshots - what actually happened at each rebase
• The target value shown is what the protocol actually calculated and used at that moment in time
• Changing historical targets retroactively would be misleading
• The discrepancy between original and revised CPI is the story itself - it shows the magnitude of the BEA revision's impact

What This Data Reveals:

• Consistency of revisions: Were all periods revised equally, or were some adjusted more than others?
• Timing of impact: When did the original vs. revised values diverge most significantly?
• Protocol accuracy: How close was AMPL's target to what it "should have been" with perfect data?

For Data Analysts:

The ability to toggle between original and revised CPI makes this table valuable for:

• Auditing the protocol's historical behavior
• Understanding the real-world challenges of oracle-dependent systems
• Quantifying the impact of BEA data revisions on AMPL's target calculation
• Educating users about why oracle governance and flexibility matters

Why Multiple Updates Per Month?

If you look at the Target Change History table above, you'll notice the target typically updates 1-2 times per month, with updates clustering around the end of the month. Sometimes you'll see 3-4 updates in a single month. This pattern is by design.

Update Frequency Rules:

The smart contract enforces specific constraints on how often providers can update:

• Report delay: 28 days minimum between updates from the same provider
• Report expiration: 93 days after which data is considered stale
• In practice, this means no more frequent than once every 28 days per provider

Security Design (Updated August 2024):

As of Proposal ID 30 (August 10, 2024), the oracle implements a 28-day security delay before using PCE data. This means the oracle uses CPI data that is lagging by approximately 1 month.

System Resilience:

• Two independent providers: Redundancy ensures the oracle continues functioning if one provider fails
• Median function: Can't be manipulated by a single compromised provider
• Expiration mechanism: Ensures data doesn't go stale (93-day maximum age)
• Minimum delay: Prevents spam attacks or rapid manipulation attempts