API3 data feeds are built to be updatable by RRP (request–response protocol), relayed RRP, PSP (publish–subscribe protocol), relayed PSP and Airnode-signed data. The Airnode protocols are optimized for EVM, which makes them very difficult to port to non-EVM chains. For example, the requester pays for all gas costs in the Airnode protocol based on an HD wallet scheme, yet this is not directly translatable to NEAR, where accounts need to be created actively. One can redesign the protocol around the prepaid gas scheme for the same effect, yet this would require a very significant investment of development resources. In general, if the chain doesn’t run vanilla EVM, it’s safe to expect this kind of a gotcha.
As a solution, I stripped off the RRP and PSP-related update options from the data feed contracts, and came up with a version that only uses Airnode-signed data. The signed data is still served by an Airnode (so it’s first-party) and uses the same API integrations and request specification format, but it can be thought of as being slimmer than RRP and PSP (in that it doesn’t care how the signed data is delivered to the chain for example). The resulting contract is much more simpler and feasibly portable to non-EVM chains with little effort, which means being able to get API3 data feeds on all chains in a practical way.
We commissioned the porting of this contract for NEAR and Solana to ChainSafe, with me acting as the client since I’ve developed the original contract and the stripped down version. After a reduction (due to reasons that would warrant a whole other post), the project budget ended up being a total of $212,400. This isn’t budgeted under any DAO proposals as of yet, but at the time, I was planning to add it to the next proposal of the core technical team upon its successful completion.
During this work, I was frequently being asked to review code that wasn’t internally reviewed first (which is apparent from a single person pushing to the main branch). However, being asked to review unit tests that were made to appear to be working broke the camel’s back (you can check out the NEAR unit tests on this commit). There are two major problems with this:
- It takes much more time to review adversarial code because I can no longer take anything at face value and have to verify everything exhaustively
- It increases the risk of me giving the okay for the DAO to pay for work that is unfit
Spoofing unit tests of smart contracts that are meant to be used by the public is not merely unprofessional, but also unethical. Unfortunately, we didn’t see eye to eye with ChainSafe on this, and it wasn’t possible for me to continue acting as their client.
I stated that I would pay any invoice that they send our way from my personal funds, but I would not review any of their work anymore and would have to report to the DAO and the greater API3 stakeholders about this. As a result:
- I can use my work time productively
- Since ChainSafe knows that their final deliverable will be scrutinized publicly in light of these events, they will be forced to employ QA
- API3 receives an unplanned donation in the form of development
To wrap up, we now have NEAR and Solana ports of the API3 data feed contracts. I’ll write a separate post about what to do with these.