-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "supports" to chains #86
Conversation
I have one doubt about this. Say we want to start supporting |
For example, base, kava, linea, mantle, rsk support API3Market in https://github.com/api3dao/airnode-protocol-v1/blob/main/src/supported-chains.js#L3 though they are not live yet. What to do about this? (Also the current state is inconsistent, mantle supports Api3Market and linea does not, even though they will be added at the same time.) |
src/types.ts
Outdated
@@ -1,5 +1,7 @@ | |||
import { z } from 'zod'; | |||
|
|||
export const SUPPORTS = ['API3Market', 'ChainAPI', 'dAPIs', 'OEVRelay']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would either do camel case (Api3Market, ChainApi, Dapis, OevRelay) or full names (API3 Market, ChainAPI, dAPIs, OEV Relay)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made these all fully lower case for now to avoid any kind of ambiguity or confusion. It seems the simplest to me (e.g. the example above is pascal case, not camel case 😬). What do you think?
Unfortunately I'm not really sure how to get around this if we want to make this package the source of truth for what is supported. I'm actually wondering if it's even the best way to go at all. I think each project should be responsible for determining (and exposing if necessary) what it supports. Then we don't have this kind of chicken and egg problem. The original issue was created to reduce confusion about what chains Api3ServerV1 is deployed on. I think a better approach is probably just to have the contract addresses listed in this repo and importing projects can figure out what they want to do with that information. i.e. {
"contracts": {
"AirnodeRrpV0": null, // if not deployed yet
"Api3ServerV1": "0x1234",
"AccessControlRegistry": "0x9876",
...
}
} I realise that this is duplicating some of the references.json data though, but this repo seems like it's maybe the better place to store all information related to each chain. What do you think? |
The fundamental issue is
We're already doing it in a non-central way but that has two downsides:
In short, I don't think that we need to export the contract addresses here. In most cases you would need to import the ABI along with the address, so it makes sense for these to be imported from the respective repos that deploy them. I think we actually need a |
I'm still a tiny bit skeptical about this but don't have a better solution at the moment so I've updated the PR and I think it should be ready to merge.
I guess so yeah. Or just a patch release |
I'm also not sure, let me dwell on this a bit more |
I'm now thinking that this was a bad idea. You can close the PR if you still think that way. Specifically I think we should remove everything and only leave |
Ok. Will re-open/re-implement if we want this again later |
Changes
supports
array to each chain. The possible values are any combination of these literals:['API3Market', 'ChainAPI', 'dAPIs', 'OEVRelay']
. Empty arrays are allowed too. I used this file as the reference for the actual values.Addresses: #3