Are you open to accepting new relayers?

[eagr]

Are you open to accepting new relayers?

By the way, if the following steps in the doc are mandatory to run a functional relayer:

Once you have set up all of the above, ask for a relayer ID and relayer count in Snowbridge Relayer Telegram group

Once the relayer has started up successfully, all relaying parties should increment their relayer count config and redeploy their relayer config. This action will be prompted in the TG group.

then it'd not be so permissionless as stated:

Relayers are permissionless and trustless. This means that anyone can operate a relayer for channels they are interested in.

[claravanstaden]

Hey @eagr! Thanks for you message. We've actually done quite a bit of ground work to accommodate external parties in the last month. I have some updated docs in this PR, will merge soon: #1731 The brittle relayer ID and relayer count config are not used anymore.

Two pieces are missing at the moment:

• Gas refunds for beefy consensus updates (being worked on in Beefy client wrapper contract #1668)
• Real incentives for running relayer (right now the cost of running compute likely won't be covered by the relayer profit)

Let me get back to you in a week.

[eagr]

Appreciate the great work and the prompt response. Phew! Glad to hear you ditch the incredibly unscalable way to add new relayers. Look forward to your update.

[claravanstaden]

Hey @eagr! I have updated the relayer docs. You can view them and run your own relayers, if you so choose. Right now, relaying consensus updates are not really advisable (as I have outlined in https://docs.snowbridge.network/resources/run-relayers#which-relayers-should-i-run), since they are not refunded or incentivized. Message relayers are rewarded, although I think the rewards are unlikely to cover your compute costs. The compute required is quite small, so perhaps if you run it on self-hosted setup the rewards might be worth it. Let me know if you have any questions. :)

[eagr]

Thanks for the tip! @claravanstaden

Is there a long-term plan for v1 relayer support? Running a v1 relayer requires the channel id of the parachain (right?) which is not very intuitive how to obtain. To make onboarding smoother, some pointer would be great. As the number of parachains with frequent transfers is still manageable, perhaps explicitly list the ids in the doc. Btw, is this correct?

const toChannelId = (paraId) => {
	const prefixBytes = Buffer.from('para', 'ascii')
	const paraIdBytes = Buffer.alloc(4)
	paraIdBytes.writeUInt32BE(paraId, 0)
	const bytes = Buffer.concat([prefixBytes, paraIdBytes])
	const hash = keccak256(bytes)
	return '0x' + hash.toString('hex')
}

Say if I want to cover multiple parachains, I suppose v1 relayers should be run somewhat like this?

CHANNEL_ID=<hydration_chid> ... docker compose -p hydration-v1 ... up -d ethereum parachain
CHANNEL_ID=<assethub_chid> ... docker compose -p assethub-v1 ... up -d ethereum parachain

---

Rewards come in two tokens ($DOT and $ETH) but one reward address? Are the rewards gonna be sent to perhaps Asset Hub where both tokens are supported, or the relayers are meant to run separately like?

REWARD_ADDRESS=<eth_addr> docker compose -p para2eth-v2 up -d parachain-v2 ...
REWARD_ADDRESS=<sub_addr> docker compose -p eth2para-v2 up -d ethereum-v2 reward ...

My bet is on the latter one :)) A few words on how the rewards are distributed would also be great.