1. a majoritarian voting system, which creates
2. an economic penalty on minority opinion, which creates
3. a self-reinforcing incentive to side with the majority

Keynes intended his contest as an analogy for the stock market, but it equally describes Nakamoto Consensus, where consensus around the longest-chain also emerges through a voting mechanism that punishes anyone who disagrees with majority opinion.

Despite the obvious parallels, few academics working on “cryptoeconomics” have read Keynes, or other economists like Mancur Olson who focus explicitly on incentivizing collective action. Instead, computer scientists focus overwhelmingly on building distributed voting mechanisms.

This intellectual bias has led computer science to approach consensus as a problem that requires voting. The blindness to other approaches starts with the way academics conceptualize the problems – consider the way the Byzantine Generals Problem is invariably described with the assumption that participants must honestly or dishonestly signal their preferred courses of action. They vote and only then do they act.

This drift away from incentives towards voting mechanisms is a major intellectual hurdle in distributed systems development, because as soon as we create voting mechanisms we automatically create majoritarian attacks on them. But isn’t our goal is to avoid incentivizing collusion? Deciding how to distribute money based on majority opinion is not a workable approach.

And this is why understanding the Keynesian Beauty Contest matters. Because knowing that Satoshi designed Bitcoin as a beauty contest mechanism allows us to ask a simple question: why bother with the first step at all? Why add a voting mechanism? Why not look for a way to impose a cost-of-attack guarantee on malicious nodes that punishes attackers regardless of whether they control majority opinion?

Few people in distributed systems conceptualize the challenge this way, not trivially because many consider it an impossible problem, but there are already formally-proven methods of accomplishing exactly this. In our case, Saito Consensus does it by using “routing work” to increase the cost of producing blocks that orphan honest blocks, while also decreasing the amount of revenue attackers can earn from producing those blocks. Because of the way the payout mechanism works, attacking a routing work mechanism always costs money. Incentives impose a cost-of-attack directly of indirectly via a gameable voting mechanism.

By delivering what actually matters (the penalty and its results) without the need for a voting mechanism, routing work gives us all the benefits of the incentive structure in the Keynesian beauty contest (a self-reinforcing emergent consensus and natural incentive to cooperate) without adding the crippling majoritarian attacks. It gives us the properties that matter for distributed consensus without the technical vulnerabilities that come from adding majoritarian voting.

It will be interesting to see how long it takes computer science as a discipline to throw off its intellectual shackles. Until that happens governance will continue to add attack vectors into distributed systems. And the solution to those problems will doubtless be yet more governance. This circularity is a problem with using voting mechanisms, but not a fundamental feature of consensus design. We can do better. And in order to solve the fundamental problems we have to.

The post Nakamoto Consensus is a Keynesian Beauty Contest appeared first on Saito.

From a technical perspective, this shift marks the official point our hardcoded “genesis” issuance files become obsolete, replaced with a dynamic file that is re-generated from our live UTXO hashmap with each network hard-fork. In the interest of public transparency and to ensure that historical data is available for public scrutiny in the future, we have taken the step as part of our network update of ensuring token issuance files are archived and uploaded to our official Github repository with each reset. The team is continuing to monitor and test the network and integrity of these files as part of our ongoing development efforts, but is pleased to report that so far everything seems to be working perfectly.

In terms of changes that users will notice to the in-browser Saito experience, while our ERC20 token withdrawals continue to be handled manually, we are expecting to update a new application / UI-feature to the Saito Application Suite later this week that will speed up withdrawals by allowing for a greater degree of automation in the token migration process. We are hopeful this will assist us in getting withdrawal times down to about 12 hours from the 24 or so that it currently takes.

On a side-note, we should also mention that we are aware of the publicly-discussed issues with the Anyswap/Multichain ERC20 < – > BEP20 token bridge and recommend/request that users do not attempt to use the bridge until the situation is resolved. In the event of continued problems, we will work to update the aforementioned withdrawal tool to allow BEP20 tokens to be directly burnable and withdrawable to mainnet in a fashion similar to ERC20 tokens, thus avoiding need for the Anyswap bridge completely.

Beyond the changes that token persistence brings to the network and the application suite, there are questions of how it should affect tokenomics questions and what changes – if any – we should be making across the our Dawn of Persistence era. In order to address these questions, and present our own thoughts, the team will be having an update on Saito tokenomics at the end of September that will provide more detailed clarity on how we expect the token persistence curve to look, as well as update to the token distribution schedule to help incentivize on-chain migration as the threshold falls.

On a closing note, we remind readers that the entire crypto space is plagued with scams and to assume by default that anyone who contacts you with claims about migration is a scammer. If you’re not sure what is legitimate, please join the community on our Official Telegram Chat at https://t.me/SaitoIo.

The post Token Persistence Update – September 4, 2023 appeared first on Saito.

Although few people ask us about WASM, this is a rather important milestone for us as a community and software platform. Having browsers use compiled Rust code for the core cryptographic and blockchain operations will not only speed up a lot the underlying activities like transaction signing and hashing that are slower in javascript, but it will also return us to having a single codebase for consensus operations.

The massive benefits of having the network run a single codebase is one of the reasons we have pushed to get WASM done ahead of token persistence. Simplifying the codebase so there is a single software stack to upgrade greatly reduces load on development, making development quicker and preventing accidental forks and other anomalies.  It is also going to be necessary for further work on the consensus-layer, including features like (eventually) adding scripting languages, support for multisig operations, on-chain NFT transfers and more.

Right now we are in the final stages of testing the WASM branch in preparation for deployment later this week. Depending on how testing goes, we’re expecting to get the WASM version up in five to seven days. Particular thanks and credit are due to Sanka for taking leadership on getting this integration done. We could not have done this without him.

Our WASM port currently supports all of the major applications that we’re seeing people use on the network: peer-to-peer video calls, RedSquare, the Arcade and of course most of the games on the network. As part of the shift, we are likely to remove some of the games that are not seeing much usage with a plan to refactor them and bring them back to the one-by-one with more polished graphics and improved gameplay.

We are aware that many members of the community are focused on token persistence and thus are also happy to share the news that we still expect to hit our target of getting that supported for large on-chain deposits by the end of next month. We’re planning to get the exact details out for the community in about a month, with an update on network tokenomics about a fortnight later towards mid-September.

In the last few months we have also made significant changes to the way that the application platform works, tried to improve the usability of RedSquare and the chat applications, and completely re-written how the Archive module allows nodes to store and load transactions received both onchain and off-chain. This work has been done to assist with executing the various projects we have in different stages of completion.

As always, we thank everyone in the Saito Community for their patience and support. If you have questions or just want to talk show, please feel welcome to drop by RedSquare or join our Telegram Group and ask them in person.

The post Saito Development Update – July 2023 appeared first on Saito.

The advance is possible in mechanisms where attackers must expend a costly resource (“work”) to participate in consensus. Under these conditions, a malicious majority can be tolerated if the consensus mechanism can asymmetrically strip attackers of “work” over time and restore honest participants to majority status.

Asymmetrically punishing attackers is accomplished by taxing the only activity attackers perform which honest nodes do not: the orphaning of work from other participants. There is a precedent for this type of tax in Bitcoin, but the penalty fails under majoritarian assault. Securing a consensus mechanism beyond that requires making work-orphaning expensive even in situations where attackers produce all of the blocks on the longest-chain.

Framing the problem this way makes it clear why proof-of-work and proof-of-stake blockchains cannot solve it. In those mechanisms, the cost of orphaning work is identical to the cost of proposing blocks once attackers can propose a majority of blocks. When attackers spend resources to push the chain into stasis, the honest network is forced to spend an equivalent amount to resolve the deadlock. Honest nodes face symmetrical losses which prevents their recovering majority status.

The theoretical solution that improves security involves migrating the “work” used to produce blocks into the transactions that constitute them. Attackers may still produce blocks that route around those proposed by honest nodes, but the newly-orphaned transactions can be shifted costlessly into a new block and deposited at the tip of the attacker’s chain to resolve the deadlock. Preventing this requires a more aggressive form of work-orphaning: attackers must move the work-bearing transactions into their own chain. This form of orphaning-by-inclusion is profitable in proof-of-work and proof-of-stake designs but can be made quantifiably costly in others.

