feat(pulse): keeper payment #2617
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
4 Skipped Deployments
|
| priceIds, | ||
| minPublishTime, | ||
| maxPublishTime | ||
| curTime > PAST_TIMESTAMP_MAX_VALIDITY_PERIOD |
There was a problem hiding this comment.
had to inline this (and extract logic into helper functions) to avoid stack depth issues
| // Update status and pay keeper | ||
| status.balanceInWei -= totalFee; | ||
| status.totalSpent += totalFee; | ||
| (bool sent, ) = msg.sender.call{value: totalKeeperFee}(""); // Pay only the keeper portion |
There was a problem hiding this comment.
just double check that we have updated the state everywhere (to make sure there's no double entry attack)
There was a problem hiding this comment.
I better implemented the checks-effects-interactions pattern. Now we apply it independently to the pyth fee and the keeper fee. This keeps accounting accurate if either of the payments fail.
| uint64 public constant FUTURE_TIMESTAMP_MAX_VALIDITY_PERIOD = 10 seconds; | ||
| /// Fixed gas overhead component used in keeper fee calculation. | ||
| /// This is a rough estimate of the tx overhead for a keeper to call updatePriceFeeds. | ||
| uint256 public constant GAS_OVERHEAD = 30000; |
There was a problem hiding this comment.
How did you get to this number?
There was a problem hiding this comment.
It's a rough estimate, we will probably want to set it per blockchain. The idea was to capture the gas used before the first gasleft() call, which would be the flat 21k gas for an external contract call, ~2.6k for the proxy's delegatecall, and some for the calldata. We can measure it more carefully when we do the math to ensure our pricing model works.
Summary
Add keeper payment in
updatePriceFeedsRationale
Keepers are permissionless and we pay them in-band if they successfully call
updatePriceFeeds. If the trigger condition isn't satisfied or the subscription doesn't have enough funds, they won't get paid.This is a temporary payment model, the long term goal is to add a monthly subscription to make it easy for users to consume the service, rather than keeping their balance topped up. However, the basic mechanism of paying the keeper for successful updates will be the same, just the fee calculation will change.
How has this been tested?