For the complete documentation index, see llms.txt. This page is also available as Markdown.

Send in Binary

Introduction to Send Transaction v2(binary) of BlockRazor Solana Fast mode and integration methods

Introduction

Send in Binary is used to send signed transactions on Solana. Compared with the Send Transaction, it allows signed transactions to be submitted in binary format instead of being converted to Base64 first. The benefits are that it removes one layer of encoding and decoding overhead, and because the payload is smaller, the transaction is less likely to be split into multiple packets during transmission, which can help reduce the resulting latency.

Endpoint

  • POST /v2/sendBinaryTransaction

Request Example

curl --location 'http://frankfurt.solana.blockrazor.xyz:443/v2/sendBinaryTransaction?auth=<auth_token>' \
--data-binary @transaction.bin

Note:

  • the auth and request parameter are compulsory to be added in URI params, e.g., http://frankfurt.solana.blockrazor.xyz:443/v2/sendBinaryTransaction?auth=<auth_token>&mode=fast&revertProtection=true

Request Parameter

Parameters
Mandatory
Example
Description

transaction

Mandatory

transaction.bin

Fully signed transactions, binary format

mode

Optional

"fast" "sandwichMitigation"

BlockRazor offers two modes: Fast and SandwichMitigation, with Fast as the default. In fast mode, transactions are sent based on globally distributed high-performance network and high-quality SWQoS, reaching the Leader node with the lowest latency. In sandwichMitigation mode, BlockRazoz will route transactions to the trusted SWQoS and skip the slot of the blacklisted Leader (dynamically identified by the BlockRazor sandwich monitoring mechanism). In this mode, DO NOT send transactions using durable nonce, as it will cause the sandwich protection to become ineffective.

safeWindow

Optional

3

safeWindow is used to determine the timing of transaction sending in sandwichMitigation mode and represents the number of consecutive slots of whitelist validators. For example, if it is set to 3, the transaction will only be sent when 3 consecutive slots from the current slot belong to whitelist validators. The range of safeWindow is 3-13. The larger the number, the better the effect of mitigating the sandwich attack, but it may have a certain impact on the rate of inclusion. If not set, the default is 3.

revertProtection

Optional

false

The default value is false. If set to true, the transaction will not fail on chain, but the speed of inclusion will be affected and there is a possibility that it cannot be included. Please choose to enable it carefully according to actual needs.

Response

Status Code
Message
Meaning

200

OK

The request is normal

400

BadRequest

Invalid parameter

403

Forbidden

Request denied, as the authentication (auth) is empty, invalid, or expired.

500

InternalServerError

The server encountered an unexpected condition that prevented it from fulfilling the request

Last updated

Was this helpful?