Routing work — the addition of cryptographic routing signatures to transactions — is the first known strategy that accomplishes it, modulating down the value of transactions for producing blocks as well as the expected payout from their inclusion. With a sufficiently high per-hop decay (50% or greater) attackers who orphan-by-inclusion face an expected loss from doing so, even if they produce all of the blocks in the blockchain. A properly designed mechanism not only exposes attackers to this cost, but forces them to pay it in a way that reduces their ability to generate work and participate in consensus.

The post Tolerating Malicious Majorities – Advances in Distributed Consensus appeared first on Saito.

We start with two straightforward claims:

proposition #1
nodes that use public routing work to produce blocks are disincentivized from delaying the production of those blocks, as that strictly reduces expected income.

proposition #2:
all participants are incentivized to share transactions publicly to induce direct competition between peers under proposition #1 and thereby secure the fastest confirmations for the lowest fee.

These claims can be formally proven but should be self-evident to anyone familiar with Saito Consensus. Under them, adding unnecessary routing hops to transactions is a strictly inferior strategy unless attackers compensate for the fall in the final-hop value of their transactions by adding their own fee-bearing transactions.

On The Irrationality of Self-Generated Routing Work

All sybil-attacks necessarily involve transactions where the attacker does not occupy the first-hop in the transaction path. This is trivially true: attackers cannot increase their payout by adding hops to transactions where they already have 100% of the claims on payout.

The irrationality of sybilling second-hop transactions can be proven by examining what happens when an attacker sybils a block with only one transaction, such as the following block produced by NODE B that contains 50 units of final-hop routing work.

With 100 SAITO in total fees and fifty-percent of those burned in the costly lottery, only 50 SAITO are available for the routing payout in this block. As transaction #1 is the only transaction that exists it has a 100% chance of selection in the payment lottery and NODE A has 2/3 and NODE B has 1/3 of the expected routing payout. We can easily calculate their expected income as 33.3 SAITO and 16.6 SAITO respectively.

The sybil attack we are concerned with involves NODE B adding an additional hop (“self-cloning”) to transaction #1 to increase its share of that transaction’s overall routing payout, while simultaneously creating the smallest fee-paying transaction needed to keep its final-hop routing work constant at 50 SAITO as per proposition #1.

This gives us the following attack block:

With 125 SAITO in total fees there are now 62.5 SAITO available for the routing payout. Our golden ticket mechanism will select the first transaction with ( 100 / 125 ) probability and the second with (25 / 125 ) probability. NODE A has ( 100 / 175 ) chance of winning if the first transaction is selected and ( 0 / 25 ) if the second transaction is selected.  NODE B has ( 75 / 175 ) chance of winning if the first transaction is selected and ( 25 / 25 ) if the second transaction is selected.  NODE B must finally deduct the 25 SAITO it has contributed to the block (that it spent to sybil) from its profits. Its expected income is now:

NODE A = 62.5 * (( 100 / 175 ) * 0.8 ) + ( 62.5 * (( 0 / 25 ) * 0.2 )) = 28.57 SAITO
NODE B = 62.5 * (( 75 / 175 ) * 0.8 )) + ( 62.5 * (( 25 / 25 ) * 0.2 )) – 25 = 8.92 SAITO

The attacker has decreased their expected income from 16.6 SAITO to 8.92 SAITO. It is easy to demonstrate that losses accelerate as the attacker adds more routing hops to transaction #1.

An Intuitive Understanding of Sybil-Proofing

Something fascinating happens when an attacker sybils a routing-work blockchain. Whereas all the fees in the block were previously potential income to the attacker, the lottery is now taxing their wallet directly.

For a routing work mechanism to be sybil-proof, it is sufficient to show that the tax on self-generated routing-work is greater than the total income a node 1-hop deeper in the network can expect from an equivalent amount of final-hop routing work. In the Saito Classic mechanism the tax is 50% of all fees put into the block, and first-hop nodes earn at minimum 50% of routing payout. Since any additional fees in the block by definition come from the attacker, it is theoretically impossible to generate positive expected income.

As long as the lottery tax remains provably costly regardless of the amount of routing work that the attacker has in the block, any network that has the same work-decay and payout-decay functions as Saito Classic by definition inherits the same sybil-proof properties.

In practice, our goal is to force cost-of-attack significantly above 100% of fee-throughput, so that in a best-case scenario the attacker is hemorrhaging money rather than merely breaking even. This requires the introduction of a staking payout and the increase in cost-of-attack that can come from the added difficulty of finding combinatorial lottery solutions that simultaneously issue the routing payments from multiple blocks to the attacker .

In the paper referenced above, we show very clearly that cost-of-attack is a minimum of 137 percent in a network with such a structure. This means an attacker must spend ~137% of network fee-throughput to earn 100% of the fees in that block which do not come from their own wallet.

With full control of the staking table, the attacker can eke out profits at approximately 75% control of the staking table.  This can easily be addressed in the paper as mentioned – by the imposition of an income cap that limits payouts to 125% of a smoothed average. Under these situations cost-of-attack rises much higher than 137% to start, and remains above 100% even if attackers gain full control of the staking payout.

The post A Simple Proof of Sybil Proof appeared first on Saito.

You have to provide your own legal ROMs, but once you do an encrypted copy will be saved to your transaction archive so you can skip this step the next time around. We’ve patched the emulator to support social features like text and video chat and hope to hook up screen-sharing and head-to-head 1P gameplay too.

Looking forward, we are getting legal advice on the viability of supporting a lending library similar to the Internet Archive that permits limited archival access to library-owned games. There are legal ways to accomplish this, and by going through the effort of making sure we do it properly, we hope that Saito can demonstrate value as a base-layer for open DRM use-cases. If people want to control the distribution of works they have the right to distribute, we believe Saito should let them be able to do that.

We are expecting clarity in the coming weeks. If you want to help in advance please drop a line, especially if you have experience with electronic engineering and Arduino hacking. Once we know how to move forward, we will likely ask for help sourcing game cartridges.

While we may not be able to resurrect Blockbuster, we believe that supporting secure remote-file access and digital lending is a great use-case for blockchain. It serves a valuable social mission in keeping older software accessible while also permitting anyone with the legal right to share works with a reliable platform through which they can manage access. We look forward to sharing more details as we work them out.

And in the meantime, you could do worse than snagging a copy of Episode I: Racer and setting some new lap records.

The post Nintendo joins the Saito Arcade appeared first on Saito.

Organization:

Our core team has seven developers and two non-technical staff. We have funding for more than two years without further token sales in the event of a prolonged bear market.

We are seeking marketing help, but need someone who understands Saito. Before we find an on-team marketing genius, we’ve shifted to releasing features as they develop rather than planning marketing activities. We think this approach plays to our strengths.

Front-End Development:

Our transaction volume is dominated by gaming applications but chat and social media usage is growing. Our development focus is on improving the Saito Arcade and Red Square.

We are aware of the limitations of these applications and are putting effort into fixing them. We are systematizing components so that common behaviors trigger consistent responses, and working on ways to make it easier for people to participate in group activities like tournaments and leagues. We also have longer-term games and projects under development.

Short-term priorities include browser-to-browser connections for off-chain transaction exchanges, a digital-rights-management module for electronic gaming, and several new applications and games we have previously discussed. A more long-term focus is a platform re-write to simplify the developer SDK.

Rust Client and Token Persistence

Our Rust team has remained focused on our WASM client, a version of Saito able to compile directly into user browsers as well as run on many other devices. This is our long-term platform intended to eventually replace our existing javascript frontend. We are happy to confirm the Rust (WASM) client is active on the Saito network.

We want this client to have at least six months of experience running in a live environment before we use it to maintain token integrity across network resets in a live network with ATR rebroadcasting. In the meantime, our Rust team will work on a variety of improvements intended to increase performance and improve security in low fee-throughput situations. We will publish details on consensus-level proposals over the next four month and continue to welcome feedback and suggestions on mechanism design.

This timeline puts the launch of token persistence in eight months: summer 2023. Token persistence will start by offering guarantees for large on-chain deposits (500k SAITO or more) and gradually lower the reaping threshold as software and network stability permits. We expect it to take approximately a year to reduce the threshold to levels needed for common commercial transactions.

Tokenomics and Staking

The introduction of on-chain token permanence will see an additional ~11mm early bird SAITO tokens enter circulation. We are otherwise reluctant to expand issuance without evidence that doing so will drive growth.

One possible exception — we may introduce a staking subsidy from the network treasury to cover rebroadcasting fees for users who migrate their tokens on-chain in the event that rebroadcasting fees are greater than rebroadcasting income during this period after token persistence is added but before the advertising faucet is generating network revenue. The community should not expect DeFi games with incentivized lock-ups and APY guarantees: we believe those who earn UTXO payouts should be incentivized to promote network usage.

Front-end work on the advertising faucet will commence after token persistence begins, likely around ten months out. We will use the high reaping threshold to experiment with small-value issuance without the risk of such issuance triggering monetary inflation while the faucet matures. As our reaping threshold falls the most popular applications and routing nodes will gradually be able to accrue income.

Exchanges:

We are happy to confirm we have listing offers from significant exchanges. With that said, these mostly involve invitations to give them non-trivial payments for the right to hand over even more significant allocations to dump on their users. There is a reason most exchange-listed tokens drop in price and we do not want to play that game.

We believe that Saito will grow into a premiere crypto-asset and that exchanges will ultimately list Saito on far better terms. Given this, as long as our token price and market cap is rising, we believe it hurts the interests of our community to pursue these opportunities, not to mention reduces the income trading generates daily for Saito holders via liquidity pools.

Saito also has many options to simply purchase that other networks to not. A low-fee crypto brokerage that runs within the Saito ecosystem and plugs directly into Red Square and the Saito Arcade is one idea we are considering, as it will expand trading support not only to our own token but for all partner tokens that can be stored in Saito wallets.

As such, we are punting on further listings activities until we have a full-time marketing hire who can handle these communications and remove the need for Richard and David to be involved in this outreach. We are assuming it will take approximately six months. If the situation changes and a listing becomes more desirable we can easily reverse course.

Third Party Nodes:

We are periodically asked when third parties can run nodes on the network. As per our existing roadmap, we will not push for that in this era as we expect this will slow not hasten network and software development.

With that said, if third parties wish to run transaction-generating infrastructure we will welcome them to participate once token persistence is active, provided they are willing to work with us on scheduled network upgrades.

Summary:

This gives us roughly a year-and-a-half of development work before we will be ready to move into the Third Era. The seminal moment will be the introduction of token persistence roughly halfway through this era.

We welcome feedback on these plans along with broader discussions of our strategic goals and choices moving forward.

The post Dawn of Persistence – Roadmap Update appeared first on Saito.

https://timroughgarden.github.io/fob21/l/l9.pdf

From the Saito perspective there are some problems though. The most significant is that it is incorrect to view public blockchains as sybil-resistance mechanisms wrapped around consensus algorithms. We understand why many researchers like this dichotomy. The distinction is easy to teach and feels productive.

But the dichotomy is incorrect. Once any network offers an outbound payment for performing a work function that function no longer constitutes a sybil-resistance mechanism: you cannot refund payments and still count purchases as expensive. Under these conditions what imposes cost-of-attack is the consensus layer, which decides which nodes receive spendable tokens in exchange for their work.

Computer scientists typically deal with this problem by axiomatically assuming that a majority of miners/stakers are honest. Under these conditions there *must* be a cost-of-attack, and if there is a cost-of-attack surely we should attribute it to the hashing or staking function where the money is spent? This feels like a harmless exercise – no shortage of papers start by making assumptions about node honesty and then derive formal proofs of security from these and other axioms. The problem is that we are doing this to maintain the illusion that the sybil-resistance layer is operating independent of the consensus layer.

Once you break this illusion you are pulled towards a more powerful reality – the realization that consensus mechanisms impose cost-of-attack by asymmetrically taxing attackers. Nakamoto Consensus achieves this by keeping hashing costs constant for all nodes, but decreasing the expected return for attackers, who must build multiple blocks in the same time their honest peers need produce only one.

It is true that in Bitcoin this asymmetrical tax collapses in the face of a Byzantine majority. And while there is no theoretical reason to believe this problem is unsolvable (do all forms of asymmetrical taxation have this weakness?), the coincidence will likely stir critics to ask why we should favor any particular framework over another if both end up predicting failure in the face of majoritarian assault?

And the answer here is that both approaches are not equally vulnerable. If you believe that your sybil-resistance and consensus functions are distinct in the way Tim and others posit, you do end up trapped: it is pointless to strengthen your consensus mechanism against malicious majorities if their existence undermines a fundamental axiom you need to keep your network secure. The framework you adopt essentially defines majoritarian attacks as an unsolvable problem.

But if you focus on the way consensus mechanisms asymmetrically tax attackers you have an open road ahead. Because you are suddenly looking for additional behavioral differences between honest nodes and attackers that can be (1) observed in distributed systems, and (2) leveraged to make proposing changes-of-state more costly for attackers than honest nodes.

This more accurate worldview encourages us to manipulate the same economic levers that Nakamoto Consensus does. It teaches us to improve on Satoshi’s solution not only by decreasing the payouts we offer attackers, but even doing things that no proof-of-stake or proof-of-work network can accomplish: asymmetrically increasing the cost that attackers pay to propose blocks. The routing work mechanism that Saito Consensus introduces simultaneously accomplishes both of these objectives.

At the end of the day, definitional frameworks matter. With an inaccurate worldview, partisans are forced into axiomatic frameworks that make progress a theoretical impossibility and steer them away from viable solutions. Shifting to a more accurate framework easily doubles the size of our solution space, and permits the development of mechanisms like Saito that can continue to impose cost-of-attack on attackers even in the face of malicious majority coalitions.

The post An Open Comment on Tim Roughgarden’s Lecture Notes on Blockchain appeared first on Saito.

Financial:

Our project finances remain in good condition: we have funding for approximately 2.5 years even in the event of a sustained bear market and no immediate plans for the sale of any project-held tokens.

Organization:

Our tech team consists of around 5 developers in addition to Richard and David. We have two developers focused on Rust (Sanka and Tharinda), two developers focused on our javascript client and application stack (Victor and Khan), and a single developer working on the Saito Game Engine and various gaming applications (Dan). 

We have churn in non-development positions, with departures from our former Chinese marketing hire (Shirley) and project manager (Karl) driven largely by the shifting needs of the project. We are grateful to both Shirley and Karl for their contributions. We hope to keep the benefits they’ve brought us while improving execution in marketing and content development.

As part of these changes, we are interested in hiring a growth/usability lead. The ideal candidate will report to the founders. A key part of the job is the ability to identify high-value work. We hope to find a Saitozen who can focus on prioritizing and fixing non-technical problems: everything from copywriting and graphic design to marketing and reachout.

Rust:

Our Rust team is now performance-testing our WASM client, collecting practical information about block processing and chain-reorganization speeds in live network conditions. We expect to complete this work within the next month, as we need the results in order to make development plans for the Second Era.

Javascript / Application Layer:

In the last few months our javascript team has released new modules like video-chat (NAT traversal), expanded support for web3 cryptocurrencies (DOT and KSM), contributed to several new games like Dominion and CDC, and started public testing of Red Square: our new on-chain social media platform. 

Lurking behind all of this work are fundamental improvements to our underlying game engine (i.e. players can now enter and exit poker games on-the-fly), our approach to CSS design and module structure, and also the way that UI Components can be coded and displayed across modules. We consider this work a key part of our dog-fooding process. We are trying to focus improvements on areas that will lead to sustainable transaction growth while also generating UI components that individual developers can use when making their own applications on Saito.

How to Help:

If you’re looking for ways to contribute, our open source “Magic” game is stuck at the stage where we need people to produce or solicit the artwork so we can move forward with card design and programming. If anyone is interested in playing around with Dall-E or Midjourney or Stable Diffusion please get in touch. We have other games under development that could use assistance with artwork / overlay / component design.

We welcome everyone to be part of making Red Square amazing – just posting and using Red Square – while we experiment and flesh it out. Having real usage is amazingly helpful in helping us all figure out what we should focus on. Having engagement on-chain is also a good way for us to shift from using non-Saito communication channels to primarily Saito-centric channels for talking about the project and pushing it forward. There is lots to do, and no better way to learn and prioritize than watching early adopters at play.

The post Saito Update – September 2022 appeared first on Saito.

The biggest challenge for us in accepting offers of help is when that requires tasking out work or managing a new project or taking on a significant amount of in-house coding. We are not complaining — just flagging that it’s harder for us when we have to take on new management work. With that in mind, we are finding that the following works:

If you are interested in hacking up existing code, please go ahead.

We have a list of random bugs and requests on Github. Some are also exploratory features. We welcome anyone to tackle any of these and submit a pull request.

If you are interested in developing a new Saito module or game, we will help you build it.

Our model for this is the great work that Naaq has done pushing Twitter forward. He started by creating a mock-up using HTML and CSS. That let us step in and build a backend once we had a wireframe to work from. We are a few weeks from being able to push this module back to the community. If you have something you want to build, this is a great model.

If you are interested in more foundational research, we have compiled a list of important tasks.

These range from researching commutative signatures to proposing ways to implement on-chain scripting or L2 VMs. If there is an obvious path forward from your research we will help you write a Saito Implementation Proposal. All members of our team can be reached on Telegram for private discussions of fundamentals and suggestions on approaches.

If you are interested in non-programming tasks, there are other ways to help as well:

• outreach and media work is always appreciated (you guys have been great).
• we need better tutorials and will assist writing them if you tell us what you need.
• please help keep Awesome Saito and SaitoFaqs updated.
• want to organize a game-specific leagues or tournaments?

We also have two specific community-led initiatives where assistance would be appreciated:

1. Red Square / Social Media:

Naaq who put together the HTML and CSS mockup that got the ball rolling with our Twitter clone. We quickly turned it into a live module that displayed the HTML. Then started brainstorming what features we think makes sense in a Saito-powered Social Media application.

We are about a week away from a basic CSS revamp well-enough done that we can continue work building this module. Once that is finished, we are hoping the community can help us flesh out the application — particularly the display of posts. Our team will focus mostly on generic features like the invites and scheduling features as we need them for arcade tournaments.

If you would like to help with this project and don’t mind the stop-and-go pace of development, please get in touch and we’ll connect you with the team.

2. Open Source Magic Game:

We have community interest in building an open-source card-based enchantment game. We think this is a great idea for many reasons:

• Two-player games are the most popular games on the Arcade
• Card games let us integrate smart contracts and NFTs atop Saito
• Historical resonance with the origins of Bitcoin and MtGox Exchange
• Massive potential for transaction volume at even modest scale

The challenge with card games is ensuring that there is no infringement. We are handling this by ensuring community work is done via a spreadsheet that allows us to confirm card-by-card if necessary that there is no infringement on anyone else’s IP. This means making sure that all Saito-implemented cards have unique and non-infringing text, descriptions and graphics.

Thanks to effort from a community member, we have a basic module that is letting us work through UI/UX issues. And we have a spreadsheet outlining a “starter deck” we can build. We need help with backend coding and with card design — but even non-designers can help by searching for suitable creative commons-licensed fantasy artwork. Once we have a playable game with usable cards we can consider sponsoring community development if the game picks up steam.

On a closing note, while we are happy to share news about where work is progressing, it is important to note that community projects really are community projects. One of the reasons we’ve been reluctant to talk too closely about work-in-progress is the concern that as soon as we mention the existence of any project, people will take it for granted and we will start getting “wen twitter” or “wen enchantment game” posts. We’re happy to help push community efforts forward, but we don’t want people developing unrealistic expectations since our ability to get this stuff done really depends on community support and assistance.

The post Saito Community Projects and How to Help appeared first on Saito.