As builders, we strive to make history even when the market is bearish. Genopets helped us make history by raising over $1.8 million dollars using our Liquidity Bootstrapping Curve (LBC) for their KI Token launch. We joined forces with the Genopets team to support the launch of their KI token using Solana’s first permissionless liquidity bootstrapping protocol, the Strata Liquidity Bootstrapping Curve. Through this liquidity bootstrapping, Genopets were able to create some of the deepest liquidity for their holders on Orca. The project did not collect any funds from this raise, rather, they used the funds to ensure that KI holders could continue trading the token for the foreseeable future. We hope to see many other projects adopting this model to supply liquidity to their holders. Genopets is a project that is familiar with making history. They are the world’s first move-to-earn NFT game. Genopets offers a unique mobile RPG experience with an evolving spirit animal NFT personalized to you. You can battle your pets with friends to earn KI Tokens. These KI Tokens are the all-important in-game utility token for the Genoverse. They can be used for crafting, refining, and terraforming. The Launch​ Genopets sold out their KI token with nearly 7 hours remaining on their LBC. With no bots or clickfarms, the Genopets team was able to bootstrap liquidity while giving their community a fair price. From the outset of the three day launch, there were a good volume of transactions. In the beginning, this demand failed to match the falling price of the LBC. This is standard in an auction, as the price is meant to fall to the fair price. The auction started at a price of$0.50 cents, accompanied by a gradual fall to between $0.07 and$0.11. In the graph below, you can see the moment the fair price range was discovered. After about 2 days, demand started to match the fall in price, and in the graph below, you can see the demand spiked when participants saw a great price.

