Skip to main content

· 9 min read
Noah Prince

A major tenant of blockchain architecture is composability. By sharing state, dApps can create rich interactions that are not isolated to a single walled garden. A token can have uses throughout the ecosystem, not just in a single application.

Solana and Ethereum take vastly different approaches to this problem. In this post, we'll explore the composability patterns on both and the consequences of these design choices.


My background is almost exclusively in Solana development. Ethereum devs, feel free to contribute and correct my understanding where needed.

Ethereum Composability

Ethereum Composability looks a lot like interface-based inheritance in classical Object Oriented Programming (OOP). Ethereum makes use of a set of Standards - Well-defined interfaces for common tasks, such as creating a token. The most well-known standard is the ERC-20 token standard:

interface IERC20 {
function transfer(address to, uint256 value) external returns (bool);
function approve(address spender, uint256 value) external returns (bool);
function transferFrom(address from, address to, uint256 value) external returns (bool);
function totalSupply() external view returns (uint256);
function balanceOf(address who) external view returns (uint256);
function allowance(address owner, address spender) external view returns (uint256);
event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

Here's an overview of Ethereum's account structure:

Ethereum Accounts Overview

A smart contract (in this case, a single token), resides at a particular address. Both the data and execution logic for that token are stored at that address. For example, the data to find all holders is available at that particular address.

In ethereum, you can compose contracts by storing them in your contract's state:

contract FooContract {
IERC20 myTokenContract;

Similar to OOP, Ethereum is a system of smart contracts adopting interfaces so that they can interoperate together. "If it quacks like a duck, then treat it like a duck"

Solana Composability

Solana Composability looks a lot more like Functional Programming (FP). The execution logic for a smart contract (on Solana, called a program) exists separately from the state.

With Solana, data is still stored in accounts, but all of the data for a given program is distributed across multiple accounts. Every account in Solana is owned by a Program. If this were a SQL database, you could get all of the state for a given program by running:

SELECT * from solana.accounts WHERE owner = <program_id>

Where is a Solana program stored? The compiled code is also stored on accounts. The Solana runtime knows how to execute the binary for these special accounts. You can think of a program call as a function execution over some state.

Since we looked at ERC-20, let's look at spl-token. First, let's take a look at a Token Account:

pub struct Account {
/// The mint associated with this account
pub mint: Pubkey,
/// The owner of this account.
pub owner: Pubkey,
/// The amount of tokens this account holds.
pub amount: u64,
/// If `delegate` is `Some` then `delegated_amount` represents
/// the amount authorized by the delegate
pub delegate: COption<Pubkey>,
/// The account's state
pub state: AccountState,
/// If is_native.is_some, this is a native token, and the value logs the rent-exempt reserve. An
/// Account is required to be rent-exempt, so the value is used by the Processor to ensure that
/// wrapped SOL accounts do not drop below this threshold.
pub is_native: COption<u64>,
/// The amount delegated
pub delegated_amount: u64,
/// Optional authority to close the account.
pub close_authority: COption<Pubkey>,

This struct will be stored on a solana account for each unique holder of a token. The account is changed via function calls, for example:

Transfer {
/// The amount of tokens to transfer.
amount: u64,

There's some major differences to note here:

  • Solana has one token program for all of the spl-tokens in existance. Eth has a program for each token.
  • Solana state is stored separately from execution logic.

Composability works via composing functions. I can write a function that takes in an Account from the spl-token program, and then calls Transfer.

Solana Composability - Inheritance

Solana Program calls depend on the arity and ordering of account arguments. Making matters more complicated, every account used by an instruction must be passed to the instruction.

The upshot: If my implementation of a function requires more or different accounts than yours, they are incompatible. This makes inheritance difficult to impossible.

Lookup Tables

A new feature to Solana, lookup tables, may help alleviate this limitation.

Solana Composability - State as an Interface

With Solana, the State is the interface. Composition can be broken down into systems of state and actions on that state. What does this mean? If Program A wants to interact with Program B, it can either

  • Directly call Program B
  • Write State that is expected by Program B

The latter has massive implications for composability. Instead of needing to agree on an action based interface, Solana programs can agree on intermediary state. Tokens are the most common form of state.

  • Program A gives the user token A
  • Program B lets the user exchange token A for NFT C

In Solana, Program B is blissfully unaware of Program A. In Ethereum, program B would need a reference to the token program of A.

Composability Example - Solana vs Ethereum

Let's say you want to mint an NFT such that the price increases for every NFT purchased. The De-Facto way to mint a collection on Solana is the CandyMachine.

The problem: The CandyMachine takes a fixed price in either SOL or any SPL token.

On Ethereum, you may extend the interface of the CandyMachine contract and add your pricing logic. On Solana, you could do similar -- fork the candymachine and upload your own program. We're devs, and code duplication is bad! Instead, we can string two programs together!

To achieve this, we can tie a Strata Bonding Curve to a Metaplex Candymachine. A Strata Bonding Curve allows you to create a pricing system such that every new token minted is more expensive than the one before it.

The integration is straightforward:

  • Step 1. Create a bonding curve with desired pricing characteristics that lets users buy Token A
  • Step 2. Create a CandyMachine whose price is 1 Token A

At minting time, the minting UI:

  • Uses SOL to purchase a Mint Token, Token A
  • Uses Token A to mint an NFT from the CandyMachine.

The intermediary state between Strata and Metaplex is Token A. Importantly, neither the Strata nor Metaplex contracts know about each other.

Solana vs Ethereum Composability - Consequences

Neither composition strategy is inherently better. As you will find with FP vs OOP, there are plenty of flame wars arguing which is better. There are, however, notable tradeoffs.

Tradeoffs - Speed

Solana's programming model lends itself to massive amounts of parallelization. Because every piece of state is identified as read-only or writable, the Solana Sealevel runtime is able to run many transactions in parallel knowing that they will not interfere with each other. This is a core tenant of Solana, and why it has a much higher TPS than Ethereum.

Tradeoffs - UI Compatability

Ethereum's interface model makes it easy for one UI to integrate with multiple smart contracts implementing the same interface. This makes forking considerably easier on Ethereum than it is on Solana. Example: On Ethereum, if you fork Uniswap and match the interface, you will have out-of-the-box support in multiple user interfaces. On Solana, you would only have support if you did not add any accounts to the function signatures. Solana user interfaces tend to be heavily coupled to particular smart contracts.

Tradeoffs - Open Source

Neither Ethereum nor Solana has contracts that are open source by default. However, Solana has a good amount of closed source contracts that hinder composability. It is much harder to compose with something when you can't see the code. That being said, there is a strong culture of open source within Solana that is actively pushing for contracts to be open. Strata is, and will always be, open source.

Tradeoffs - Program Proliferation vs State Proliferation

Ethereum's model leads to a lot more programs and a lot more bespoke code running on chain. This makes it way easier to override behavior (for example, taking fees on token transfers). On Ethereum, forking is easy and encouraged.

Solana's model leads to a lot more state, and programs that act as state changing primitives. This makes it preferable to create chains of logic where generalized contracts interact with other generalized contracts. On Solana, forking adds complexity for any UI-only dApps. This causes a push for well-thought-out battle-tested contracts, like the Metaplex Token Metadata Standard.

Tradeoffs - Complexity

Solana tends to be more complex from a planning and architecture standpoint. You need to think hard about the state you're outputting, and how it can be used in other contracts. Stringing contracts together can be painful if this is done incorrectly.

With Ethereum, as long as you have a reasonable interface you can get away with ugly state.

Strata - Composability First

The future of Solana is chains of primitives working together. We can model tokens, and systems of tokens, using various primitives like Bonding Curves, Fanout Wallets, CandyMachines, Governance, and Multisigs.

For example, using these primitives Grape has been able to set up a multifaceted DAO with SubDAOs:

System of Composable Tokens - Grape

With systems like this, the question shifts from "How do we develop an individual smart contract?" to "How can we compose and orchestrate existing primitives?".

Interested in Learning More?

· 7 min read
Noah Prince

In this article, we'll cover how to create a Solana token on Strata. Launching your own Solana token can be daunting. There are a lot of considerations, and we’ll try to cover those as well.

First, what does it mean to “Create” a token? Creating a Solana token tends to come in 3 steps:

  1. Creating the token. How do you actually create a Solana token that will show up in wallets like Phantom, Slope, and Solflare?
  2. Distribution. How do you get this token out to the community? How do you sell an initial supply to your community?
  3. Liquidity. How does your community continually have the ability to buy and sell this token?

How to Create a Solana Token Easy Mode - Fully Managed Tokens

Let’s say you do not want to worry about steps 1 through 3. You just want a token that people can buy and sell right now. When users put SOL in, they get the token out. You will not manage the token supply or pricing, and will instead take a royalty on sales (similar to an NFT). If you would like to create a token where you manage your own supply, you can skip to Creating a Token

For this article, I’m going to create a Solana Token called NOAH. Since it’s a small token, there’s no guarantee that there will be a counterparty to any trades. Instead, by using a Strata Fully Managed token, the protocol will be the counterparty to every trade.

Head over to the Strata Launchpad. Select “Create a Token”

Create a Solana Token

Select Fully Managed:

Fully Managed Solana Token

Fill out the name, description, and photo for this token:

Fully Managed Token Information

Then, select a price sensitivity. Utility is generally a good place to start.

Price Sensitivity

Next, I'm indicating that this is a Social Token. I want this token to link to my wallet, so that it can be bought and sold in apps like We’ll use SOL to price this token. When users put in SOL, they’ll get NOAH out. If this token isn't associated with a person, project, dao, it's fine to leave this toggle off.

Since I have set the royalties to 5% NOAH on Buy, I will get 5% of every NOAH token sale. If there are 100 NOAH tokens minted via the protocol, I will have received 5. I can also take SOL on buy/sell.

Fully managed royalties/info

Done! You now have a tradable token! You can see this token on devnet here.

Fully managed swap form

You can skip the rest of this guide, as it only applies to tokens not having their liquidity managed by Strata.

How to Create a Solana Token - Self Managed Tokens

A self managed token is one where you decide the supply, and have full control over distribution. You will want to think about who should have this token, how it gets distributed, and the percentages/amounts for each party. You can see an example of this kind of workup here

Step 1: How to Create a Solana Token - Creating the Token

This is the easiest part. Head over to the Strata Launchpad and select Create a Token

Create a Solana Token

Select self managed:

Self managed

Fill out your token’s information like the name, symbol, image, and supply:

Self managed info

Click Create Token. Strata will create the token and you should be able to see it in your wallet.

Step 2: How to Create a Solana Token - Distribution

You have a token in your wallet, but how do you distribute it? You can send the token to people using your wallet, but what if you want to sell the token? This is called “Liquidity Bootstrapping.” In the previous step, you will have been greeted with a screen like this. If not, you can get to this screen by clicking “Sell a Token” on the launchpad.

Sell a Solana Token

Here, you have a choice. Do you want to sell the token with price discovery or for a fixed price?

Price Discovery

If you expect the token to be in high demand, this is the best option. This option lets the market and your community decide on a fair price for the token. This uses the Strata Liquidity Bootstrapping Curve (LBC), which is similar to an LBP on Ethereum. The protocol will sell the token using a process similar to a dutch auction. The price will fall over time, and increase with every purchase. This creates a price discovery, which you can read more on here.

When selling a token with price discovery, the price will float throughout the launch period. You can control the following settings

  • Starting Price - The starting price when the LBC launches. The price will drop quickly in the beginning and more slowly as time goes on. We suggest you set this price at the highest price you expect the token to sell for. This is not the maximum price. If the token is in high demand, it could sell for an average price higher than the starting price.
  • Minimum Price - The absolute minimum price you would like to accept for these tokens. The price will never fall below this threshold. A minimum price that is too high may mean that the token does not sell out. This price should be within 5x of the starting price. If the starting price is 5 SOL, the minimum price should not be less than 1 SOL. The larger the difference, the faster the price will need to drop.
  • Number of Tokens - How many tokens do you want to sell in this LBC?
  • Interval - How long should this LBC go on for (in seconds)? This period is the time during which the price will fall. We recommend you set this period long enough so that everyone gets a chance to participate. Windows less than 15 minutes (900 seconds) are not recommended.
  • Launch Date - When should the LBC start?

Fixed Price

This option sells your token for a fixed price to anyone who visits the sales page. While this leads to predictable liquidity, it is also vulnerable to bots looking to buy your token and flip it on a secondary market. As a general rule of thumb, if your token is in high demand and you expect the fixed price to be less than the aftermarket price, you should use Price Discovery.

Bootstrapped Liquidity

After you finish launching your token, you’ll be able to distribute the funds from the sale back to your wallet. When using the wallet that launched this sale, you should see a form like this:

Disburse funds

Step 3: How to Create a Solana Token - Liquidity

Now you have both your token and SOL in your wallet. Your community has tokens which they have purchased. How do you enable trading on this token? The best way to enable trading is via an Automated Market Maker (AMM). The most common form of this is a Swap (think Uniswap). On Solana, you have a lot of options when it comes to swaps. We will do a more in-depth post on this step later, but for now you can look at several different options with some of the features:

Let’s say you bootstrapped $200,000 in liquidity with a finishing price of $0.50 per token. After the liquidity bootstrapping is finished, you could go create a pool on any of these services with:

  • $100,000 USDC
  • 200,000 Your token

This will start the price of the pool out at $0.50 with $100k in liquidity. You can then invite your community to provide additional liquidity on this pool.

· 4 min read
Noah Prince
Bryan Zettler
Frank De Czito

Strata Investors

We are thrilled to announce a $1.5 million strategic round for the first permissionless token launchpad on Solana led by Multicoin Capital with participation from Solana Ventures, Starting Line, Asymmetric Partners, and Alameda Research.

Several notable angels also participated including:

  • Bill Lee, the co-founder of Craft Ventures
  • Chris McCann, a Partner at Race Capital
  • Saurabh Sharma, a Partner at Jump Crypto
  • Tristan Yver, the Head of Strategy at FTX.
  • Roneil Rumburg and Forrest Browning, founders of Audius

Our funding announcement heralds the Strata Launchpad, the first permissionless no-code token builder on Solana. Our Launchpad makes it simple to launch tokens for Creators, GameFi, DAOs and Sub-DAOs as well as a social mesh for creating networks of social tokens. Launching a token should be as easy as launching a website with Shopify or Wix.

This funding will be used to further build our team as we help the community launch their tokens and expand the use cases for Strata tokens within the ecosystem. We’re hiring in both engineering and business development!

We would also like to thank the Solana community and our advisors for supporting us on this journey. From the various hackathons and hacker houses to the tireless work from the community on tools and composable protocols, we truly stand on the shoulders of giants.

Strata Protocol

Strata is the best way for creators, builders, and entrepreneurs to integrate tokens, and novel experiences around tokens, into the heart of their communities. Strata Launchpad, a no-code token builder built using Strata, makes it incredibly easy to create and launch tokens with a few clicks.

Strata has a variety of options for launching social tokens, ranging from fully managed AMMs with frictionless token swaps to Initial Token Offerings (ITOs) using a technical innovation called a Liquidity Bootstrapping Curve (LBC). The LBC is similar to Liquidity Bootstrapping Pools (LBPs) on Ethereum, though notably they do not require any initial liquidity. These technologies enable price discovery and allow for Strata tokens, such as social tokens, gamefi tokens, or sub-DAO tokens, to start trading day one.

Strata tokens are built for composability. Tokens created with Strata are just normal SPL Tokens with Metaplex token metadata. This means they will work with your existing wallet and can be used out of the box in a wide variety of DeFi protocols. Strata is fully open source, and comes with a suite of developer tools so that you can embed your token anywhere.

Strata ships with a social framework that allows networking interrelated tokens to bind their directional success. Most notably, this framework can be used to create Sub-DAOs where the Sub-DAO token is directionally bound to the parent DAO. Viewed through a social lens, token collectives are a crypto-linked way to create micro economies within a larger organization. Like-minded creators can pool resources together and bond their directional success to other members of the collective.

Strata Protocol plans to work with the Solana Ecosystem to facilitate the launch of new tokens and develop them in innovative ways. The ease of our launchpad opens up the token economy to new users facilitating the growth of web3 by lowering the barrier to entry.

Strata Protocol is allowing tokens to be used with previously unexplored utilities. Strata’s diverse toolkit has already enabled platforms such as to create social tokens for hundreds of users. GRAPE protocol has created Sub-DAOs using Strata Protocol enabling their community to monetize their skillsets via social tokens. Strata Protocol bounties enabled the Pandas Not Plastic campaign to raise over 1000 Sol for charity.

What’s coming next

Integrations! We are going to add support for using your Strata token in a variety of places, from NFT marketplaces to governance and DAOs.

Our goal is to help the community innovate. Want to launch a token but not sure how? Feel free to reach out on twitter and we can help you brainstorm!

Where to find us:

  • Follow us on twitter
  • Join our discord
  • We’re Hiring! Apply here
  • Our source code is here
  • Our audit via SlowMist for the token bonding contract here

· 4 min read
Noah Prince


What is Blockasset?

Blockasset is a platform on Solana for verified athlete tokens and NFTs. They specialize in social crypto assets for athletes. Athlete tokens on blockasset are a new p2p economy that rewards community engagement and early adopters. Blockasset is pushing the bounds of fan engagement in the sporting world.

Let's take a closer look at these Athlete Tokens, how they work, and how you can get your hands on one.

What is an Athlete Token?

An athlete token is a subset of social tokens. Owning a social token is like joining a fan club. It gives you access to exclusive content, and can be exchanged for priceless experiences. For example, these athlete tokens will give access to training sessions, VIP sporting event tickets, signed merchandise and more. While an athlete token could increase in value, they are not an investment or security. Instead, the primary use of an athlete token is to be consumed.

The value of an athlete token is related to the power of the community behind them.

$BLOCK is the token of blockasset. You'll use this token to interact with everything in the Blockasset ecosystem, including to purchase these athlete tokens.

How does it work?

Blockasset is using Strata Protocol to do permissionless launches of their athlete tokens so they are immediately tradable. No need for market makers or LPs. Strata seamlessly handles the supply and liquidity.

While this sounds complex, from a fan perspective it's as easy as clicking "buy".

tl;dr: The price of the token goes up as tokens are purchased and down as tokens are sold, following a mathematical curve

This is accomplished using an Automated Market Maker (AMM) called a bonding curve.

The best way to visualize this process is with poker chips. Imagine there is a cash register. When you put dollars into the register, the cashier gives you chips (tokens). When you return the tokens, the cashier gives you dollars back. When you give Strata Protocol $BLOCK, it gives you Athlete tokens. When you sell them back to the protocol, it gives you $BLOCK. The more of the athlete token in circulation, the more $BLOCK it costs to purchase a token and the more $BLOCK you receive by selling tokens.

Athlete tokens are currently priced on a square root curve. This means the price is related to the square root of the total supply of athlete tokens. Here's a visualization:

Square Root Plot

The launch day prices may differ, but the curve will have the same shape.

🔥 Sponsored Burn 🔥

If the price of a token is related to the number of tokens in circulation, how does burning tokens raise the price?

In a typical sell operation, your athlete tokens are burned in exchange for $BLOCK tokens. This means that both the supply goes down and the amount of $BLOCK in the cash register. What happens if you don't take any block from the cash register? This should make all existing athlete tokens worth more $BLOCK.

When athlete tokens are burned for experiences, all circulating athlete tokens are backed by more $BLOCK. This leads to several innovative tokenomics models.

Royalties and NFT Holders

When an athlete token is purchased, a percentage of the sale is taken in royalties. This functions similar to NFTs, where a percentage of each sale is sent to the creator. The blockasset team will be routing a portion of these royalties to the athlete, and a portion of the royalties to NFT holders based on rarity. This means that NFT holders will accumulate athlete tokens which they can exchange for experiences.

The Fair Launch Window

When an athlete token launches, the price will be fixed for 30 minutes. After 30 minutes, the athlete token will gradually transform from fixed price to a square root curve. This results in upward price pressure with increased price sensitivity.

If you would like to learn more about this process, you can read on here

· 2 min read
Noah Prince
Bryan Zettler

Open Collective


If you have been following closely to our small corner of the web you should be familiar with the Open Collective and the utility OPEN provides. If not, you can read more about it here

In short, Open Collective is the default collective of the Strata Protocol. And OPEN is the token for this collective. Any token made on Strata that isnt directly bonded to SOL, USDC, or any other cryptocurrency will be automatically bonded to OPEN by default.

The bonding curve for OPEN will become unfrozen at 9:00AM UTC Today. It is setup in a way to provide a fair launch to all who participate in the early moments of its price discovery. If you would like be one of those participates, please ensure you have a Solana wallet and have funded it with SOL. After that, all you need to do is wait for the curve to become unfrozen and utilize the UI below.


The OPEN token will launch on a bonding curve with the formula P=cSkP = c * S^k

The parameters for the OPEN fair launch are as follows.

  • First 6 hours of launch the curve price remains fixed P=0.005P = 0.005
  • 6 hours after launch there will be a 9.09091% bump PcS(1/10)P \approx c * S^{(1/10)}
  • 12 hours after launch there will be a 7.57576% bump PcS(1/5)P \approx c * S^{(1/5)}
  • 24 hours after launch there will be a 8.33333% bump PcS(1/3)P \approx c * S^{(1/3)}
  • 36 hours after launch there will be a 8.33333% bump PcS(1/2)P \approx c * S^{(1/2)}
  • Beyond 42 hours the curve will have reached its final slope

Whenever the bonding curve steepens resulting in an increase in price, there is a temporary tax imposed on selling. This removes incentive for bots to pump & dump the launch

· One min read
Noah Prince
Bryan Zettler

Wumbo Open Beta OPEN Distribution

If you participated in the beta of, you should have been airdropped netbWUM. A token which represented your overall total earnings from the beta. If you ended up holding it and not swapping for SOL in the first round of the beta distribution then congrats!

The time has come for you to be able to swap the netbWUM to OPEN, the first collective launching on Strata and the default collective for any unbonded social token. You can read more about the Open Collecive here.

At the time of this post, and the decommisioning of the netbWUM to SOL exchange, there was 388.57 SOL left unclaimed in the beta rewards pool. We have gone ahead and added an additional 10% (38.857)SOL to the pool as a thanks for sticking with us and converted it all to OPEN.



Chrome Webstore

You can now download the latest version of on the Chrome Webstore

· 14 min read
Mark Roszak
Noah Prince

Strata Social Tokens give content creators the tools they need to easily create and manage their own personalized cryptocurrency. This comes with unequaled opportunities for monetization and community engagement.

New opportunities often expose us to risk, especially where we lack information. If you are a creator based in the US, it is important that you stay on the right side of US securities laws. We created this guide as a primer for everything you need to know before you mint your first Social Token.


Securities can be a complex and evolving area of law. This post is intended to provide general educational information, but is not legal advice. Its content was overseen by lawyers retained by and Strata, but they are not your lawyers. If you have any questions about securities laws, contact an attorney licensed in your jurisdiction for advice on what you should do to stay legal.


Many token projects have had success reducing the risk of being deemed a security by focusing on one of the following features:

Provide non-financial benefits to limit risk of security status

If you're based in the US or offer your Social Tokens to US individuals, you should set up your Social Token to provide rewards or perks to your fans, but nothing that could be considered profit (such as an appreciation of capital or a share in your earnings). You should likely avoid even hinting that the coins could appreciate in value or "pay off" somehow. Be straightforward. Let your fans know that your Strata Social Tokens are a great way to show their appreciation for what you do, and can carry some nifty perks as well — maybe an exclusive video or a chance to buy tickets to a show early. But nothing more.

Your aim should be for your tokens to be consumed; the more these tokens are meant to be exchanged for status, perks, goods, or services, the less they look like a security. This aligns well with the royalties mechanic — you receive royalties when tokens are being transacted. Look to provide value in exchange for holding or paying tokens.

Ensure any increase in value of Social Token is the result of community activity

If purchasers of your token are not motivated by your entrepreneurial activities, the token may not be considered a security. The best example is an unclaimed token, or a token you have claimed but are not actively participating in. In this case, the value of the token is derived from community efforts (the fans).The value can also be derived from applications like, which is a platform built on Strata Protocol that brings Strata Social Tokens directly to social networks. is allowing users to gain utility from using the token; such as displaying it in tweet replies as a symbol of support. In this case, an argument can be made that the value of the token is derived from, the Strata Ecosystem, and the fans.

US Securities Law

So, what is a security, anyway, and why is it a big deal?

The Securities Act of 1933 and the Securities Exchange Act of 1934 are the bedrock of securities laws in the United States. Enacted in the wake of "Black Tuesday" and the stock market crash of 1929, they impose strict regulations on the sale of "securities," defined broadly to include a wide range of instruments, including "investment contracts."

But what is an "investment contract?" In SEC v. W. J. Howey Co., 328 U.S. 293 (1946), the U.S. Supreme Court formulated what came to be called the Howey test: a set of four factors. If all four factors are present in a given instrument, it's an investment contract (and thus a security). They are:

  1. An investment of money,
  2. In a common enterprise,
  3. With a reasonable expectation of profit,
  4. Derived solely from the entrepreneurial or managerial efforts of others.

When considering whether a given instrument is an investment contract, it's important not to look only at the form and terms of the instrument itself, but also on its context and circumstances.

Whether or not a given instrument is a security is critically important. It's generally illegal (outside certain exemptions) to offer or sell securities across state lines unless they're properly registered---and the registration requirements can be burdensome. But if an instrument isn't a security, those requirements don't usually apply. If you're considering offering a Social Token or similar crypto coin or token, whether or not your coin is a security is a critical distinction: it can mean the difference between spending substantial time and expense dealing with red tape or not (with the possibility of Securities and Exchange Commission ("SEC") administrative action, a lawsuit, or criminal penalties for failure to comply). 

The Howey test and crypto: more than you wanted to know.

If you plan to offer a Social Token, you'll want to ensure that it's not a security under U.S. law by using the Howey test to evaluate its status (and remember, all four factors need to be met for it to be a security). Let's take a closer look at the four Howey factors to see what they mean for creators using crypto to connect to their fans.

Factor 1: An investment of money

Do you plan to allow fans (or, for that matter, anyone) to purchase your Social Tokens? That's probably an investment of money for Howey purposes, which does not need to take the form of cash. U.S. dollars qualify, but so do other exchanges of value, such as Bitcoin, Bitcoin Cash, Sol, or Ethereum.

Factor 2: In a common enterprise

This is somewhat tricker to consider: courts in the U.S. are actually split with respect to what test should be applied to determine whether the common enterprise factor of Howey has been met. Because it's difficult or impossible to determine beforehand which court's rule applies, we need to look at all of them to be on the safe side.

Most courts require a finding of "horizontal commonality," which generally requires that the funds or assets of purchasers are pooled and that such purchasers proportionally share profits and risks associated with the enterprise. Generally, horizontal commonality is present "when the fortunes of each investor depend upon the profitability of the enterprise as a whole," often combined with a pro-rata distribution of profits.

So if you're a creator planning to issue a Social Token, the key question is whether you are pooling the assets of the Coin Sale purchasers in a common enterprise. Consider: are the rewards associated with your Social Tokens going to go up or down in value for each individual Coin holder in line with your entire Coin ecosystem? If so, you may have horizontal commonality, which in some courts, would meet the second Howey factor.

A less popular approach involves determining whether there is "vertical commonality," which typically focuses on the relationship between the investment contract's promotors and the purchasers. Vertical commonality can be further broken down into "broad vertical commonality" and "narrow vertical commonality."

Under broad vertical commonality, used by some courts, "the investors are dependent upon the expertise or efforts of the investment promoter for their returns." Unlike horizontal commonality, broad vertical commonality can exist even in the absence of other investors in a scheme.

Narrow vertical commonality (used by the Ninth Circuit Court of Appeals) examines the relationship between the purchaser and the promoters and asks whether the fortunes of the investor are inextricably interwoven with and dependent on the efforts and success of a promoter. This test ignores whether funds have been pooled, and can exist on a one-to-one basis between an investor and purchaser.

Under these approaches, when you consider your Social Token, ask yourself: are the rewards associated with your Coins dependent on your expertise or efforts? Or, is the success of any Coin holder in receiving rewards interwoven with and dependent on your own efforts and success? If so, you may have vertical commonality, which in some courts, would meet the second Howey factor.

Factor 3: With a reasonable expectation of profit

The third Howey factor is whether purchasers of an investment contract reasonably expect profits. "Profits" has a limited meaning under federal securities law, requiring either the appreciation of investment capital, or a participation in earnings.

In its investigations, the SEC often examines the marketing efforts of the promoters and the materials provided to potential purchasers to ascertain the reasonable expectations of the investors. With regard to crypto currencies and tokens, for instance, the SEC has focused heavily on statements promising a return in the form of profit sharing and capital appreciation of tokens, and argued in court that promotion materials were a critical element in establishing that the investors were expecting profits.

But where a purchaser is motivated primarily by the desire to use or consume the item purchased, courts have found that there is no expectation of profit. Under those circumstances, "securities laws do not apply."

The upshot of this for Social Tokens is that the third factor of the Howey test can be avoided (and thus, securities status can be avoided) by ensuring that the coins carry no expectation of profit. The coins should not be marketed as an "investment"---not even subtly or implicitly---and should carry no language that suggests that participants can "grow" or "increase" anything of value from their purchase price, or that they can participate in your earnings as a creator.

If the SEC ever investigates, they'll likely look carefully at the statements you make in promoting your coins. If you watch what you say, and are careful to emphasize that the coins can only be used or consumed---e.g., by trading them in for perks or privileges which are not exchangeable for cash or other cash substitutes---you may stand a better chance of avoiding legal difficulty.

Factor 4: Derived solely from the entrepreneurial or managerial efforts of others

The fourth Howey factor examines whether profits expected by purchasers are derived from the managerial or entrepreneurial efforts of the promoters or a third party. In other words, the key element is who makes the efforts which affect the success or failure of the enterprise: the investor, or someone else.

With regard to digital assets, including cryptocurrency coins and tokens, at least one SEC official has expressed the view that a network that is "sufficiently decentralized ... where purchasers would no longer reasonably expect a person or group to carry out essential managerial or entrepreneurial efforts ... may not represent an investment contract."

This is good news: under this view, most virtual currencies proposed in token offerings are not inherently securities in themselves. Instead, the nature of the transaction is what establishes an investment contract. Potential factors in this determination include the nature of the currency's distribution and whether such distribution mechanisms are tailored towards use or consumption, the nature of a project's promoters and whether they are raising excessive funds, and whether there are information asymmetries.

Adding to this, in 2019, the SEC Strategic Hub for Innovation and Financial Technology released guidance providing a framework (the "Framework") for analyzing whether certain digital assets, including cryptocurrency coins and tokens, are "investment contracts" under the Howey test. The Framework does not constitute new law and is non-binding, but it currently serves as the most comprehensive look at the SEC's approach to reviewing certain digital assets. It also introduces the concept of an "Active Participant" with regard to the fourth factor of the Howey test.

The Framework defines an Active Participant ("AP") as "a promoter, sponsor, or other third party (or affiliated group of third parties)," and looks at the group collectively when determining if their "essential managerial efforts ... affect the success of the enterprise, and investors reasonably expect to derive profit from those efforts." In other words, an AP is someone whose efforts investors reasonably rely on for their profit.

The Framework provides characteristics of what it means to rely on the "efforts of others:" the more of these characteristics that are satisfied, the higher the likelihood that the fourth factor of the Howey test is satisfied. These characteristics include, among others:

  • An AP is responsible for the development, improvement (or enhancement), operation, or promotion of the network. 
  • There are essential tasks or responsibilities performed and expected to be performed by an AP, rather than an unaffiliated, dispersed community of network users (a "decentralized" network). 
  • An AP creates or supports a market for, or the price of, the digital asset.
  • An AP has a lead or central role in the direction of the ongoing development of the network or the digital asset.
  • An AP has a continuing managerial role in making decisions about or exercising judgment concerning the network or the characteristics or rights the digital asset represents.
  • Purchasers would reasonably expect the AP to undertake efforts to promote its own interests and enhance the value of the network or digital asset.

That's a lot to take in. But the upshot is that if participants in your Social Token system reasonably expect to make a profit, the extent to which you or someone working with you manages, operates, or oversees your coin ecosystem could determine whether investors reasonably expect your efforts to be what generates that profit. And if they do, the fourth factor of the Howey test may be satisfied, which puts your coin one step closer to being classed as a security.

Wrapping up

As you can see, evaluating whether your Social Token is a security under U.S. laws is tricky business. The regulations are intricate and can be challenging, even for trained experts.

But remember: because all four Howey factors are required for your Social Token to be a an "investment contract" (and thus, a security), avoiding meeting any one of the factors will generally be sufficient to avoid security status.

Probably the easiest to avoid is the third factor: the expectation of profit. Due to the narrow definition of "profit" under securities laws, if you set up your Social Token to provide rewards or perks to your fans, but nothing that could be considered profit (such as an appreciation of capital or a share in your earnings), you may likely avoid accidentally creating a security.

Because any investigation would look at your statements and those of anyone else working with you in promoting the coin, it's probably a good idea to avoid making broad, sweeping announcements. You should likely avoid even hinting that the coins could appreciate in value or "pay off" somehow. Be straightforward. Let your fans know that your Strata Social Tokens are a great way to show their appreciation for what you do, and can carry some nifty perks as well — maybe an exclusive video or a chance to buy tickets to a show early. But nothing more.

Your tokens are meant to be consumed and traded; this aligns well with the royalties mechanic — you receive royalties when tokens are being transacted. Look to allow people to trade tokens in exchange for perks, goods, or services. Purchases should be motivated primarily by the desire to use or consume the item purchased.

Another way to position your token is to asses where the value of the token is derived. If purchasers of your token are not motivated by your entrepreneurial activities, the token may not be considered a security. The best example is an unclaimed token, or a token you have claimed but are not actively participating in. In this cases, the value of the token is derived from community efforts (the fans). The value is also derived from applications like allowing users to gain utility from using the token as a status symbol. In this case, an argument can be made that the value of the token is derived from, Strata, and the fans. If your token is "sufficiently decentralized," in that it is governed by the community, you may have an argument that it is not a security.

This can all seem overwhelming, but you are already on the right track by reading through this document. If you pay careful attention and think ahead, you may find yourself in a better position to avoid inadvertently violating federal securities laws than another creator who didn't do their homework.

Happy building!

· 10 min read
Noah Prince


Automated Governance on your Anchor Programs

Have you been deploying your programs with solana program deploy with deploy keys on your local file system? While it works for prototyping, it's not great for a production program on mainnet that's holding real money.

Local file system deploy keys are a security risk. If your computer is compromised, a hacker could take the deploy keys and do whatever they want with your program; including siphon all funds stored in or owned by the program.

Multisigs are great for simplicity, but with governance you can transfer voting shares around. You can also change the voting settings as the project evolves. It's also got a nifty UI!

In addition to the security risks of deploying locally, there's also several risks associated with manually deploying to mainnet, including:

  • Accidentally deploying dev code to mainnet because you ran the wrong command
  • Updating the program but not the IDL
  • Forgetting to publish a verified build
  • Inconsistency with your git repository and what's deployed, making debugging difficult.

Let's instead set up automation so we get something like this:

Governance on Mainnet

By the end of this guide, we'll set up automation such that when you issue a release on github, you'll get a Governance proposal to deploy the contract. All you need to do is vote yes on the proposal, then execute the transaction. For devnet, you'll get a new proposal every time the rust code changes on master.


Do this in devnet before you try it on mainnet

In this guide, we're going to:

  • Issue governance voting shares
  • Setup SPL Governance around an Anchor Program
  • Deploying a program using governance without CI/CD
  • Automate program deployments using CI/CD
  • Setup Anchor Verifiable Builds

Issue Govenance Voting Shares

Governance works by creating and executing proposals to upgrade the program. These proposals are voted on by governance token holders. In a simple case, the governance token holders may just be the founders of the company. If all hold an even number of tokens, this acts like a multisig.

Let's issue a governance token. We're going to use Metaplex spl-token-metadata to asssociate a name and symbol with our governance token, so it's easy to use in wallets. You can edit the name and symbol in createMetadata to name your own token.

import { ASSOCIATED_TOKEN_PROGRAM_ID, Token, TOKEN_PROGRAM_ID, u64 } from "@solana/spl-token";
import { Connection, Keypair, sendAndConfirmTransaction, SystemProgram, Transaction } from '@solana/web3.js';
import { createMetadata, Data } from "@strata-foundation/spl-utils";

Take note of the mint address above. Mine was "65uCXAukbwXFMUdT75SjmBfr6HhFL4h17QtzsM5MdmLD"

Change your wallet network to devnet. If you check your wallet, you should see our test governance token. After you're done with this guide, you can send it to anyone you'd like.


Setup SPL Governance

First, to setup governance we must have deployed the anchor program once. If you haven't yet, run

anchor build
solana program deploy ./target/deploy/<YOUR_PROGRAM>.so -u devnet

You'll also want to init the idl:

anchor idl init <YOUR_PROGRAM_ADDRESS> --filepath target/idl/<YOUR_PROGRAM>.json --provider.cluster devnet

Since you likely deployed with a local deploy key, you will want to temporarily transfer the authority to your current web wallet.


This command cannot be undone without the new upgrade authority signing off. Make absolute sure your wallet address is correct here.

solana program set-upgrade-authority -u devnet <PROGRAM_ADDRESS> --new-upgrade-authority <YOUR_WALLET_ADDRESS>

Now we will need to create a realm. Navigate to:

Once you connect your wallet, you should be able to click Create Realm:

Add Realm

You'll want to choose the second option, as bespoke realm:

Bespoke Realm

Fill out this form with your mint from earlier as the community mint id:

Realm Form

You should be taken to a new page. This is your realm page. Bookmark this.

Deposit your governance tokens using the deposit button

Now, we're going to add our program. Click the plus button next to assets to add a program asset:

Add Asset

Fill out your program information. You can also fill out voting threshold information:

Create New Program Governance

Deploy Your First Update

Deploying with governance works in two steps. First, we'll write a buffer to Solana. Then, we'll create a Proposal to deploy that buffer. This allows us to separate building from signing to deploy.

solana program write-buffer /path/to/your/deploy/ -u devnet

This write buffer will be owned by you, so let's transfer it to your governance. To get the governance id, click your program under "Assets" then click Upgrade:


You should see Upgrade Authority. Copy that to clipboard

Gov ID

solana program set-buffer-authority <YOUR_BUFFER_FROM_ABOVE> --new-buffer-authority <GOVERNANCE_ID_FROM_CLIPBOARD> -u devnet

Now that we've deployed our buffer, let's propose an upgrade to our contract. Input your buffer from above into the upgrade form

Upgrade Form

Once you've created your proposal, you will be able to vote on it like so:

Vote Yes

Once the vote passes, click on the instructions drop down and scroll down to execute:


Done!! Now you've succesfully deployed your first program using SPL Governance!

CI/CD - Automation

If you're like me, you're probably thinking: "this could use some automation."

Yup. Let's set this up.

First, let's transfer the IDL to governance:


This command cannot be undone without the new authority signing off. Make absolute sure the governance address is correct here

Gov ID

Make sure you're using this address, and double check it in the explorer to make sure it's owned by the governance program.

anchor idl set-authority --provider.cluster devnet --program-id <PROGRAM_ADDRESS> --new-authority <GOVERNANCE_ID>


We'll need two github secrets

  • DEPLOY_KEYPAIR - A keypair that we will use to deploy buffers. This won't have permission to change the program, but we will need to load it with SOL to write the buffers.
  • ANCHOR_TOKEN - The authentication token for

To add a secret, navigate to Settings > Secrets in github:

Creating a Secret

First, head over to and sign up for an account. This is where we'll post our verified builds.

Click your Profile in the top right > Account Settings > New Token. Create a token for CI/CD. It will say:

anchor login <ANCHOR_TOKEN>

Copy that down. Fill that in for ANCHOR_TOKEN

Next, let's generate a keypair for deploys:

solana-keygen new -o deploy.json

Now cat that file and copy its contents and fill that in for DEPLOY_KEYPAIR

cat deploy.json

Deploy Wallet

We need to set this deploy wallet up with permissions to create proposals and write buffers. First, it will need some SOL:

Get the address:

solana address -k deploy.json

Now airdrop some sol to it (run this a few times). On mainnet, you will need to fund this wallet:

solana airdrop -u devnet 2 <DEPLOY_ADDRESS>

You may want to store the deploy key somewhere safe. Now delete that file so it cannot be compromised:

rm deploy.json

Now, go back to the govenance UI and withdraw your tokens. You will need to send 1% of them to the deploy wallet so that it can create proposals.

Now, we need to deposit those voting tokens. You can add the deploy to your wallet in phantom via "Add / Connect Wallet" > "Import private key". Re-visit your realm page using this wallet and deposit the tokens.

Github Actions

You'll want to setup github actions for your repo. Strata has two main workflows relating to this:

  • Devnet Proposal - When a commit is pushed to master, if the rust contracts have changed, create a proposal to devnet governance to release the new version
  • Mainnet Proposal - When a github release happens, if the rust contracts have changed, create a proposal to mainnet governance to release the new version

To get these in your repo, you'll want to clone

You will need to copy and edit the variables in:

  • .github/workflows/devnet-proposal.yaml - When a commit is pushed to master, if the rust contracts have changed, create a proposal to devnet governance to release the new version. Make sure to set governance to the dev governance address we got from the Upgrade Form.
  • .github/workflows/mainnet-proposal.yaml - When a github release happens, if the rust contracts have changed, create a proposal to mainnet governance to release the new version. Make sure to set governance to a production governance, you will need to follow the above steps on mainnet after you verify it works on devnet.

In particular, make sure there's an entry for each program, and that you set program, program-id, network, keypair, governance, name, description. If signatory is set, that account must "sign off" on the proposal to get it out of draft stage.

These workflows rely on some actions that you will probably not need to edit, but will need to copy:

  • .github/actions/anchor-publish - Action that publishes your anchor contract to Anchor Verified Builds.
    • If you do not want to do this, simply comment out this action in .github/workflows/mainnet-proposal.yaml
  • .github/actions/upload-bpf - Action that builds your smart contract and uploads it to solana via write-buffer
  • .github/actions/create-proposal - Uses a script we wrote to create a governance proposal to set your program to the one deployed via upload-bpf
  • .github/actions/deploy-with-gov-proposal - Execute upload-bpf then create-proposal, only if a proposal hasn't been created for this action.
  • .github/actions/setup - General setup
  • .github/actions/setup-anchor - Setting up anchor cli
  • .github/actions/setup-solana - Setting up solana cli

Test It

Create a fork of your repository. These hooks only run on the master branch, so you'll want to use a forked version of your repo until you get them stable.

Add the secrets to this fork, then push these actions to master. Go to the "Actions" tab on github and watch them go:


If it succeeds, you should be able to go to your realm and see the proposal!

Vote in Progress

Congrats! You're now running program governance on auto-pilot!

To test mainnet proposals, click the releases button on the side of your github repo. Draft a new release and publish it. Then go to the actions tab and make sure it runs successfuly.


There's a lot of steps in this process, it's easy for a misstep. If you're having trouble debugging, you can come join us in the Strata discord and we'll do our best to help you out:

Want to see more like this?

We'll be posting tips and tricks as we solve problems ourselves. If you're interested in launching a token or token(s), let us know! We can help with that too!

· 6 min read
Noah Prince
Bryan Zettler

Open Collective

The Open Collective

If you're not familiar with Strata, you can read more about the protocol here

A collective is for like minded creators that want to pool resources and bond their directional success to others. Collectives also allow fans to take directional positions on the success of groups or categories rather than individuals alone. Viewed through this lens, collectives can be seen as idea indices.

The Open Collective (OPEN) is the default collective on Strata. When a token is created without a collective or base mint specified, the default is to place that token into the Open Collective.

While some collectives can be exclusive, requiring permission to join, the Open Collective allows anyone to join. The Open Collective also takes no fees or royalties.

The Open Collective is truly decentralized. We, the Strata Team, get no cut of the OPEN token. We believe that taking a cut would stifle innovation.

Anatomy of the Open Collective

  • Token. This is the OPEN token. Every member of the collective will be bonded to it via a Bonding Curve
  • Bonding curve. Users can quickly purchase OPEN tokens using the SOL/OPEN bonding curve. The price is a function of the current supply.
    • Royalties. OPEN has no royalties on buy/sell through the bonding curve.
  • Exclusivity. The OPEN collective allows anyone to bind their token to OPEN and join the collective. It does not require sign off for new members
  • Configuration.
    • Limited royalties on sell: Users cannot set sell royalties unreasonably high, devaluing the token.
    • Unclaimed Token Settings
      • Symbol: UNCLAIMED
      • Social Token royalties on buy: 5%
      • All royalties are owned by the person who claims this token

Why buy OPEN?

Applications like use the Open Collective to make it possible to create tokens in one-click for users that have yet to join the platform.

As expands, OPEN-based tokens will be created for a variety of social media accounts, including Twitter.

The Community

Ultimately, the decision to buy OPEN is an investment in the community that will form around the Open Collective. It is backing every creator and unclaimed token that is based on the Open Collective.

No fees

The OPEN collective takes no fees. This means that, while you are still exposed to risk in fluctuating price, it costs nothing but the Solana transaction fees to get OPEN tokens.

This also makes the open collective a good choice for a creator that wants a social token, as there is no middle-man taking a cut.

The hope is that the Open Collective pushes future collectives to innovate. If a collective is going to pool resources in the form of royalties, it should offer something in return. That might mean building a website, setting up a storefront, or just riding on the network effects of a strong collective.

Network Effects

Creators can use the Open Collective to join an existing, established network. As the network of open collective improves its value, the value of every individual social token in the network is improved.


The Open Collective limits royalties on token sales. This keeps the authority on a token from completely devaluing the token for all holders. While OPEN tokens do still carry risk, the risk is in token holders selling and not necessarily changes from the authority.

The Open Collective ensures that all unclaimed tokens follow a similar, fairly shaped bonding curve. It also ensures that royalties are set aside to incentivize the token's owner to claim the token.


Buying OPEN will allow you to buy the social tokens of anyone within the open collective

OPEN Risks

OPEN is just one of many collectives that will form on Strata. It has a distinct advantage in that it is the default collective, but it is also not being managed as an organization.

No fees

No royalties means that the Open Collective has no treasury. The Open Collective is not an organization. It will not provide services because it does not have funds to do so.

Members of the collective may choose to provide services because they are incentive aligned with the Open Collective.

No Team

Neither the team nor the Strata team own, or are taking any share of the Open Collective. As such, the Open Collective is not backed by a team. While the community that forms around the Open Collective will drive it forward because of the incentive alignment; there is no core team.

OPEN is a truly decentralized utility token.

OPEN in no way represents ownership in Strata or

The teams of both Strata and want to see the Open Collective succeed because they want to see the entire protocol succeed. They want to drive value into this newly forming economy. Neither team, however, will ever pick sides or choose winners amongst collectives.

Collective Movement

While not currently supported, the goal is to allow free movement of ones token from one collective to another. This ability may hurt or help the open collective. This will lead to higher competition between collectives. This could either drive users back to the Open Collective, if other Collectives fail to deliver. Or it could drive users away from the Open Collective, as other collectives that take royalties provide greater utility.

OPEN Fair Launch

The OPEN token will launch on a bonding curve with the formula

P=cSkP = c * S^k

Choices for k and c have not yet been finalized

This plot visualizes the formula when c=1c = 1 and k=0.5k = 0.5


Reward Early Adopters, not Bots

The curve above rewards whoever gets their transactions through first on launch day. In practice, that will be bots.

The solution to this is to have a curve that changes shape over time. All day-1 buyers get the same price. The bots had no advantage in getting their transactions through sooner, as they received the same price as everyone else.

Launch Day

After day 1, the curve begins to steepen:

Launch Day

Over time, the curve steepens to its final shape:

Final Curve Shape

· 6 min read
Noah Prince
Bryan Zettler

Strata is a social token protocol that makes it possible to build and monetize tokenized economies around a person, idea, or collective. Powered by Solana, it is the fastest and least expensive way to launch a token. After months in development, the Strata protocol was officially open sourced today. We owe a big thanks to the community and the Solana community for helping us get here. Get started here

Strata Social Tokens unlock local economies around individuals while Strata Collectives make it possible to pool resources and structure incentive models around networks of social tokens. The combination of these composable token mechanisms will fuel not only the Creator Economy, but will unlock a new Cooperation Economy that compounds the value of social token networks. Strata has the potential to upend entrenched, royalty-seeking business models which have taxed creators for decades and unlock a wider design space for social tokens.

Strata’s mission is simple: make it radically easier for people to coordinate social communities. The definition of community is up to you. Whether that means creating a community exclusively for your fans, building a membership-based record label, integrating social tokens into an existing network, or building local chapters within divisions for an international organization — the decision is yours to create.

Strata is for creators, builders, and entrepreneurs who seek to integrate tokens, and novel experiences around tokens, at the heart of their communities. No project is too big or too small — social tokens should be, and will be, everywhere. In addition to unlocking social tokens on Solana, Strata makes it incredibly easy and inexpensive to launch and experiment with them.

How Does Strata Work?

Social tokens are tokens typically associated with an individual, idea, project, or community. There are many flavors of social tokens but they typically provide access, status, and utility related to the individual they represent. Strata takes this idea further and provides a new way to bundle social token networks into collectives, which are networks of social tokens bound by a common collective token.

In addition to simple minting, Strata natively leverages automated market makers and bonding curves to guarantee liquidity for its tokens. If done right, there will be a long tail representing millions of social tokens powered by Strata. This ensures that there will always be a market for them.

Using Strata, creators can create, manage and build social tokens in just a few clicks. These tokens can be bound to SOL, USDC, or a collective.

Collectives are a new approach for like-minded creators to monetize the efforts of group cooperation. Collectives allow participants to pool resources under their collective token which is bound to their network of social tokens. They allow a community or business to structure incentive models designed to increase the value of the collective as a whole, in tandem with the efforts of individuals. Creators can join collectives by basing their tokens in the native collective token at the point of creation. Collective creators have the ability to make collectives open or closed.

Collectives allow fans and communities to take directional positions for the success of ideas, groups, or categorizes. Viewed through this lens, Collectives can be seen as an index for ideas. Imagine a group of artists forming a collective and working in partnership to create a custom marketplace for their genre. Or perhaps a Decentralized Autonomous Organization (DAO) formed by an organization of contributors with their individual tokens bound to the DAO token. Collectives are a way to form economies around ideas, and to seamlessly integrate Strata Protocol into your business model.

The first social token collective on Strata is the Open Collective (OPEN). The Open Collective was built to serve as the default collective for all social tokens issued on Strata, unless a creator specifically wishes to bond their tokens to SOL, USDC, or a new collective instead. The Open Collective serves as a springboard for creators and projects to get started quickly.

An example of one such project is, which was also developed by the Strata community. is a social token platform built on Strata that makes use of the Open Collective. It brings social tokens directly into social networks (Twitter, Twitch, Reddit, etc.) and makes it possible to see the economy surrounding an individual inline with their profile picture. Using, anyone can mint a social token that represents them or a creator they love. The value and mechanics of those tokens is up to them. For example, a creator could offer lunch with fans for the price of 100 of their native tokens; artists could offer pre-sales for limited edition works for fans who hold 1000 or more of their native tokens; brands may offer discounts for products for fans who burn 10 or more tokens, and so forth.

There are at least 5 projects currently building on Strata as we speak. Social tokens are an entirely new way for fans to engage the creators, brands, and stories they love. By building the core infrastructure and lowering the barriers to entry we hope to spur a tsunami of experimentation and innovation with social tokens.

Get started

The key to innovation is rapid iteration and exploration, and as such, Strata is completely open source and free for all to use. Get started here.

Strata is designed to become a standard for social tokens and bonding curves. The most innovative business models have yet to be discovered. As such, the smart contracts take no share of the tokens exchanged and the protocol remains as non-opinionated and flexible as possible. How you implement Strata is your canvas to paint.

You can customize everything from your curve's shape to its launch-time characteristics, to the royalties you collect, and so forth. This might sound complicated, but with sane defaults you don't have to reach under the hood.

Ready to get started? Here’s how you can create a social token on devnet right now:


Now display it in React!


Next Steps

Like what you see? Let’s build together! The community is great and we’ll be there to help you along the way—office hours, hands-on assistance, and more. We want to hear what you're building.

Not a dev? It’s all good. will be launching a chrome extension that makes it stupid easy to create social tokens with one click natively inside Twitter. It doesn't get much easier than that!

Join the Community