Skip to content
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

Open
JeremyParish69 opened this issue Jul 24, 2022 · 7 comments
Open

Add Relayer info? #667

JeremyParish69 opened this issue Jul 24, 2022 · 7 comments

Comments

@JeremyParish69
Copy link

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

@Galadrin
Copy link
Collaborator

Irisnet IBC explorer is building the registry.
https://github.com/irisnet/iob-registry

@tombeynon
Copy link
Contributor

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?

@Sdpierret
Copy link
Contributor

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.
but, one of the important things is the "path" relayed by the operators.

ie. we have 3 relayer instance.
the 3 have cosmos addresses but the 3 relayer instance don't relay the same paths.
only 1 of them will have cosmos/osmo and maybe the second one will have cosmos/juno

achuchavo pushed a commit to achuchavo/validator-registry that referenced this issue Nov 21, 2022
…e-grant-deny-list

Autostake: Handle StakeGrant deny_list instead of allow_list
@AutoStake-com
Copy link
Collaborator

AutoStake-com commented Nov 27, 2022

SmartStake is already making such a tool

https://relayers.smartstake.io/

image

@AutoStake-com
Copy link
Collaborator

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. but, one of the important things is the "path" relayed by the operators.

ie. we have 3 relayer instance. the 3 have cosmos addresses but the 3 relayer instance don't relay the same paths. only 1 of them will have cosmos/osmo and maybe the second one will have cosmos/juno

https://github.com/SmartStake/relayers/blob/main/relayers/4D3303E20A4D2C32.json

@tombeynon
Copy link
Contributor

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.

@AutoStake-com
Copy link
Collaborator

Sir, you are a God Walking Amongst Mere Mortals 🫡

I don't think it's a priority though, just a nice to have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants