The Simplest Geyser Plugin Ever

What's a Solana Geyser Plugin?

A Solana Validator can "leak" accounts and transactions data outside the validator. This flow of data is achieved through the The Geyser Plugin Interface.

An external library can plug into that interface by implementing the necessary functions and thus listen for accounts and transactions streams.

That dynamic library is provided to the validator at runtime. The validator can then open that library and call the implemented callbacks or hooks with accounts and transactions data.

The library can then feed on these data and take further actions, such as logging, inserting the data into a DB or a consumer/producer system, etc.

Solana Geyser Plugin Scaffold

This is the simplest geyser plugin implementation you will encounter, all it does is log every calls from the plugin manager to our plugin scaffold. This is a good start to familiarize yourself with the plugin workflow, and most importantly debug.

/!\ The code is for educational purpose, in a production setting, you would want to remove any fancy logs and do the minimum work possible in the hooks by leveraging threads, different process or external services, etc...

Try It!

Run: bash ./scripts/run.sh

How do I know if it works? bash ./scripts/logs.sh

Plugin or validator crashing? bash ./scripts/check_errors.sh

Geyser Plugin Config

The dynamic library path is provided to the validator using the --geyser-plugin-config parameter. For example when using the test validator: ```bash solana-test-validator --geyser-plugin-config config/geyser-plugin-config-mac.json

or use ./scripts/run.sh

```

At a minimum the config file should: - Be in JSON format - Contain the path to your geyser plugin dynamic library .so or (dylib on mac)

For example: json { "libpath": "libsolana_geyser_plugin_scaffold.dylib" }

Of course your production validator won't run on mac, so update the path accordingly and use the .so version.

Additionally, at runtime the Solana Plugin Manager will pass back the path to that config file to your plugin. The config_file path will be provided on the onload(&mut self, configfile: &str) lifecycle event. So you can add any additional config you think your plugin might need. And parse it when your plugin gets loaded.

Going Further

Examples Plugin Implementations