This article is meant to act as a comprehensive guide to the who, what, why, and how of GenesysGo.
(Edit, 12/24: We have received overwhelming interest in people wishing to help test the Shadow Protocol as Alpha-Shadow Operators. We have closed the testing pool as of 12/22/21. Thank you all so much for the help! Keep an eye on our Twitter and Discord for when we announce the next round of testing)
You will hopefully leave having a better understanding of key concepts such as: what we’ve built, what we are building, the Tokenomics of the $SHDW token, and the mechanics of our upcoming IDO.
My name is Frank and I am one of the co-founders of GenesysGo. This article will, hopefully, shed light on how GenesysGo went from being two best friends building servers to a team of seven developers, multiple community managers, and a community of nearly 13,000 in less than a year.
What is GenesysGo?
Since April 4th, 2021 GenesysGo has been building and providing infrastructure to the Solana community. Our validator, the Shadowy Super Coder DAO validator, (https://solanabeach.io/validator/AKoVXpZmi8wSz3sGvCYEygbpdHvSRysWsh36b97iPvKh) came online in early April and we very quickly transitioned to building and networking RPC servers.
To put it simply, GenesysGo is the infrastructure provider of RPC and Validator services on the Solana network.
For those who don’t know, RPC servers are the backbone of the Solana blockchain. They are the traffic controllers of the Solana validator network and literally every single project building on Solana uses them.
Solana is especially hard on RPC servers because of the sheer throughput that Solana is capable of. RPC servers are arguably the hardest working piece of hardware on the Solana chain.
Over the past eight months GenesysGo has been quietly gathering more and more user traffic and at this point we, conservatively, power over half of all traffic on Solana.
What projects do you power on Solana?
We built a RPC network that provides unlimited requests per second (any RPC provider that has a payment model based only around requests per second is showing a fundamental misunderstanding of how server resources work), unlimited data, global DNS load balancing for the lowest latency, and is backed by a network of 300+ bare metal servers in 9 different countries across 3 different continents. We also provide access to the full ledger history all the way back to Solana’s genesis block.
Why is this important?
Because it’s very important to us to establish that we’re not a new project. We have a well established product and well established brand. We made a choice in the beginning (for better or worse) to focus on building rather than talking about building and there are far too many projects who keep promising “big announcements” already in the ecosystem.
Steven and I both have backgrounds in b2b sales and we put that to use by getting out into the Solana community and grinding until “overtime” just became “normal time”. We developed a very deep userbase by (as the Solana team loves to say) chewing tons and tons of glass.
So, as you continue reading and learning, that’s good context to keep in mind!
Who makes up the team?
Steven and I are the founders and we ran the project for eight months before bringing anyone on board.
Steven has a background in distributed data systems and geographic information systems, as well as extensive experience building inside Linux terminals. I have a background in education, business leadership, and I am self-taught quant trader. Both of our careers took detours early on into the world of traditional finance where we both spent many years working as financial planners and leading business units at large investment firms… which really just translates to some financial planning and a lot of sales conversations.
When Steven and I first met we bonded over being the only real hardcore computer nerds in a building full of finance people. While we enjoy software, our true passion has always been the hardware and networking side.
We hold multiple town halls per month on Zoom and are about as doxxed as you can get short of inviting people over to check out our houses.
So what are you building? Why the IDO? Also, what’s this NFT you mentioned?
All three of these things are linked. Let’s start with the NFT mint…
The Shadowy Super Coder NFT Mint
https://genesysgo.medium.com/genesysgo-shadowy-super-coder-nft-collection-80ba8811d4f2 — Rather than retype everything, I’ll drop the link here for those who haven’t heard of our NFT, its utility, and want to learn more.
TL:DR; We minted 10,000 SSC NFTs at a price of 2.5 SOL on the very day that Solana made its all time high and all 10,000 were minted in less than 9 hours. We were told it couldn’t be done but this is how much the ecosystem values what we do.
What made the NFT drop even more impressive was the wallet distribution. https://gist.github.com/levicook/6d7dcf374ece6cb2d585cd32b07a3e0b#file-ssc-holders-csv — This snapshot is as of 12/17. Given that our NFT is tied very closely to our seed token allocation, this means very good things for the project’s Tokenomics as a whole (obviously, no one can guarantee what the price will do and, candidly, we are much more focused on building strong utility for the token).
The top 20 wallets hold only 28% of all the NFTs… this was very exciting and very important to us as it spreads out the risk curve for the token overall.
In fact, the top 120 wallets barely reach 50% ownership of all Shadowy Super Coder NFTs.
How does the Shadowy Super Coder DAO fit in with GenesysGo?
The SSC DAO has always been meant to be the ultimate custodian of the network layer that GenesysGo is building. The SSC NFT mint allowed us the chance to accelerate our ability to execute while simultaneously bringing together the community that will ultimately make up the DAO. It is important to note that the DAO is not a fully functional DAO at this time. The network layer we have built is very integral to Solana and changes to it must be made very deliberately and with careful testing. The DAO serving as the foundational community allows members the ability to understand more about a layer of the Solana architecture that is fairly complex and not well understood. This gives the GenesysGo team the ability to make critical, in the moment, decisions regarding architecture and the needs of Solana while also allowing DAO members the ability to observe and learn.
As we achieve the full rollout of the various aspects of our project (more details below) the DAO will begin taking more of a central role in the decision making processes, with a central council being the fiduciaries over the caretaking of the network.
So, what are you building?
Before we talk about the Shadow Protocol, let’s talk about one more thing related to our existing RPC network.
As you may have read if you read the articles about our NFT mint, our promise to the ecosystem was that if all Shadowy Super Coder NFTs were minted in the first 24 hours then we would provide the Solana ecosystem with full RPC network access at no cost until the end of 2021.
Our NFT was fully minted in less than 9 hours and so, since Nov 3rd 2021, our RPC network has been available at no cost.
We believe the “RPC provider” model is very outdated and it is our goal to break this model. Between what was generated from our NFT mint, continued NFT royalties, and the fees from the Shadowy Super Coder DAO validator node we are able to provide RPC access at no cost into perpetuity.
Because of our focus on searching out creative revenue sources other providers don’t utilize, we are able to provide a massive scalable RPC network without using funds from the upcoming IDO, which allows us to focus those funds solely on building the first truly Solana optimized decentralized RPC network and the first truly Solana optimized decentralized storage layer.
That’s great… but what are you actually building towards?
First, a recording of our third Town Hall is viewable here: https://youtu.be/sFAQ9hPqaBg — In this Town Hall we go over, in depth, what the Shadow Protocol is, what we are building, and how it plugs into the Solana ecosystem.
Second, to make sure everyone is on the same page as far as the nomenclature goes…
Shadow Protocol = Broad sweeping term which includes all things related to the $SHDW token, decentralized RPC, decentralized storage, and the community that contributes compute to earn rewards.
Shadow Network = Decentralized RPC Network
Shadow Drive = Decentralized Storage Solution
Shadow Nodes = The actual servers that make up the Shadow Network/Shadow Drive
Shadow Operator = The person who contributes compute power in exchange for token rewards paid out in $SHDW
Tech Talk AMA hosted by Steven is here — https://youtu.be/gbeOzLq8N0Y
In this Tech Talk, Steven peeks under the hood of our RPC network and how it operates… in addition to highlighting the process for Shadow Operators to connect to our network and begin earning rewards.
The Shadow Network — why is this a big deal?
There are many RPC providers out there at this point, sure. However, all but two (we will touch on the two decentralized providers shortly) are fully centralized and have significant overhead. The RPC server space is also becoming increasingly crowded and, as such, it will continue to be (as someone once phrased it) a “race to zero” as RPC providers are forced to provide more bells and whistles for less.
The two decentralized RPC from other chains (POKT and ANKR) both struggle to generate the throughput needed to power Solana. To date, both have failed to launch a working server on Solana.
POKT and ANKR both suffer from the same thing that makes RPC servers powered by AWS, Hertzner, and Google Cloud highly unreliable on Solana… they are incapable of handling Solana’s throughput requirements without failing. Solana is incredibly performant and, as such, it will always be hard for RPC providers, who built their foundational architecture on other chains, to port over to Solana and thrive. In order for that port to happen successfully, it would require a fundamental redesign of their key architecture which would be expensive and time consuming.
As such, our Shadow Network will be the first fully functioning decentralized RPC server network that is designed specifically to handle Solana’s throughput needs.
What is the benefit of this and why would you eat such a huge cost like that?
Well, it very much fits into our ethos of empowering the community to help strengthen and expand the infrastructure of Solana! Anyone supporting GenesysGo, the SSC-DAO, and our IDO is directly contributing to the expansion and future success of Solana.
Secondly, a decentralized RPC structure allows us to include a very important KPI to use as a measure for the sustainability of both $SHDW and the Shadow Protocol… that KPI is the number of Shadow Operators contributing compute to the network. To date, we already have 20 individual operators who are planning to connect machines and add their compute to the network.
Why is this the main KPI for us? Well, there are many levers one can pull in order to create a sustainable project… and one of those levers is in regards to expenses. Every Shadow Operator who comes on board to the Shadow Protocol earns rewards in $SHDW tokens… and, every Shadow Operator who contributes compute allows us to reexamine and potentially reduce the amount of compute that our network contributes. This, in turn, reduces our expenses while spreading said expenses across the Shadow Operator layer. This “spreading of the expenses” reduces their overall impact and makes them much more manageable. Our goal then becomes to ensure that the emissions of $SHDW are incentive enough to make becoming a Shadow Operator appealing.
In addition, Shadow Operators serve a key role in reducing the circulating supply of $SHDW tokens which acts as a drag on the overall token velocity of $SHDW. This is due to the fact that Shadow Operators are required to stake a certain number of $SHDW tokens in order to earn rewards (more on this below). This creates a deflationary effect on the total supply which means the onboarding of Shadow Operators is a key mechanism for judging the direction and health of the project as a whole.
Ultimately, over the long term we expect our server expenses to drop below 95% of their current levels as we integrate more Shadow Operators and the need for a centralized server backbone is reduced. Through the use of smart contracts, open-sourced resources, and server redundancies on the Shadow Operator level, we are building a fully self sustaining architecture that can scale automatically as Solana scales while not being reliant on a core team in order to survive.
The Shadow Drive — A Decentralized Solana Optimized Storage Solution
This is best summed up using slides from our 3rd Town Hall and so I will post the slides and then add context below.
So what’s the TL;DR? Solana needs an optimized storage solution that protects the integrity of the consensus when storing the data. We have a unique perspective when viewing the ecosystem because we communicate directly with developers about their needs on a daily basis.
The need for full access to a copy of the Solana historical ledger and broad “Account State” that is truly immutable has increased dramatically over the past several months. This is a mission critical need for the Solana blockchain if it is to continue growing and scaling.
This is also a relatively easy lift in terms of the workload because of our in-depth knowledge of how information is shared between different validators and validators to RPC servers. As such, we expect the timeline around storing a truly immutable copy of the total state of all accounts in the Solana AccountsDB to be measured in weeks rather than months.
Our most recent talent acquisitions have all been focused on bringing onboard engineers with strong backgrounds in building distributed database systems in both the web2 and web3 spaces, as well as hands on experience building in Rust (the native programming language of Solana).
As such, our ability to warp a general decentralized storage solution for the Solana ecosystem would also be measured in a matter of weeks rather than months.
At the moment, Arweave is the primary storage solution used by a great many builders on Solana however this is largely a function of there not being any other alternative. We receive messages from developers on a consistent basis asking why they are receiving RPC errors when doing Arweave uploads and we explain that this is due to the fact that Arweave’s chain is not fast enough to keep up with Solana’s. When this happens, transactions start to fail but the failure is coming from Arweave’s side.
There is an appetite in the Solana ecosystem for an optimized storage solution and, due to the sheer amount of data that the Solana ecosystem creates, we see this as a huge market opportunity.
Plus, this is right in our wheelhouse… we started GenesysGo and our RPC network with the mindset that existing RPC services enforced rate limits because their architecture was not optimized for Solana. We then examined the landscape, took the best qualities of all providers, and then bootstrapped what has turned into an incredibly successful venture. Stepping into the landscape, building an optimized solution, and then growing user adoption is what we do best.
Okay, we get it… but can we PLEASE talk Tokenomics???
That’s fair! I appreciate you letting me lay all of that information out for you. Context setting is important simply because of the broad nature of where we are, where we’ve been, and where we’re going.
It also drives home what I’m about to say, which is… The $SHDW token is meant to be a 100% utility token. However, in order for it to be a true utility token, it is important we take the time to understand the full context of the protocol it is providing utility for.
Without this context then $SHDW goes from being a “utility token” to just another “coin” that is tied to faceless Discord server that posts every week or so that “big things are happening” and “big announcements are coming soon!”
The use case and utility for the token should be clearly spelled out rather than us simply waving our hands, saying that “We’re an infra provider and we’re powered by a token” and letting people draw their own conclusions of what that means. The token use case and the project it is powering should be clearly and plainly laid out rather than loose associations drawn.
NFT Holders — This allocation is a hard and fast allocation. These tokens are paid out to NFT holders on a daily vesting schedule over the course of one year. We have built a NFT staking contract which ensures the trustless payment of emissions. Emissions are not paid unless the holder of the SSC NFT has staked the contract. Meaning, the full daily emission rate of the “NFT Holders” allocation cannot be reached unless all 10,000 Shadowy Super Coder NFTs are staked. $SHDW tokens placed into the NFT Staking Smart Contract are associated to the token address of each individual NFT and only 10,000 $SHDW tokens are paid to the wallet associated with that NFTs token address.
Bonus Emissions for Long Term Holders — NFT holders who stake their Shadowy Super Coder NFT for 12 consecutive months, will receive an additional payment of bonus tokens. It is our intention to reward long term holders of the SSC NFT as they are, much like the developer community who supported our success pre-NFT mint, a key reason why our community has grown as large and as strong as it has. PLEASE NOTE the word CONSECUTIVE… if the SSC NFT is removed from the staking contract then the “timer” resets. This bonus is only paid out once and, again, requires the continuous staking of the NFT for consecutive months in a row.
Shadow Operator Emissions — Shadow Operators earn a % of the fees paid by clients who use the Shadow Drive. However, it is important to us that there be a backstop in order to ensure that Shadow Operators have consistent incentive to continue providing compute. Therefore, if the % of fees paid by clients fails to be higher than a minimum threshold (calculated using the machine costs of the Solana Server Program as a guide) the Shadow Operator Emissions pool will act as that backstop. These tokens are paid out to Shadow Operators who contribute compute to power the network. The emissions rate is variable based on overall network size and the amount of client fees paid into the emissions contract. Currently, the maximum emissions rate is targeted to be 10% of the unpaid emissions supply per year (i.e. Year 1 = 10% of 20m, Year 2 = 10% of 18m, etc), spread across all Shadow Operators and distributed on a weekly time frame. The distribution of the emissions is based on the performance of the operator’s machine. In order to be eligible for Shadow Operator Emissions, operators are required to post collateral in the form of staked $SHDW tokens (see the Collateral Section below).
IDO Pool — The amount of tokens being put up for public sale on Jan 3rd, 2022. These tokens are being offered at a minimum price of $.50 per token but, as we are using a slightly modified version of the Mango/Aurory IDO program (the slight modification being the $.50 per token floor price), the price may go higher if there is significant interest in the IDO. Unsold tokens will snapback to GenesysGo and be used as a Treasury because, successful IDO or unsuccessful IDO… we’ve got a lot of things to build! We have structured the IDO price to enable us to pursue something as big and as challenging as building an optimized Solana native version of Arweave or Filecoin (Arweave, for example, raised $22m between two IDOs and now has a market-cap of $2.2b as of the time of this writing) and the IDO is structured to reflect those plans.
Strategic Reserve — The Strategic Reserve is designed to act as a buffer for those unexpected situations in which the team needs tokens on hand. This includes things like, CEX listings, funding liquidity pools, acquiring new strategic talent or partnerships (placed into multi-year vesting contracts), etc. At the moment, no such things are planned (no CEXs have a secret lump of tokens which will cause an unexpected liquidity spike) but we don’t know what we don’t know and it is important we are able to have the agility needed in order to take advantage of situations that could be potential boons for the project. This allocation is not for open market sale or to provide ad hoc liquidity. This is critical to understand. We are very aware of the funds we need in order to successfully implement our vision at a large scale. This is what the IDO pool is for. The Strategic Reserve allocation is meant to be just that… strategic… strategic does not mean open market sales.
Thoughts on the design of the tokenomics…
The tokenomics were designed with token velocity in mind. We have gone to great lengths to ensure that tokens are introduced into the markets gradually.
NFT Holder Daily emissions — Some key things NFT holders need to keep in mind when it comes to daily emissions…
- NFT holders must stake their SSC in the staking contract to begin emissions
- $SHDW token vesting happens on a daily basis and can be claimed daily
- Vested $SHDW tokens are held in the NFT Staking Smart Contract until claimed. You do not need to claim emissions daily , your $SHDW will always be there waiting for you.
- Un-staking your NFT automatically claims your tokens and sends them to the wallet you staked your NFT from.
This provides line of sight on the daily emissions of new tokens into the marketplace by tracking the number of NFTs held in the staking contract. We do not anticipate all NFTs will be staked from day one and held in the staking contract for the full year. We anticipate, in very short order, that NFT marketplaces will begin to reflect the price of $SHDW combined with how many $SHDW tokens are left for that particular SSC NFT to have paid out to it. As such, there will be those who wish to take liquidity instantly rather than waiting for the full year for the smart contract to emit their tokens. Those SSC holders will be able to list their NFT on the various marketplaces to achieve liquidity. This will have the benefit of further delaying the tokens attached to that NFT from entering into the marketplace.
Where is the Founder/Team portion?
For starters, the team and I are all SSC NFT holders (purchased with our own capital on mint day, just like anyone else) and as such we have $SHDW tokens of our own to vest as well! It’s also easy to forget, in this world of tokens and token vesting, that salaries are still a thing. That said, our tokenomics are designed for the slow and transparent introduction of tokens into the ecosystem. Unless something changes, we are targeting 50% of the $SHDW of the storage fees paid to go to Shadow Operators. The other 50% goes to the GenesysGo Shadow Protocol to pay the operational costs of running the project. One of those operational costs is the cost of paying team members.
Our focus is, and always has been, building an incredibly cool and wildly sustainable platform which powers innovation on blockchain. When our user count is measured in the millions and our market cap is measured in the billions, I am sure we will be well taken care of. That’s more than enough for us, we would prefer to earn that rather than be counting down the seconds until a founder allocation unlocks.
The Token’s Utility
We have built a token use case that is very similar to Arweave or Filecoin. Clients wishing to use the Shadow Drive for storage will be able to using $SHDW tokens. Shadow Drive users can choose between storing their data forever and paying a one time fee or storing their data and paying monthly storage costs in a similar fashion to cloud storage.
While the use case to our token may be similar to AR and FIL, the execution of that use case will be markedly different. We believe that both Arweave and IPFS have incorporated several unnecessary pieces into their network architecture and tokenomics models that will ultimately hamper their ability to properly scale and gain mass adoption (more on that below).
Users of the Shadow Drive will be looking at storage costs more closely aligned with the $.009 to $.02 per GB ($10 to $23 per TB) charged by cloud storage providers. These costs would be paid in $SHDW tokens and with 50% or more being paid to the Shadow Operators who power the network.
Compare this to Filecoin which starts at $.03 per GB ($30 per TB) but can go higher depending on the type of data be stored or Arweave which asks users to pay 200 years worth of storage costs as a one time up front cost that runs (as of the time of this writing) $8,214.22 per TB.
Our focus is combining the best elements of Filecoin, Arweave, and traditional Cloud Storage into one cohesive storage layer powered at the speed of Solana.
While the initial versions of the Shadow Drive will be focused on direct interaction with users who are looking to store data, we believe an API layer that encourages others to build on top of the Shadow Protocol is vital.
Our goal is to build support for developers to build on top of the Shadow Network and Shadow Drive systems. In doing so, we create a system where Solana’s Proof of History consensus mechanism acts as the CPU, the Shadow Network (RPC Servers) begins to act as a RAM drive, and the Shadow Drive (storage layer) begins to act as the hard drive. Effectively, tying Solana and the Shadow Protocol into one large computer with a dual token structure with SOL/SHDW as the token pair that powers the transactions.
Shadow Operators, backbone of the Shadow Protocol
Shadow Operators are the backbone that powers everything about the Shadow Protocol. Shadow Operators provide the compute power to run the Shadow Network and Shadow Drive, they receive a percentage of the fees that users pay for accessing the Shadow Protocol, and they also act as a key part of slowing token velocity and removing tokens from the ecosystem.
The thought to have Shadow Operators stake $SHDW in the form of collateral is a concept we borrowed from Filecoin. When a Filecoin Operator commits to storing data, they must put up a certain amount of FIL as collateral in case the data they are storing is damaged or lost in some way. Given the importance of maintaining trust with our users, we decided to implement this mechanic in a similar fashion.
A similar mechanic is already in place on Solana within the Solana validator nodes. Each Solana validator operator is required to pay .8 to 1.1 $SOL per day in “vote fees” (gas fees), this $SOL is then burned. This means that, hardware costs aside, the cost of running a Solana validator is approximately $150 to $200 per day, depending on the price of Solana at that time. This has become a significant pain point for Solana as it tries to continue scaling higher. We wanted to avoid this pain point in the event the $SHDW token were to reach similar price levels.
To that end we settled on a staking mechanic rather than a gas fee mechanic. Shadow Operators who wish to earn $SHDW rewards must stake $SHDW tokens. Once these tokens are staked, they are locked in for a minimum of 30 days. During that time, Shadow Operators who are not maintaining their machines or experience downtime beyond what would be considered normal can have penalties applied to their collateral. A Shadow Operator who no longer wishes to provide compute power to the network may stop earning rewards and will have their collateral returned to them (minus any slashing penalties).
This collateral mechanic serves as a key velocity trap for the $SHDW token while also ensuring that the Shadow Operator has a vested interest in ensuring the success of the users of the Shadow Network.
Due to our foundational role in the establishment of the Solana Server Program, we have decided to benchmark collateral and Shadow Operator Emissions to the cost of a Solana Server Program server. We highly encourage anyone interested in being a Shadow Operator to check out the Solana Server Program https://solana.foundation/server-program
We’re all still so early…
Whew… okay… that was a long journey… if you’re still with me, then let me just say thank you so much for taking the time to read through everything here! This document was definitely a labor of love and it’s one I feel like I have written ten different times as I have answered questions across various different channels. However, this is the first time I’ve sat down with the goal of writing an all inclusive document.
I will update this document as needed but please feel free to DM me directly if you notice anything incorrect or want to learn more!
Discord: Frank | GenesysGo#5122
Telegram: FrankGenGo
Discord Server: https://discord.gg/genesysgo
The hope is that this article gave you a better understanding of who we are, the things we’ve built, and the level of consideration we’ve put into every aspect of our network. Steven and I have built our entire careers on the notion that if you add real value to your community then success is the by-product. What we’re building is, by design, built with the thought in mind that if Solana is successful then its developer community is successful. If both Solana and the developer community are successful then we are successful. I know I speak on behalf of myself, Steven, Levi, and the rest of our team when I say, we just want to be part of an amazing community and to build cool stuff.
The days since April 4th, 2021 have been a crazy blur. They’ve been exciting and terrifying and so much more… the one thing they haven’t been is boring! This is the most fun I have had working on anything in my entire life and I wouldn’t trade it for anything.
The Solana community continues to humble us daily and we could not be more grateful to the developers we have come to call friends. It continues to be an absolute honor to lead the Shadowy Super Coder DAO and the GenesysGo team. What began as two best friends deciding to turn on a validator node has grown into something so much bigger and better than we could have even dreamed.
It’s easy as builders to spend every day laying brick after brick and staring at the blueprints you’ve drawn… writing articles like these gives me the chance to step away from the blueprint and look up at the structure of the thing we’ve been building… and this thing wouldn’t be possible without the thousands of people who have supported us along the way… so, from the bottom of my heart, thank you.
