feat(pulse): add pulse contracts #2090
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
target_chains/ethereum/contracts/contracts/pulse/PulseErrors.sol
Outdated
Show resolved
Hide resolved
target_chains/ethereum/contracts/contracts/pulse/PulseState.sol
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
As we've discussed before, having provider doesn't make much sense for the Pulse and it seems that this code is very centered towards different providers (from requesting one, updating, separate fees, ...). I think the options are either 1) allow all providers to fullfill a request 2) remove providers entirely and make it permissionless.
yeah this makes sense, I have gone with option 2 and removed providers entirely |
| uint256 callbackGasLimit | ||
| ) external view returns (uint128 feeAmount); | ||
|
|
||
| function getPythFeeInWei() external view returns (uint128 pythFeeInWei); |
| _state.pyth = pythAddress; | ||
| _state.currentSequenceNumber = 1; | ||
|
|
||
| if (prefillRequestStorage) { |
| function executeCallback( | ||
| uint64 sequenceNumber, | ||
| bytes[] calldata updateData, | ||
| bytes32[] calldata priceIds |
There was a problem hiding this comment.
Hmm thinking about it, now that we don't emit the ids and don't store them (we store the hash of it), how argus is supposed to understand it :? parse the transactions?
| ); | ||
|
|
||
| // Check if enough gas remains for the callback | ||
| if (gasleft() < req.callbackGasLimit) { |
There was a problem hiding this comment.
I recommend allocating an extra overhead for cross-contract calls.
| clearRequest(sequenceNumber); | ||
| } | ||
|
|
||
| function emitPriceUpdate( |
There was a problem hiding this comment.
It's good to emit something (for debugging purposes), just be aware that it might be expensive to do this in ethereum mainnet.
| function getFee( | ||
| uint256 callbackGasLimit | ||
| ) public view override returns (uint128 feeAmount) { | ||
| uint128 baseFee = _state.pythFeeInWei; | ||
| uint256 gasFee = callbackGasLimit * tx.gasprice; | ||
| feeAmount = baseFee + SafeCast.toUint128(gasFee); | ||
| } |
There was a problem hiding this comment.
I'm wondering how this works in Entropy. Do we update pythFee regularly based on gasPrice? @m30m might know better but similar products charge fee as % of the tx fee.
There was a problem hiding this comment.
There is also one DoS attack vector in our price feeds use case regarding gas prices. People can ask for price updates anytime in the future and it won't be fullfilled immediately (opposed to Entropy) and this might make tx.gasprice a worse estimate on normal usage (only a few seconds after that) or can be taken advantage of to make hundreds of requests in the future when the gas price is lower.
My recommendation is to not allow a publish time that is more than 1min in the future. Or charge higher fees as it goes more into the future.
No description provided.