Перейти к основному содержанию
Клиент Apex на TypeScript входит в @orbitflare/sdk и не является отдельным пакетом. Он работает с Apex только по HTTP JSON-RPC. Транспорта QUIC для TypeScript пока нет, потому что в Node нет реализации QUIC, достаточно надёжной для отправки. Для пути с наименьшей задержкой по QUIC используйте клиент на Rust или клиент на Go.

Установка

@solana/kit и два пакета программ собирают и подписывают транзакцию. Самому клиенту Apex нужен только @orbitflare/sdk. Задайте свой API-ключ Apex, keypair с балансом и эндпоинт Solana RPC для blockhash и подтверждения. В примере используется OrbitFlare RPC с вашим лицензионным ключом:

Быстрый старт

Эта программа отправляет 1,000 lamports на выбранный вами адрес (по умолчанию на свой собственный) с минимальными чаевыми, а затем ждёт, пока транзакция попадёт в блок. Сохраните её как send.ts и запустите командой npx tsx send.ts.
Фрагменты ниже используют apex, solana и байты подписанной транзакции (wire) из этой программы.

Отправка

Одну транзакцию отправляют два метода. Оба возвращают подпись, как только эндпоинт её принимает.
Оба принимают необязательные mevProtect (пропускать лидеров из блок-листа Shield, см. Защита от MEV) и maxRetries (ограничить, сколько раз Apex повторно отправляет транзакцию), которые переопределяют значения билдера по умолчанию для этого вызова. Транзакция должна занимать от 1 до 4,096 байт (APEX_MAX_TRANSACTION_SIZE).

Пакеты

sendBatch отправляет до 16 транзакций (APEX_MAX_BATCH) в одном запросе. Каждая транзакция проверяется и отправляется наперегонки отдельно, поэтому одна плохая транзакция не останавливает остальные.

Бандлы

sendBundle отправляет от 1 до 4 транзакций (APEX_MAX_BUNDLE), которые попадают в блок вместе или не попадают вовсе, только через лидеров Jito. Ровно одна транзакция в бандле несёт чаевые.
state принимает значения Pending, Landed, Failed или Invalid. Статусы бандлов могут отставать от чейна, поэтому подтверждайте signatures бандла через waitForConfirmation, а не ждите только статуса. Правила и лимиты запросов описаны в разделе Бандлы.

Чаевые и подтверждение

Правила чаевых описаны на странице Чаевые.

Регионы и резервирование

Когда запрос к основному эндпоинту не удаётся, клиент по порядку пробует резервные. Коды регионов: fra, ams, dub, lon, nyc, slc, sgp, tyo, sqq и global (ближайший исправный эндпоинт). Если регион не задан, клиент использует ORBITFLARE_APEX_URL, затем ORBITFLARE_APEX_REGION, затем Франкфурт. См. Эндпоинты.

Параметры

По умолчанию клиент делает одну попытку на эндпоинт и сразу переходит к следующему резервному вместо повторов. Это сделано намеренно: повторная отправка транзакции, которую Apex уже принял, расходует ваш лимит запросов, а Apex сам продолжает повторно отправлять принятые транзакции.

Поддержание соединения прогретым

apex.ping() вызывает GET /ping и завершается, когда эндпоинт отвечает pong. Вызов раз в несколько секунд держит HTTP-соединение открытым, поэтому следующая отправка пропускает TCP-рукопожатие.

Ошибки

Каждый сбой является OrbitflareError с полем kind: Коды ошибок и лимиты запросов Apex перечислены в разделе Ошибки и лимиты запросов.