Using Orca.so, the Genopets team created an Automated Market Maker with a pool using the $1.8 million raised. The price discovery mechanism enabled the Genopets team to find the true value of their token by bootstrapping that liquidity raised via price discovery directly from the LBC right into an Orca liquidity pool. We would like to congratulate our friends at Genopets on a smooth and successful sellout of the KI Token, as well as the Genopets community for their new KI tokens! We also love the phenomenal custom UI skin the team created for their LBC launch. This custom skin demonstrates the ability to customize the underlying components of Strata to fit your needs. We look forward to making more blockchain history, and seeing the new ground that the Genopets team is sure to break. If you wish to launch a token or an NFT project with Dynamic Pricing, you can use our launchpad at app.strataprotocol.com. If you need any assistance feel free to hop into our discord and we’ll help you set it up. Strata and Metaplex partner to bring community driven pricing to public mints · 6 min read Strata and Metaplex partner to bring community driven pricing to public mints Today we’re excited to announce a new partnership with our friends at Metaplex that natively integrates Strata’s Liquidity Bootstrapping Curves (LBCs) into Metaplex’s CandyMachine creation process, bringing dynamic, community-driven pricing to public mints and a better user experience for creators and collectors alike. LBC mints are live today. Read the docs or watch this video to learn how to use it. Since the days of yore (read: 1 year ago), minting NFTs on Solana has been done with a fixed price. NFT Collections set a supply and a price, and hope that they sell out. When the SOL community was small, this methodology worked well. With increasing attention, mispriced mints have led to headaches for everyone involved and the network itself. An overpriced mint will not sell out, forcing projects to cut their collections short. An underpriced mint invites hoards of bots that can clog, and in extreme cases stop, the Solana network. Add to this situation that projects are now being listed on exchanges during the mint, and you have a recipe for disaster. Price discovery is happening anyway, and the profits are going entirely to flippers and bots. The solution: Dynamic Pricing. By partnering with Metaplex, we are pushing price discovery to be the new default for public mints. While whitelist mints can still be fixed price, price discovery is a necessity for public mints. Price discovery during the mint means that there is no advantage to spamming transactions or clicking “mint” before someone else. During a Dynamic Pricing Mint, the price floats according to supply and demand. As a minter, you decide what price you are willing to enter. As a creator, the proceeds of the price discovery help fund the project instead of short-term flippers. How does Dynamic Pricing work?​ Imagine you are auctioning an item, but you do not know what it is worth. A good auctioneer will first establish a baseline price, then let participants bid the price up. The price starts high, falls until someone bids, then rises with every bid. For example, if we were auctioning a grill, the auctioneer may start the price at$1000. Then $500. Then$200, where someone makes a bid. From there, the price may be increased through bidding to 350. How can this work with an NFT collection instead of a single item? The Strata Protocol LBC (Liquidity Bootstrapping Curve) does this by setting a starting price that falls over time and increases with each purchase. As an example, let’s take a look at the Divine Dogs Dynamic Pricing mint. Based on previous mints, the team estimated that the collection would sell out completely for somewhere between 2 and 2.5 SOL. Thus, they set a starting price of 3.3 SOL and a minimum price of 1.1 SOL. The plot below is the actual sales history of the mint. The price fell to around 2.6 SOL, followed by large demand from minters who thought the NFT was worth 2.6 SOL. As the price ran up, more minters bought, driving it up further. At 2.8 SOL, demand normalized and the price began to even out. The jagged lines down to 2 SOL show the users trying to time the dip. At 2 SOL—likely a psychological number—we can see the price rose rapidly as minters assumed the current price was the lowest they would see. The Strata + Metaplex Partnership​ We’re huge fans of Metaplex and already built a way to create dynamic pricing mints on Metaplex Candymachines, but the experience is far from seamless. The goal of this partnership is to drastically lower the barrier to entry to dynamic pricing mints, hopefully making the LBC mint mechanism a default for creators, collectors, and the Solana Network at large. The partnership will support deep, native integration in Metaplex including updates to the metaplex CLI and documentation that make dynamic pricing the default for public mints. Metaplex believes, as do we, that dynamic mints are ultimately better for creators, collectors, and the Solana Network. Better for Creators,Collectors, & Solana​ The dynamic pricing model is more equitable for both creator and collectors. Using this mint method collectors have a fairer chance to mint, the community incentivises collectors that are long-term holders vs. short-term flippers, and creators usually end up raising more money through effective, community-driven price discovery. A Fair Chance to Mint​ During a fixed price mint, the average collector does not stand a chance at minting a NFT. Professional scalpers deploy bots that submit millions of transactions while the average retail collector can usually only submit a handful. Even with anti-botting strategies, click farms stand a far better chance at minting NFTs than the intended minters. With dynamic pricing, every mint participant has a fair chance to mint at a price they deem fair. This is a step-function improvement in inclusion and accessibility for mints that radically expands participation from the hands of the elite few to a true-fan community of many. Disincentivize NFT Scalpers​ A classic NFT mint works a lot like concert ticket sales. Scalpers take the majority of the tickets and resell them to true fans, who are forced to pay a premium. The artist sees none of those profits. With NFT communities, this situation is even worse because, in addition to creators getting harmed, the Solana Network is also spammed by bots and flippers trying to make a quick score. An NFT community seeks long term holders. True believers that want to see the project succeed long term. The Strata LBC combined with Metaplex makes it easy to disincentivize NFT scalpers and incentivize long-term community members. Creators Can Earn More​ Creators have the potential to earn more using Strata’s Dynamic Mints in Metaplex. Creators do the heavy lift to bootstrap communities, and we think they should be rewarded for it—but not at the expense of the community. Since the money that would be going to bots is now going to the creators, projects will have a better chance to achieve their funding goals—from a more qualified community base. This should, in theory, make projects more likely to succeed by aligning the interests of creators and collectors. Better for Solana​ At the end of the day, minters are not the only victims of botters. Botting is clogging the network and will continue to do so unless something changes. Botters take advantage of the fact that mints are first-come-first-serve at a discount price. They submit millions of transactions so they have a better chance of being selected to receive the discount. With a dynamic pricing mint, this kind of behavior would only drive up the price and hurt the bots. As a result, bots are disincentives to participate, which improves the performance of the Solana Network for everyone. Get Started​ Jump into our docs here to learn more or watch the following video, which shows setting up a dynamic pricing mint with a whitelist: https://www.youtube.com/watch?v=i28CwS1QYAo Solana Composability vs Ethereum Composability · 9 min read 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. Background 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: 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: 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?​ How to Create a Solana Token on Strata · 7 min read 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” Select Fully Managed: Fill out the name, description, and photo for this token: Then, select a price sensitivity. Utility is generally a good place to start. 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 Wum.bo. 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. Done! You now have a tradable token! You can see this token on devnet here. 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 Select self managed: Fill out your token’s information like the name, symbol, image, and supply: 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. 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 Options​ • 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: 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 bootstrapped200,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

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.

Tags:

Strata Raises $1.5 million for the first permissionless token launchpad on Solana · 4 min read 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 wum.bo 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:​

• We’re Hiring! Apply here
• Our source code is here
• Our audit via SlowMist for the token bonding contract here
Tags:

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: 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.

Tags:

How to buy the OPEN token

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 = 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.005$
• 6 hours after launch there will be a 9.09091% bump $P \approx c * S^{(1/10)}$
• 12 hours after launch there will be a 7.57576% bump $P \approx c * S^{(1/5)}$
• 24 hours after launch there will be a 8.33333% bump $P \approx c * S^{(1/3)}$
• 36 hours after launch there will be a 8.33333% bump $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

Tags:

Wum.bo Beta OPEN Distribution

If you participated in the beta of Wum.bo, 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.

...

Tags:

Social Tokens and US Securities Law

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.

Disclaimer

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 Wum.bo 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.

TL;DR;​

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 Wum.bo, which is a platform built on Strata Protocol that brings Strata Social Tokens directly to social networks. Wum.bo 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 Wum.bo, 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 Wum.bo 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 Wum.bo, 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!

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:

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.

note

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 buildsolana 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.

caution

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: https://realms.today/realms?cluster=devnet

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

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

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

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:

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

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/contract.so -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

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

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

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:

caution

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

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>

Secrets​

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 anchor.projectserum.com

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

First, head over to https://anchor.projectserum.com/ 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:

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 https://github.com/StrataFoundation/strata

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!

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.

Stuck?​

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!

Tags: