Hello everyone, Hi @coinflipcanda
Marcin from RedStone Oracles here. First of all, great to see GMX improving and tackling the most pressing problems in the V2 update. Our team is glad to see in the comments a factual discussion about Chainlink alternatives - it shows that the market is mature enough for diversity.
Monopolies are never good for innovation and can lead to groupthink, which is detrimental to the security, especially in such a distributed space as Web3.
We are strongly convinced that GMX needs to consider more than just one oracle to take the best possible decision in terms of sustainable long-term development and protocolās leading position in the competitive perpetuals market.
The aim of this comment is to:
- Amplify for the GMX Community that Chainlink is not āthe only possible solutionā.
- Bring awareness that the total price of 1.2% for GMX will possibly be a huge absolute number and the proposal does not mention anything about gas costs.
- Support the discussion about the possible oracle options and suggest transparent & public benchmarking of possible incumbents including Chainlink, Pyth and RedStone.
- Signify RedStoneās readiness to support the GMX DAO as a primary oracle, support requested assets (esp. These that Chainlink canāt deliver in a timely manner) and cooperate shoulder-to-shoulder with the GMX Core Contributors to provide all necessary input for them to make the most optimal decision regarding oracles going forward.
RedStone X for Perpetuals
RedStone Oracles disrupts the space with Modular design, providing 3 data consumption models. For Perpetuals (and specifically having GMXās architecture in mind) we have designed:
RedStone X model (No Front-running): targeting the needs of the most advanced DeFi protocols by eliminating the front-running risk through offsetting the delay between the userās interaction and the Oracle price update. Here is a high-level overview of how that works:
This model introduces No-latency - there is no delay between the Userās request and the oracle price hence there is no possibility of frontrunning the Userās transaction. Our infrastructure asks retroactively: what was the price for the underlying asset at the exact timestamp when the Request has been submitted?
Then it pushes the price with the timestamp back to the dApp to settle the position in the very next block.
Why RedStone Oracles
RedStone is well positioned as an alternative to Chainlink for GMX, here is why:
-
RedStone is āTheā On-Demand Oracle - we have been promoting the on-demand model narrative and developing our solution for the past 2 years and we know very well that the implementation of such a model is far from trivial.
-
RedStone has been developed & tested since Dec 2020, on mainnet since March 2022, well audited and securing real funds. Along the way we had to solve countless tech challenges (i.e. Assembly-level optimisation of costs), so we are confident that our implementation is the most technologically advanced if it comes to the on-demand oracle model.
-
Our flow is designed to be maximally cost-efficient - happy to provide benchmarks vs other oracles on that front.
-
DeFi ecosystem is built on the premise of being decentralised & permissionless. Looking at factors limiting the decentralisation of Oracles such as governance of āultimateā multisig or full control over the off-chain component, we designed the RedStone ecosystem, so that it can operate under any circumstances.
-
A protocol using RedStone Oracle has full clarity and transparency in terms of data sources and origins of consumed price feeds - as opposed to the black box offered by some of the popular incumbents. Moreover, we give dApps creators a spectrum of customisation options regarding off-chain and on-chain aggregation methods, as well as picking Data Providers they trust.
On top of that, RedStone = working shoulder-to-shoulder with builders.
We collaborate hands-on with our Partners to come up with an optimal solution for their specific use case, customising many parameters such as:
- data aggregation mechanisms,
- data injection to the chain,
- custom flows of liquidation/opening a position etc.
We are fully committed to building an entirely dedicated solution for GMX including risk mitigation mechanisms, backtesting analysis and other very custom forms of implementation. Additionally, we are willing to be in close contact with and at disposal of GMX risk analysis partners.
Conclusion
As we have seen - the discussion about implementing Chainlink is not unanimous. We are convinced that in order to make the best possible decision Core Contributors should consider more than just one option. We would be happy to work closely with @coinflipcanda @xdev_10 and the whole team to provide all necessary data and other inputs to build benchmarks so that both oracle solutions could be tested thoroughly and transparently in terms of update and maintenance costs, long-term sustainability, security measures, transparency etc.
Also, if we were to propose the next step in this discussion we would suggest that each oracle provider prepares a testnet POC for benchmarking purposes to gather data and see which oracle solution would be best suited for the GMX-specific needs.
End Note: Our sincere apologies for submitting this comment only now. A large part of the discussion took place over the Easter Holidays, therefore we wanted to get involved once our team is back from family tables.
