[PASSED] OP-PIP-13 - Upgrade Blast Entropy Contract (Mainnet)

Abstract:
Upgrade the current Pyth oracle contract on Blast Mainnet to:

  1. Add a fee manager role that simplifies operations for randomness providers by letting their keeper wallet withdraw accrued fees
  2. Collect a share of the gas fees spent when interacting with Entropy

This PIP is the mainnet version of PIP 11: [PASSED] OP-PIP-11: Upgrade Blast Entropy Contract (Testnet)

Rationale:
Running an Entropy keeper should be easy. At the moment, there is a significant pain point in maintaining the wallet balance for the keeper, because the keeper isn’t authorized to withdraw fees from the contract to recoup it’s gas expenses.

The gas fee collection change is additional Pyth revenue generated from usage of the oracle by downstream at no extra cost to users — it’s paid out from the centralized sequencer revenue.

Description:
The first change in this proposal updates the Blast Mainnet Entropy contract to add a fee manager role. The fee manager is authorized by a provider to (1) set its fee, and (2) withdraw accrued fees. Providers can set the fee manager to their keeper wallet, which will enable their keeper service to better manage its gas.

The second change in this proposal updates the Blast Mainnet contract to enable gas fee claims (as part of sequencer revenue sharing of this protocol). After upgrading the contract to this version, anyone can call the newly added function to enable the gas fee sharing. A further contract upgrade can add functionality to withdraw the accrued gas fees.

Proposal: CP4kcXd5zLVaKzbf3N6N4D6y1w1BNpChMSKPd4SyYidU

Code changes:

branch: entropy_blast (the blast gas claim code is not merged into main because it’s a one-off that doesn’t fit in the generic smart contract)

Verification:

  1. Make sure you node-js and forge installed.
    a. node-js: install nvm from here
    b. forge: install it from here
  2. Clone pyth-crosschain repo
  3. Checkout the proposal code branch
  4. Run the following command from the root dir: npm ci && npx lerna run build
  5. Get the on-chain implementation code digest by going to the contract_manager directory and running this command: npx ts-node scripts/check_proposal.ts --cluster mainnet-beta --proposal <proposal id>
  6. Get the source code digest by going to the target_chains/ethereum/contracts and running npx truffle compile --all && cat build/contracts/EntropyUpgradable.json | jq -r .deployedBytecode | tr -d '\n' | cast keccak
  7. Match the of the on-chain digest with the source code digest.
  8. Both digests should also equal 0x00796fddbb5c438e486af88939daaaade9560d659124099113b05c9fb5c82fb1, which is the digest from the corresponding testnet proposal [PASSED] OP-PIP-11: Upgrade Blast Entropy Contract (Testnet)
6 Likes

gm gm Pythians

It was verified and signed on my end

Let’s make Entropy even better so we reach the skies

5 Likes

This is great! Entropy has gotten quite the traction on Blast with some protocols using it extensively.

2 Likes

I’m feeling ENTROPIC today! Let the world know that Pyth can do random numbers on top of price feeds

1 Like

I have a few questions about the terminologies, sorry if it is probably in the code. i dont know how to read them

In this case, who is the provider?
is it any protocol using Entropy?
and those accrued fees are also withdrawn by the protocol?

Read the docs about this and overview says this

Existing L2s like Optimism and Arbitrum keep sequencer fees for themselves. Blast redirects sequencer fees to the dapps that induced them, allowing smart contract developers to have an additional source of revenue.

dapps that induce them and smart contract developers = protocol using pyth?

to sum it up, this upgrade gives additional revenue from fees to protocols using Pyth Entropy?
(also same with the other proposal but without the 2nd part)

3 Likes

gm gm @bats4

I think it is important to understand the terminology to then understand the flow of actions

Entropy: the onchain protocol (owned by the Pyth DAO)

Entropy Provider: anyone that runs the off chain service to fulfill random generation requests

Entropy User: application that wants a secure random number onchain from Entropy

The protocols using Entropy usually just care about receiving a secure random number onchain — not so much from whom/where does it come.

However, Entropy was designed differently from other VRF protocols as it enables anyone to not only be a user of Entropy permissionlessly but also a provider.

A provider fulfills the request he receives from applications. The provider has to run offchain instances to make it work, and for this work the Provider is able to charge a fee to the application.

Above proposal is mostly about further improving the life of the provider.

Until now, the provider would have been able to withdraw its accrued rewards but to the same wallet. This upgrade enables the provider to delegate the rewards to another wallet (usually done for security/ops purposes).

One part I did not cover on the fees (or cost) is what is in it for the Pyth DAO? Like the price feeds, every time there’s an Entropy request fulfilled, the Pyth Entropy smart contract will accrue fees.

So in practice an Entropy user pays fees both to the Pyth DAO as well as the provider. And again an Entropy user can also be its own provider.

For the 2nd part of the Q on the gas kickback: it is similar to what was done to the price feeds couple months ago here: [PASSED] OP-PIP-1: Upgrade Blast Contract - #2

Blast like Mode give back 10 or 20% of the total gas used when interacting with a specific contract.

So if there’s like 1 ETH in total spent to interact with the Pyth Entropy contract, Blast would reallocate 0.1 or 0.2 ETH back to Entropy contract (akin to extra revenues).

This function was not included day-1 as the traction experienced nowadays was not expected but this is great!

3 Likes

thanks for the very easy to understand explanation!

and yes, i also was going for the questions, “What is in it for the Pyth DAO?”
thank you for answering that question too!

1 Like