-
Notifications
You must be signed in to change notification settings - Fork 835
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 Relayer info? #667
Comments
Irisnet IBC explorer is building the registry. |
Yes 1000% same page as you guys! I want to make this as on-chain as possible (supported by cosmos.directory) but I'm a little naive about the IBC implementation right now. I figured validators would need to submit at least an address to link them to a relaying wallet? If validators were to provide a relayers.json file, with their address for each chain - would this be all the data we needed to link on-chain wallets to a validator identity? |
a relayer operator is "only" an operator making transactions with a wallet address. ie. we have 3 relayer instance. |
…e-grant-deny-list Autostake: Handle StakeGrant deny_list instead of allow_list
SmartStake is already making such a tool |
https://github.com/SmartStake/relayers/blob/main/relayers/4D3303E20A4D2C32.json |
Ah awesome! It would be pretty easy to pull their data into cosmos.directory and expose via the APIs there. I have plans to add relayer info to REStake at some point but it's not super high on the list - let me know if exposing SmartStake's data via API is useful for anyone and I can prioritise that sooner. While Validator Registry is suitable for this data, relayers and validators aren't necessarily one to one so I'm very on board with supporting an external repo like that. |
Sir, you are a God Walking Amongst Mere Mortals 🫡 I don't think it's a priority though, just a nice to have. |
Many of the crypto community want to support the (generous) IBC Relayers, and a registry of that could offer some value. With the right kind of automation, utilizing the profiles that are already defined here could serve to become a registry of IBC Relayers, with support/tip information. It could also be used as a quality metric for validator selection (in addition to in-chain data, such as governance history and performance.
Help me replace the hardcoded data in this file:
https://github.com/osmosis-labs/docs/blob/main/developing/relaying/relayers.md
The text was updated successfully, but these errors were encountered: