Requirements Native tokens of the source chain are the only acceptable method of payment; The estimated fee of the message to be transferred is provided by a pricing system on the source chain which is connected to a Relayer Fee Market; The cost on the target chain is at the expense of the relayer who claims the handling fee on the source chain with the proof of delivery after delivery is completed successfully. To incentivize relayers, the pricing system should ensure the gain is greater than the cost in the long term. If an automatic pricing mechanism is infeasible, relayers should give their offers manually and bear the cost of offering. The relayers should be punished if they fail to relay the message as expected; Relayers and Users constitute a secondary supply-and-demand market, where prices rise when supply is low and fall when supply is abundant. There are no access restrictions for relayers, and anyone can enter. Relayers should evaluate and quote at their own discretion as economically rational people. An incomplete list of risks that relayers should take into account is as follows: a. Fluctuation in token prices and exchange ratios; b. Time delay between quoting and claiming; c. Loss of staking funds due to software or network failures. Tiered Quotation Market This approach is suitable for scenarios with a lower gas fee on the source chain and a shorter finality time. It has better versatility, reliability, and robustness. Such networks include Heco, BSC, Polygon and Darwinia. First, the relayer posts their quotes based on the reference price and the expected profit on the blockchain at any time. An off-chain pricing system maintains the reference price. Each relayer should lock a sufficient default margin on the chain to guarantee the faithful execution of the deal. In this way, a series of Ask prices(price meanings fee per message) come into being in the ascending order on the blockchain. When the user initiates a request on the source chain, the lowest n offers P1, P2…and Pn are filtered out, and Pn is used as the billing price. Those who make these offers are called Assigned Relayers. The user can request a cross-chain message delivery after paying Pn. We select n relayers in the executed order because we want to have redundancy for executing the message delivery. P1’s relayer is R1, P2’s relayer is R2, Pn’s relayer is Rn. At any time, the messaging relayer and confirming relayer can be different. However, the assigned relayer will be highly rewarded in priority time slots, both for delivering and confirming. Relayers with different asking prices will be assigned a different priority time slot. Once completing the task in its assigned time slot, the relayer assigned will be rewarded with a higher percentage, and this reward is for the asked price and the commitment (delivery in time or slash). Relayers with lower prices are assigned with the earlier time slot. For simplicity, when a user wants to send a bridge message and queries the pricing system, the dispatch call will fail and exit if the number of relayers in the current market is less than MIN_ASSIGNED_RELAYERS_NUMBER. Detailed Steps in Implementation

1. Enroll and lock collateral. a.enroll_and_lock_collateral dispatch call; b. cancel_enrollment() dispatch call, remember to check if the relayer is in priority time slots.

2. Ask price. We use simple constant price function for messages currently: fn(message) = const_price * 1 where const_price means fee per message. We might later improve this fn(message) with relayer defined fee functions. a. Update, Cancel prices storage; b. If the collateral of any registered relayer is lower than the required collateral threshold (e.g. slashed), the enrolment of this relayer will become inactive(will be removed from the ask list, and not able to put new ask).

3. Send message. Users pay Pn for sending a cross-chain message. a. Create a new order(with current block number), in the order lifecycle, the relayer cannot cancel enrollment and take back collateral; b. Pn is consumed in the module relayer fund account.

4. Message delivery and confirmation by bridger;

5. Reward and Slash Strategy. a. If the order is confirmed in Rn’s slot, then Rn can claim 60% from the reward P1, and message relayer can claim 80% * (1- 60%) from P1, confirm relayer can claim 20% * (1- 60%) from P1, (Pn - P1) will go to treasury; b. If the order is confirmed beyond all assigned relayers slot, and then The reward will be S(t) where S(t) > Pn, the part S(t) comes from funds slashed from R1, R2, Rn’s collateral. Message relayer can claim 80% from S(t), confirm relayer can claim 20% from S(t). Note: The ratio parameters in the strategy can be defined in runtime, and there might be update to them for refinement after more benchmark and statistics. Alternative Proposal B-Oracle + On-chain Automatic Pricing High gas fees in some networks, such as Ethereum, may prevent the relayer from quoting frequently. The execution cost of message delivery on the target chain is predictable (Ethereum>Darwinia). In this scenario, a second-best solution is to query the execution cost by the interface on the target chain, plus the estimated delivery cost. The disadvantage is that it is not adaptable, and no relayer may be willing to take the order, causing message delivery congestion and stability problems. Update to Darwinia > Ethereum Bridge: Grandpa Beefy Light Client + Three-tiered Quotation For BEEFY, the interaction is a multi-round process in which the Bridged Chain fee should be paid. The user needs to know in advance how much the handling fee is and whether the balance is sufficient. However, it cannot be predicted. We can establish a market that implements an ask/bid system. The relayer posts a quote for Header Relay during a specific period(ask), and the user may respond to it (bid) if they accept the quoted price. The relayer relays the header after the deal is closed. The relayer may lose the staking tokens if they fail to relay the message in time, whatever the reason is. More than one relayer can quote at the same time to compete for users.