Messages
Currently, version one of the Streamer Protocol supports only six message types:
Hello
The HELLO
message is the first message sent between the client and Mevlink node. It consists of the client's protocol version & their API Key ID, found in the Mevlink Dashboard.
Challenge
The CHALLENGE
message is sent by the Mevlink node in response to the client's HELLO
message. It contains the 16-byte HMAC challenge string.
Challenge Response
The The CHALLENGE_RESPONSE
consists of the HMAC-SHA256 digest
Transaction
Once the messages above have been exchanged, the Mevlink node will begin sending TRANSACTION
messages to the client. The TRANSACTION
message includes the rlp encoded tx bytes, the unix timestamp of when tx was sent, and the unix timestamp of when Mevlink first learned about the transaction.
All rlp encoded transactions in the ethereumplex include a length specifier near the beginning. BSC uses legacy transactions and thus are also rlp encoded. Check out the ethereum rlp docs for more details or checkout how we parse this message in our streamer-go library.
The ordering of the emitted fields, timing information, and MAC is such that you can choose to react to transactions before you have timing information or have verified the authentication signature.
Disconnect
If the Mevlink node disconnects gracefully, it will do so with a DISCONNECT
message containing an error code describing why it closed the connection.
Emit Transaction
This feature is currently in beta and experiencing many updates and maintenance. We do not consider it's performance to be as strong as our transaction streaming service at the moment, but encourage you to try it as a value add.
If you'd like to propagate a transaction, you can send a EMIT_TRANSACTION
message with the RLP encoded transaction bytes.
Emit Whitelist
Not live! Coming soon.
The EMIT_WHITELIST
message explicitly tells the node which peers you'd like us to send the propagation request transactions to.
Emit Blacklist
Not live! Coming soon.
The EMIT_WHITELIST
message explicitly tells the node which peers you'd like us to NOT send the propagation request transactions to.
Last updated