Once you have installed the client dependency, you can initialize it as follows:
import Client from "@triton-one/yellowstone-grpc";
const client = new Client("https://api.rpcpool.com:443", "<insert your token here>");
// now you can call the client methods, e.g.:
const version = await client.getVersion(); // gets the version information
console.log(version);
Please note that the client is asynchronous, so it is expected that all calls are executed inside an async block or async function.
Subscription Streams
You can get updates and send requests through the subscription stream. You can create it by calling the client.subscribe() method:
import { SubscribeRequest } from "@triton-one/yellowstone-grpc";
// Create a subscription stream.
const stream = client.subscribe();
// Collecting all incoming events.
stream.on("data", (data) => {
console.log("data", data);
});
// Create a subscription request.
const request: SubscribeRequest = {
// you can use the standard JSON request format here.
// the following documentation describes available requests and filters.
...
};
// Sending a subscription request.
await new Promise<void>((resolve, reject) => {
stream.write(request, (err) => {
if (err === null || err === undefined) {
resolve();
} else {
reject(err);
}
});
}).catch((reason) => {
console.error(reason);
throw reason;
});
grpcurl Client
grpcurl is a good client for testing. You will also need the following two Protobuf proto files to describe the protocol:
Once you have these two downloaded, you can access Triton's staging environment with your token (contact Triton customer support for a token) to run gRPC requests:
The gRPC streams happen by default on the processed commitment level.
Triton also supports specifying confirmed and finalized commitment levels. In these cases, Dragon's Mouth will buffer the incoming updates for you and release them once the updates have become confirmed or finalized.
For maximum performance, however, it is recommended to use handling commitment levels client side.
To specify commitment level in your Dragon's Mouth gRPC calls provide the following values:
The benefit of working on processed is that you can process transactions as soon as they arrive, but only commit to them once you know whether they are confirmed or finalized. This means that you can get faster response times in your UI by doing a lot of the processing work at a lower commitment level and then be able to surface the changes as soon as you see that the event is committed.
How to manage `confirmed` and `finalized`
To manage confirmed and finalized you need to buffer events by slot. Each event (transaction or account write) will have a slot attached to it. You store these events in a buffer ordered by slot.
You will receive all the transaction notifications or account write notifications for the slot before you receive the "confirmed" and "finalized" notification for that slot.
The special thing about finalized
Unfortunately, due to a quirk in the way that Geyser works on SVM not every slot finalized notification is issued. This means that you need some special processing if you want to handle finalized correctly.
The special handling is the following: whenever you see a finalized slot notification, you need to check the parents and grand parents (and great-grandparents and so on) of that slot and mark those as finalized too even if you didn't receive a notification for them.
A sample Typescript/Nodejs client is available at .
A sample Rust client is available at .
A sample Golang client is available at .
You then also make sure you subscribe to . This will give you information about when a slot is confirmed or finalized. Depending on the commitment level you are interested in, you should release your buffer when you receive the slot notification for a particular slot at a particular commitment level.
