Buckle up. The puns will get worse until morale improves. But, other than being an amazing vehicle for terrible puns, what exactly is a DAO? Wikipedia will tell you:
A decentralized autonomous organization (DAO), is an organization represented by rules encoded as a computer program that is transparent, controlled by the organization members and not influenced by a central government, in other words they are member-owned communities without centralized leadership. A DAO’s financial transaction record and program rules are maintained on a blockchain. The precise legal status of this type of business organization is unclear.
DAOs were made possible because decentralized computing such as Ethereum now exists. They’re a great tool for enabling financial and logical controls in decentralized projects, so over the last 4 years, lots and lots of DAOs have been created. Of course, over the last 4 years, many, many DAOs have collapsed, been hacked, or exploded in spectacular ways. So are we too early? Are DAOs just a bad idea? Or are we using them in ways they’re not well-suited for?
To create effective DAOs, we have to learn from those failures, hacks, and explosions, and design our code and behavioural systems in ways that either prevent explosions, or mitigate the effects of them.
Let’s look at prevention first. All we have to do is write code that has zero flaws, and can handle every future case that the world can throw at it. If you know code, you’ll realise that the word “all” is doing an impressive amount of heavy lifting in that sentence. Attempting to write flawless code that’s entirely future-proof is easy. Easy in the way that doing brain surgery on yourself is easy. Sure, you can try it. But the results aren’t going to work out well for you.
But, let’s assume that we can make a flawless perfectly spherical DAO in a vacuum. It can manage an entire project from start to finish, and grow smoothly. Is building that even a good idea? Most likely, what we’ve built is slower than a traditional organization to adapt to changes. It also took us longer to build, and we spent more resources doing it. So even if we could build the perfect DAO, it’s pushing us into sub-optimal working practices. Preventing DAO explosions entirely isn’t going to be viable.
So we’re left with mitigation. This is immediately more promising, because we can point to a corollary type of organization that also experiences a high rate of explosive failure: traditional startups. Looking at the numbers, startups fail at a significantly higher rate than DAOs (though it’s early days yet, and the DAOs may catch up). And yet, the startup lifecycle is not only accepted, but celebrated. Failure is expected, and the failure states are well-known and easy to manage. Can we replicate this in the DAO world? Maybe – it’s certainly worth trying.
The big difference between startups and DAOs is that startups compartmentalize risk extremely well, while most current DAOs are “all the eggs in one basket” organizations. For startups, very few people are “all in” – usually just the founders and a few of the early employees. The investors are highly diversified, and the risk to later employees and other stakeholders is lower – there are always more tech jobs.
DAOs are basically a giant bucket of risk, held together by a single piece of slightly dodgy code. One piece of software runs the whole show. In addition, the participants are more heavily invested, both economically and emotionally (and mostly, they got involved with little or no due diligence). Clearly, we need to de-risk DAOs if we want them to be effective and successful.
We can reduce risk in exactly the same way that the startup industry reduces risk – by modeling ourselves on a venture capital firm, rather than on a single startup. VCs are the real winners of the startup economy. They know they’re in a risk-based game, and they do a ton of work to de-risk their portfolios. The biggest thing they do, of course, is right in the title: They have a portfolio of investments, so they have smaller eggs, and more baskets. Their investments are also long-term (5 to 10 years or more; practically forever in crypto terms), and chosen very carefully – VCs say yes to way less than 5% of opportunities.
Looking at a decentralized project, this model fits remarkably well. We can set up a non-profit or foundation managing the overall health of a project – mirroring the VC in the startup world, and then lots of DAOs, each set up for a single, focused purpose – mirroring the individual startups. This balances decentralization with flexibility, speed, and resilience. If one DAO fails or is compromised, none of the others are affected, and the majority of project funds are unaffected.
It’s probable that a smart team could eventually design a DAO to take the role of the central organization. That organization is making simple yes/no decisions; it can require a high bar of votes to say “yes” to things, and it can minimize risk by limiting the funds that can be spent on a single project, or over time, and by setting up clear rules for milestones and vesting. Even with a foundation in charge, the foundation would likely codify similar rules, and could increase transparency and decentralization by doing that. I’m hopeful that someone will design and test something like this in the near future, because if it works, I’d look at adopting it for the Genesis Foundation portion of Genesis Worlds.
At Genesis Worlds, we’re taking the slow route towards a DAO-based organization. Step 1 was fully centralized; that was our startup phase while we were figuring out what to do. Step 2 was “community involvement” – lots of conversations with the community, and sharing information. Step 3 is now – community voting. We can get a stronger sense of what the community wants using a mix of discussions and off-chain voting tools like Snapshot.org.
The next step beyond this is setting up the Genesis Foundation, an organization explicitly tasked with maintaining and growing the Genesis ecosystem and community. Instead of using smart contracts to enforce behaviour, we can use the legal system instead – if the foundation breaks explicit promises to the community, legal action can force it to comply. Beyond that, we’re planning to implement the sub-DAO system, providing direct management of development funds for individual worlds or other in-game communities. It’s entirely possible that in the future, DAO technology will advance to the point that we’ll be able to complete DAO-ification of the whole Genesis Worlds project. I’m hopeful that can happen; we’ll see what the future holds for it.
Friends and community,
We are excited to share the details of the Genesis Worlds Mining Claims NFT launch happening on Tuesday, January 18th! We know you want to be prepared when the first three Worlds go on sale. Keep this message at your fingertips in case you need to reference it during the sale. (And feel free to share with friends)
Genesis Worlds Mining Claims are the founding NFTs that allow you to participate in individual World governance, while Mining the tokens that power the Metaverse economy.
Here are the details you will need to successfully participate in the Mining Claims sale. All times are listed in PST. You can use a time zone converter tool to find out when sales occur in your region, or you can look at the page for the mining claim. The individual mining claims pages also list the launch time in your local time zone along with a countdown timer to the launch.
Date:
Tuesday January 18, 2022
Time(s):
8:00 AM PST – Nexus
9:00 AM PST – Treasure Planet
10:00 AM PST – Neo Tokyo
Here are the preparation steps we believe will best lead you to success:
On the page for the Mining Claim you want to purchase, click BUY CLAIM and follow the prompts to complete your purchase.
World Mining Claims are liquid NFTs. They can be bought and sold from the Mining Claim contract at any time, for the current market buy or sell price. This is a massive improvement over traditional NFTs, which can be hard or impossible to sell. The buy and sell prices are calculated automatically using a bonding curve, based only on the number of Claims that exist. As you can see below, the curve is very gentle, to allow a good number of Claims to be purchased. For example, when:
500 Claims exist, the next Claim will be priced at 508 $GAME
1000 Claims exist, the next Claim will be priced at 873 $GAME
1500 Claims exist, the next Claim will be priced at 1391 $GAME
2000 Claims exist, the next Claim will be priced at 2139 $GAME
2500 Claims exist, the next Claim will be priced at 3195 $GAME
3000 Claims exist, the next Claim will be priced at 4633 $GAME
Note that when Claims are sold back, they are burned, thereby reducing the number of Claims in existence and potentially lowering the sale price for new Claims.
The first launch will provide us with info to help us continually improve the experience as we launch future Mining Claims. Our team members have all participated in launches where we were unsuccessful purchasing NFTs we were hyped to collect, and we understand that pain. We expect to have a lot of demand the first day, and want to remind everyone that the sale doesn’t end the first day. The price will eventually settle at a market price, and you’ll be able to buy your World Mining Claims at that price.
The team at GAME Credits cares deeply about our community. We are privileged to be able to connect daily with truly wonderful and collaborative people. We are working diligently to ensure a fair launch and we are excited to have you along for this big step in building the 100 year Metaverse!
With Genesis Worlds, we’re building a decentralized Metaverse that’s going to last for 100 years. That’s a massive, ambitious goal, and it’s only possible through the application of blockchain technology. Each of the four concepts within that phrase have their own technical requirements and tradeoffs. As we’ll see, there are no easy answers to the question “what tech should we build on?”, and in fact the answer that’s closest to right today may be wrong tomorrow, as the underlying technologies change.
Decentralized: “Decentralization” can in some circumstances mean “100% trustlessness,” but that’s not our goal here, as it significantly impacts other parts of the Metaverse and game we are building. Instead, our measure is that community members can and do contribute directly to the project, and make changes to the fundamental nature of the project.
Metaverse: There are thousands of different opinions on what a Metaverse is, but for us, it’s a 3D multiplayer environment, created and built on by users, owned by the users, and with strong interoperability across different platforms.
Game: It has real gameplay woven through the Metaverse environment, made up of shared user-created experiences. It’s fundamentally multiplayer, and it’s not a collection of mini-games and disjointed experiences.
100 years: We’ve seen major technological jumps roughly every 10 years – from the personal computing revolution of the 1980s to Web 1.0 of the 1990s to Web 2.0 of the 2000s to smartphones in the 2010s to Web 3.0 in the 2020s. That pace of change is likely to continue. The platforms and technologies used in 30 years from now will be vastly different from what we’re used to today. And this has a big impact on our tech stack and the considerations we make during our development process.
So what does the tech stack look like? Firstly, there’s some pretty standard components needed:
The “Metaverse” and “game” requirements don’t have too much of an impact here – while there will be some differences on the depth of experience, or quality of graphics, we can achieve them with almost any tech stack choices. “Decentralized” and “100 years” are far more impactful, especially where it comes to front-end tech.
The biggest unknown is clearly future hardware. We have absolutely no clue about this, and the impacts could be profound. It’s entirely possible that in 50 years, quantum computing will make current blockchain technologies obsolete. Also, the blockchain tech that exists today is 3-6 years old, and has gone through massive upheavals and changes. What this tells us is that we need to ensure that we plan for flexibility to adjust to newly-evolving tech stacks.
But… we also know that the world will also adapt to changing technology stacks, and we can use that to our advantage. That brings us to possibly the biggest choice, and a controversial choice: Choosing an engine to drive the front end. The first Metaverses (Sandbox, Decentraland, others) all picked home-grown engines. This was a choice that maximized decentralization. But, the tradeoff for that choice is reduced agility, and much reduced flexibility. You’ve taken something that isn’t really a core part of your value proposition – making a 3D game engine, and you’ve taken it on as a core part of your business. Now, when the world changes tech platforms, as it will many times in the future, you have to do all the work to support that new tech platform, or risk going obsolete.
So really, you don’t want to be writing your own game engine, you want to use a commercial engine. This feels like it’s a big step back in terms of decentralization. But is it? I’d argue it isn’t, or at least not in a meaningful way. The only commercial game engine that has flat-out died in the last 20 years is Flash (and for good reason). Every other engine is either going strong, or has transitioned to open source. There is a AAA-level open source game engine out there: Amazon’s Lumberyard. There’s also Unity and Unreal. Unity is mostly a no-go, as its licensing terms don’t play nicely with open source projects. That’s sad – in many ways, it would be the perfect engine; we even did our initial Genesis Worlds prototypes in Unity. So it comes down to the open-source Lumberyard vs the closed-source Unreal. This, as it turns out, is a no-brainer. Unreal wins by a landslide.
Wait – is that really right? Yep. Open source in this case is worth very little, for two main reasons. One: The future will be different, so it’s probable that we’ll be rewriting the client several times in the future. Two: Lumberyard is a cost center for Amazon, not a profit center. If Amazon pivots away from gaming (and it will at some point), Lumberyard effectively becomes an in-house engine. Three: People. Way, way more devs are highly skilled in Unreal than Lumberyard. And people are the most important factor here; even more so for a community-driven project like Genesis Worlds than for a corporate project.
So, our selection for the front-end client becomes the latest version of Unreal Engine, Unreal 5.0.
Usually when you’re specifying a game platform, you think of back end server tech and storage tech at the same time; they interact closely with each other, and are managed by the same people. Building a decentralized game, you’re in a more complex world.
Luckily, it’s a world that helps you in many, many ways. Firstly, your core economic transactions have a clear place: On chain. We’ll have to pick the right chain, but we’ll come back to that. Secondly, you need storage for user-generated assets (and source code etc). Again, there’s existing solutions here. IPFS for UGC is great for the most part; open source repositories handle the source code.
For the actual gameplay logic, it’s unrealistic to attempt to do that on a traditional chain – with millions of transactions per second and required response speeds measured in milliseconds, the only real option is a traditional server. It’s possible to decentralize those servers, at least for small player counts – Decentraland handles 2,000 concurrent players in this way. That’s several orders of magnitude smaller than a traditional game’s user base. And there’s a lot of traditional functionality you have to compromise on. So, the majority of modern blockchain-powered games instead rely on more traditional game servers. For now, we’ll stick with that trend, and run on traditional servers. But… the future will likely look different here, and we can set ourselves up to take advantage of it.
Up until now, we’ve assumed that our decentralized Metaverse is going to run on a tech stack that’s similar to traditional games. But… that doesn’t have to be the case. What if we could make decentralization work for us in terms of efficiency and resilience, rather than against us?
Here at GameCredits, we are building a large-scale multiplayer game where players will be connected for significant amounts of time. That gives us access to a massive amount of connected, readily-available storage and compute power: Every device that’s live and running the game. The technology to turn that mass of computing and storage into a live gaming network doesn’t yet exist, but it’s within our grasp to create it. Once you’ve got that built and running, you no longer need servers, and you no longer need storage for in-game assets. You still need storage for downloadable content, but that’s already solved in a decentralized manner. You do still need some centralized touchpoints – all the app stores require a true business entity, and someone still has to provide analytics & telemetry analysis to a scale that couldn’t be stored in a decentralized manner. Those two points, however, could be replicated by other teams, so the project at this point would become forkable.
In summary, I don’t know what the future holds. But I do know that it will be different than the present. And just knowing that is a massive help in making tech stack decisions for Web 3 and the Metaverse.