We want to remove the support of websockets in the relayer and instead of that we define a new API endpoint for our supported system that accepts the same payload we originally used in websockets and respond back immediately with a txhash that the caller can use for tracking the progress of the tx. (See #535 for more)
Motivation
This technically would allow the relayer to be more stateless that we could use to run on serverless infrastructure and easier to maintain. Another thing is it is much simpler this way, from the user respective or anyone wants to build on top of the relayer.
Task Checklist
[x] Create POST /api/v1/send/evm/<CHAIN_ID>/<CONTRACT_ADDRESS> endpoint
[x] Create POST /api/v1/send/substrate/<CHAIN_ID>/<TREE_ID> endpoint
[x] The structure of the payload for both should be similar with the a few differences (see below)
[x] Once submitted, the response should be one of the following:
[x] Failure case: { "status": "Failure", "message": "Failed to send the transaction", "reason": "...." }
[x] Before we submit the tx to the tx queue, we should do some validation first, here is a list of things that we should check:
[x] The requested chain id is supported by the relayer. reason: "Unsupported chain id".
[x] The requested contract address/ tree id is supported by the relayer. reason: "Unsupported contract/tree"
[x] The relayer field in the extData matches the relayer's beneficiary address. reason: "Invalid relayer address, expected '0x123...'"
[x] The requested refund in the extData is not greater than the max_refund. reason: "Requested refund is greater than max refund supported by the relayer".
[x] The requested refund in the extData is not greater than the relayer's balance - 15% (for paying the gas). reason: "Requested refund is greater than relayer's available balance"
[x] After all these validation, construct the call, queue it in the tx queue, and return the txhash back to the user.
Overview
We want to remove the support of websockets in the relayer and instead of that we define a new API endpoint for our supported system that accepts the same payload we originally used in websockets and respond back immediately with a txhash that the caller can use for tracking the progress of the tx. (See #535 for more)
Motivation
This technically would allow the relayer to be more stateless that we could use to run on serverless infrastructure and easier to maintain. Another thing is it is much simpler this way, from the user respective or anyone wants to build on top of the relayer.
Task Checklist
/api/v1/send/evm/<CHAIN_ID>/<CONTRACT_ADDRESS>
endpoint/api/v1/send/substrate/<CHAIN_ID>/<TREE_ID>
endpoint{ "status": "Sent", "message": "Transaction sent successfully", "itemKey": "0x123...." }
{ "status": "Failure", "message": "Failed to send the transaction", "reason": "...." }
reason: "Unsupported chain id"
.reason: "Unsupported contract/tree"
relayer
field in theextData
matches the relayer'sbeneficiary
address.reason: "Invalid relayer address, expected '0x123...'"
refund
in theextData
is not greater than themax_refund
.reason: "Requested refund is greater than max refund supported by the relayer"
.refund
in theextData
is not greater than the relayer's balance - 15% (for paying the gas).reason: "Requested refund is greater than relayer's available balance"
Example of Valid payload