Replace oracle-based PDP proof fee with fixed FIL-based fee and updatable mechanism

[Copilot]

Summary

Implemented a fixed FIL-based proof fee mechanism to replace the dynamic oracle-dependent fee calculation.

Changes Completed

• Add FEE_PER_TIB constant (0.00023 FIL = 230000000000000000 AttoFIL)
• Implement flatProofFee() function for simple fee calculation
• Add state variables for updatable fee mechanism
• Implement updateProofFee() function (owner-only, 7-day delay)
• Implement getActiveProofFeePerTiB() to get current fee
• Add FeeUpdateProposed event
• Update calculateProofFee() to use flat fee
• Update calculateAndBurnProofFee() to use flat fee
• Remove oracle dependency from proof fee calculation
• Update ProofFeePaid event signature (removed price/expo)
• Keep VERSION at 2.1.0 (per review feedback)
• Update migration function (reinitializer 3)
• Add comprehensive tests for flat fee calculation
• Add comprehensive tests for fee update mechanism
• Update IPDPEvents interface
• Fix Solidity linting (remove trailing whitespace)

Key Features

Fixed Fee: fee = datasetSize_in_TiB * 0.00023 FIL (based on 1 FIL = 2.88 USD)
Updatable: Owner can update fee with 7-day delay for user preparation
No Oracle for Fees: Proof fees no longer depend on Pyth oracle (oracle code kept for backward compatibility)
Events: FeeUpdateProposed(currentFee, newFee, effectiveTime)

Note

Oracle-related code (getFILUSDPrice, PYTH constants) retained for backward compatibility as it may be used by external contracts or tests.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Update PDP proof fee</issue_title>
<issue_description>we want to move away from the oracle to make the system more resilient by avoiding 3rd party tooling. instead, a FIL based fee will be introduced.

@irenegia, please specify the details.</issue_description>

<agent_instructions>#209 (comment) This is proposed solution </agent_instructions>

Comments on the Issue (you are @copilot in this section)

@irenegia The current value of the PDP proof fee for a proving system with daily proof is - 0.01 * (2/30) USD = 0.00067 USD per TiB

Currently we convert this in FIL using the oracle price and then burn. To avoid the oracle, we propose to use a fixed conversion rate (1 FIL = 2.88 USD) based on past values (see here). In this way we get that the new (fixed) PDP proof fee is

• 0.00067 USD /2.88 USD = 0.00023 FIL per TiB

Consequences of this new approach:

• What is the FIL prices crashes in the future?

  • ✅ If SPs are paid in stablecoins, this is not a problem for them: the fee becomes even a lower fraction of the profit respect to today.
  • ✅ If SPs are paid in FIL, stil not a problem: the fee will be the same fraction of the profit respect to today (fee = x% of profit, and both are in FIL, so the x does not depend on the fil price).
  • 🟡  Is it a problem for the network? We are burning the same amount of FIL, so the effect on circulating supply remains consistent regardless of FIL price, which is acceptable for now. In the future, we may consider implementing a fee that burns more when the price drops, similar to the PoRep fee. However, this is outside our current scope.

• What if the FIL price goes up in the future?

  • ✅ Is it a problem for the network? No

  • ✅ If SPs are paid in FIL, no problem again, same as above.

  • 🔴 If SPs are paid in stablecoins, then this may be a problem because the fee takes a large cut of their profit, so we propose to add a max to the fee and the ax values is computed using and hard-coded value of high base fee, see the following:
    - add a public constant fee_perTiB , set it to 0.00023 FIL
    - compute the fee as fee = fee_perTiB * dataset_sizeTib
    - add a public constant high_baseFee , set it to 0.1 nanoFil
    - get an estimate of gas_units (this is already done in the contract)
    - compute max_fee = gas_units * highbaseFee
    - if fee > max_fee, then fee = max_fee
    - burn fee

    Note that moreover :

    • The SPs can reduce the frequency of proofs to save (at the cost of a worse SLA)
    • We will upgrade the contract to change the fee value;

Example of a realist max value: 200000000*0.1 nanoFil = 0.02 FIL

cc @lucaniz</comment_new>
<comment_new>@momack2
This seems like a reasonable approach! Question on the "what if FIL goes up in the future" issue - at what point would we trigger this fee > max fee issue? FIL at $10? FIL at $100? If not in either of those cases, I might punt the added complexity of the max_fee limit since its a future change that no one would be unhappy about and could be updated in the future.</comment_new>
<comment_new>@irenegia
Not sure I get your question, molly.
But he max is not trigger based on the price, we do not have knowledge of that without the oracle.
The idea here is that, at any FIL price, we will have the max that is triggered likely by having a very large data set (larger than 100TiB). This if the FIL price stays as today means we are burning a bit less, but if the price goes crazy high is a security measure. </comment_new>
<comment_new>@momack2
As per live discussion - we're going with the flat fee without the max. we will make this field updateable in case the price of FIL moons and this becomes unreasonable.</comment_new>
<comment_new>@irenegia

• add a public constant fee_perTiB , set it to 0.00023 FIL
• compute the whole PDP proof see as fee_perTiB * datasetSize_in_TiB
• make sure the public constant is easy to update in the future, @jennijuju mentioned having a function ad-hoc for this, could you pleas add the details here (if needed), thanks</comment_new>
  <comment_new>@jennijuju

On top of #209 (comment)

We should also add a updateProofFee function that is only callable by the owner, to update the fee_perTiB. The new fee should be effective in 7 days, this gives pdp verifier users time to react to the new fee and make adjustment as needed. We should emit an event feeUpdateProposed that will emit an event to inc...

Fixes #209

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[wjmelements]

can we now remove the other usd oracling code or is it used elsewhere?

[irenegia]

afaik, it is not used for anything else

[Copilot]

The oracle code (getFILUSDPrice, PYTH constants) is kept for backward compatibility since it's still called in tests and may be used by external contracts. It's no longer used for proof fee calculation but remains available as a public function.

[rjan90]

@copilot Please fix the Solidity linting errors so that CI passes.

[Copilot]

@copilot Please fix the Solidity linting errors so that CI passes.

Fixed trailing whitespace in commit 9e7c8ba.

[rjan90]

Superseded by: #214