If you've worked in the security token space, you know the problem: every project ends up building the same verification flows, the same corporate action logic, and the same compliance hooks from scratch. It's inefficient, error-prone, and makes it harder for the ecosystem to build momentum around regulated assets on-chain. 

That is what the Solana Security Token Standard (SSTS) is designed to change. SSTS is an independent, open-source standard built by Halborn, Hoodies, and a council of industry contributors including Tokeny, Franklin Templeton, Superstate, Securitize, and others with direct support and feedback from Solana Foundation. It is now available as a Solana program that gives teams a solid foundation for issuing and managing regulated tokens on Solana, with configurable verification, standardized token operations, and built-in corporate action support. 

SSTS began about a year ago when Solana Foundation issued Halborn a grant to support development of a security token standard for the broader Solana ecosystem. A council of contributors brought real-world requirements and feedback to the design process. Halborn contributed the architecture and coordinated the standardization effort, Hoodies developed the implementation, and Halborn performed the security audit. 

Here's what SSTS is, what it unlocks, and how it works. 

SSTS is a security token standard built for Solana that leverages SPL Token 2022 and its extension model. It's designed to support regulated token workflows that require configurable verification, controlled operations, and corporate action support, while remaining adaptable to different operational and policy requirements. 

The architecture separates two key concerns: verification is handled through external programs that can be configured per instruction, and token operations are executed through a standardized program layer once verification succeeds. This separation gives teams the flexibility to adapt their compliance logic without rewriting core token functionality. 

Security token implementations often converge on the same technical needs. Issuers and platforms need to run eligibility checks before sensitive actions, standardize lifecycle operations across venues, and support issuer-driven events like conversions, splits, or distributions. 

SSTS makes those workflows consistent and composable, without forcing every team to implement bespoke policy logic inside a token program. The standard provides the infrastructure, and you bring the compliance logic that fits your use case. 

SSTS focuses on four functional areas that map to the core requirements of regulated token operations. 

SSTS supports external verification programs for policy checks and is designed around two patterns. 

The first is introspection, where SSTS confirms the required verification programs ran earlier in the same transaction before it proceeds. The second is CPI-based invocation, where verification is performed through direct program calls as part of the flow. 

SSTS also supports flexible authorization models. Depending on how a deployment is configured, authorization can be delegated to configured verification programs, with an optional fallback model tied to the original mint creator. This flexibility allows teams to implement the authorization structure that matches their operational requirements. 

SSTS standardizes common token operations using SPL Token 2022, including mint, burn, transfer, freeze, thaw, pause, and resume. 

It's built to work with Token 2022 extensions that are commonly relevant for controlled assets, including PermanentDelegate, TransferHook, and Pausable. It also supports optional metadata-related capabilities, including MetadataPointer, TokenMetadata, and ScaledUiAmount. These extensions give issuers the control surfaces they need for regulated assets without adding unnecessary complexity. 

SSTS includes primitives for corporate actions that commonly appear in security token lifecycles. 

It supports token splits via rate-based minting. It supports token conversions between mints using configured rates. It supports distribution claims using Merkle tree proofs, which can be used for events such as dividend or coupon-style distributions. It also includes rate accounts so conversion and split math can be configured with defined rounding behavior. 

These primitives handle the mechanical side of corporate actions, allowing issuers to focus on the business logic and governance around these events. 

SSTS defines standardized account types that make verification and corporate actions auditable and easier to integrate. 

MintAuthority stores the original creator for authorization fallback, when configured. VerificationConfig defines per-instruction verification program configuration. Rate defines conversion and split rate configuration. Receipt helps prevent duplicate participation in corporate actions. Proof stores Merkle proof data for distribution claims. 

These account types provide a consistent data model that makes it easier to build tooling, integrations, and user interfaces around SSTS tokens. 

SSTS is designed around a straightforward idea: verification should be configurable, and token operations should be standardized. 

Teams can define expected verification workflows per instruction using a VerificationConfig account. SSTS then validates that the expected verification steps were performed in the same transaction before executing the requested operation. This design allows projects to adapt verification logic over time without changing the core token operations layer. 

The separation of concerns means you can iterate on compliance logic as regulations evolve or as your operational requirements change, without touching the underlying token mechanics. That's a significant advantage in a space where regulatory frameworks are still taking shape. 

The repository includes the program implementation and supporting materials to help teams evaluate and integrate the standard. 

GitHub: https://github.com/Halborn/solana-security-token-standard 

Official site: https://ssts.org  

SSTS touches sensitive surfaces. Any system that combines verification, authorization, and corporate actions should be integrated with a security-first mindset. 

Teams should review how VerificationConfig and Rate accounts are governed, including who can update them and under what controls. Test receipt logic for corporate actions to ensure operations cannot be executed more than intended. Validate rounding and edge-case behavior for conversions and splits. For distribution claims, Merkle proof handling and receipt issuance should be tested for replay resistance and correctness under adversarial inputs. 

These aren't optional steps. They're core to ensuring your implementation behaves correctly under all conditions, including adversarial ones. 

Halborn was one of several contributors who helped bring SSTS to life. We worked with Solana Foundation to convene the industry council, contributed the core architecture based on feedback from Franklin Templeton, Tokeny, Superstate, Securitize, and others, and audited the final implementation that Hoodies built. 

If your team is evaluating SSTS, building custom verification programs, or implementing corporate action workflows, we can support threat modeling, security reviews, and end-to-end testing across both the verification layer and operational controls. We've been involved with this standard from the beginning, and we understand the security considerations that matter most for regulated token infrastructure. 

Reach out if you'd like to discuss your implementation. We're here to help you ship securely.