Introducing Yellowstone Shield 🚫🛡️

At Triton One, we believe every user and developer should have transparency and control over how their transactions move through the Solana network. As the validator landscape evolves—and Maximum Extractable Value (MEV) risks become more prominent—this control has become essential.

Today, we're excited to introduce Yellowstone Shield: an on-chain access control framework that empowers users and transaction forwarders to decide who is (and isn't) authorized to handle their transactions.

What Is Yellowstone Shield?

Yellowstone Shield is a Solana program for managing on-chain allowlists and blocklists of identities. An identity can be a validator, a wallet, or even another program. These policies let transaction senders define which validators are trusted to process transactions—and which should be excluded.

Each policy is stored as a Program Derived Address (PDA) and linked to a Token Extensions (TE) asset, giving token holders the power to manage and update forwarding policies over time.

Why We Built It

As transaction forwarding became more common—through solutions like Jito’s Block Engine or custom RPC routing layers—so did the potential for abuse.

The MEV Problem

While Solana originally had no public mempool, systems like Jito introduced partial transaction visibility. Some validators began exploiting private mempools for profit—executing frontrunning, sandwiching, and other forms of MEV.

Even though Jito eventually removed their public mempool, the practice continues today: validator-based transaction exploitation became real.

With Yellowstone Shield, we give users and RPC providers a way to opt out—to route transactions only to validators they trust.

How It Works

Yellowstone Shield lets you define a forwarding policy with two modes:

• Allow: Transactions are only forwarded to validators that appear on the allowlist.

• Deny: Transactions are never forwarded to validators that appear on the blocklist.

RPCs using Shield will monitor Solana’s leader schedule. If the current leader doesn’t meet the policy criteria, the transaction won’t be sent. Instead, it will be forwarded to the next eligible leader that passes the policy check.

This offers a strong guarantee: your transaction is never handed to an untrusted validator.

Powered by Yellowstone Shield Store

We’ve also released yellowstone_shield_store, a Rust crate that provides:

cargo add yellowstone-shield-store

• 🔄 Efficient caching of on-chain policies

• ⚡ Atomic updates to policy data

• ✅ Fast, thread-safe enforcement of access rules in transaction forwarders

This library makes it easy for anyone building custom RPCs or forwarders to enforce policy-based routing without sacrificing performance.

use yellowstone_shield_store::{
  VixenConfig,
  NullConfig,
  PolicyStoreBuilder,
  BuiltPolicyStore
};

// Initially seed policy store through RPC
let rpc = RpcClient::new("https://api.mainnet-beta.solana.com".to_string());
// Keep policy up to date over grpc
let vixen = VixenConfig::<NullConfig>::default();

// Build a policy store and subscription for live-updates
let BuiltPolicyStore { subscription, policies } = PolicyStoreBuilder::new()
  .rpc(rpc)
  .vixen(vixen)
  .build()
  .await?;

// Dummy validator and policy addresses
let validator = Pubkey::new_unique();
let policy = Pubkey::new_unique();

// Retrieve the latest snapshot of policies
let snapshot = policies.snapshot();

// Check if the validator is allowed by the policy
match snapshot.is_allowed(&[policy], &validator) {
  Ok(true) => println!("Validator is allowed."),
  Ok(false) => println!("Validator is denied."),
  Err(e) => println!("Error checking policy: {:?}", e),
}

Jet Support — Available Today

If you’re using Triton RPC, you can start using forwarding policies right now.

That’s because Yellowstone Shield is fully integrated into Yellowstone Jet, Triton One’s open-source transaction forwarder. When you submit a transaction through Triton RPC, Jet checks your specified Shield policy and routes the transaction accordingly:

• If the current leader is not on your allowlist—or appears on your blocklist—Jet will not forward the transaction.

• Instead, it skips the validator and forwards to the next eligible validator that meets your policy criteria.

This ensures your transactions are only ever handled by validators you trust.

Example usage:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sendTransaction",
  "params": [
    "<base64_encoded_transaction>",
    {
      "encoding": "base64",
      "skipPreflight": true,
      "forwardingPolicies": ["<your_policy_pda>"]
    }
  ]
}

Or use the HTTP header for legacy clients:

Solana-ForwardingPolicies: "<your_policy_pda>,<your_policy_pda2>"

Whether you’re integrating with a wallet, a dApp backend, or just sending transactions manually, you now have a simple and powerful way to enforce trust in your transaction flow—with zero changes to how Solana itself operates.

Build, Explore, and Customize

To make policy creation and management easier, we’ve built a full toolkit:

• 🧰 CLI Tools – Create, update, and share policies from the terminal

• 📦 SDKs – Integrate with Rust or TypeScript apps

• ⚙️ Rust Policy Store – Fast caching and enforcement for custom RPCs

• 🌐 Web App (coming soon) – Explore and manage public or shared policies visually

The Road Ahead

Triton One is just getting started.

Yellowstone Shield is a foundational building block for a more secure, transparent, and user-driven Solana network. As support expands across the ecosystem, users, and builders will be able to confidently route transactions without fear of validator-level exploitation.

Take Control

Solana’s performance has always been world-class. With Yellowstone Shield, we’re raising the bar on transaction trust and forwarding transparency.

🔗 Visit the repository

💡 Start building with yellowstone_shield_store

Together, we can make Solana not just fast—but fair. 🚀🛡️