Rough design for a trustless tipping mechanism for BEEFY relayers:

Data Types on BH:

• Tips: Mapping between an outbound message nonce and the beefy relayer tip.

Flow

Polkadot->Ethereum:

1. On AH, user signals a BEEFY relayer tip by including this xcm within ExportMessage:

DepositAsset (WETH, TipAmount) SnowbridgeBeefyTipsAddress

2. When the forwarded XCM is received on BH, set Tips[Message.Nonce] = TipAmount. Export the message for delivery to Polkadot

3. When an inbound message is processed by the Gateway contract on the Ethereum, the InboundMessageDispatched event includes the address of the BEEFY relayer that provided the BEEFY state used to prove the message.

Ethereum->Polkadot:

1. When proof-of-delivery for the user message is sent back to BridgeHub, the tip is rewarded to the beefy relayer's account on AH. In Snowbridge V2, this can be handled by the rewards pallet.

Frontend UX

The frontend should calculate a suitable tip based on current bridge traffic, and with awareness that there is a free BEEFY consensus update every 4 hours (the mandatory beefy commitment at the start of each session)

Discussion

Currently BEEFY relayers are incentivized outside of the protocol using treasury funding. This has certain benefits, including much lower overall user fees. On the other hand, it does not promote decentralization.

With this design, which introduces protocol-level incentivization, there is obviously a race for competing BEEFY relayers to submit updates and receive tips. This a larger problem that either needs to tackled as part of this solution, or separately.

One approach, at least for mandatory BEEFY commitments, is to introduce a registration and slashing mechanism. This would involve round-robin relayer selection, relayers putting up a deposit, and being slashed for not submitting mandatory BEEFY commitments in time.

This approach could be extended to non-mandatory commitments. The selected relayer for a session will forfeit the tips described above if they don't follow their duties.