We believe all community projects deserve our support. We also know it’s critical to build a community of developers and are grateful to everyone who has volunteered to help with Saito development. This blog post explains what problems we have run into, how we are fixing them, and what community projects are actually underway that need help.

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.


The current state of the CSS rework. Once it looks good we can return to prototyping…
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.

It has become conventional wisdom that there’s no way to tell attackers (wolves) from honest nodes (sheep) in an open network. The strength of this opinion is based partially on its promotion by talented developers like Vitalik Buterin and Zooko Wilcox-O’Hearn. But this opinion is nonetheless incorrect: to see why consider the difference that Bitcoin exploits:

While honest users build on the chain-tip, attackers build from a block at least one confirmation deeper into the chain.

This difference exists because attackers who are re-organizing the chain must produce two blocks in the same amount of time that the honest network has to produce merely one. The network exploits this difference to tax attackers: the cost of producing blocks is identical for wolves and sheep, but sheep who produce at the tip of the longest-chain are far more profitable.

So blockchains do differentiate between wolves and sheep – they do it by taxing behavioral properties that any node might exhibit, but that attackers must exhibit. It does not matter if this tax occasionally penalizes an honest node with an unfortunately dim view of consensus. As long as attackers are disadvantaged relative to a subset of honest nodes, the network can maintain its cost-of-attack while incentivizing honest behavior.

But don’t majoritarian attacks put wolves back on equal footing with sheep? Some developers may make this claim (“what I meant was…”) but note the shift in logic: they have moved from asserting there are no behavioral differences between wolves and sheep to asserting that no differences exist which can be leveraged to penalize wolves in majoritarian conditions. And this claim is also false.

All we need to disprove it is a single a difference that can systematically tilt income away from all wolves and towards an unknown subset of sheep. And it turns out there is at least one behavioral difference with this property:

When an attacker puts a transaction (that will be profitable for them to collect) into a block, they must be one hop deeper into the routing network than at least one honest node or user.

If an attacker is making money producing blocks, those blocks must by definition contain fees that come from someone else. In the absence of a block reward, every wolf that is not burning their own money to produce blocks must have at least one transaction in that block that was routed to them from an honest user or sheep, either sent to them as an unconfirmed transaction or stolen by them from a previously-published block.

As with Bitcoin’s tax on re-org depth, this difference can be leveraged to suppress the profitability of wolves: simply make block production more costly for deep-hop nodes, while forcing them to compete with shallow-hop nodes for control of the longest-chain. Saito does this by halving the value that fees contribute for producing blocks with every hop a transaction takes across the network. Any node at routing depth N+1 can produce only half the blocks and/or earn half the profits as a node at position N given the same set of transactions.

Taxing fee-transfers this way puts attackers at a disadvantage in producing blocks. This solution is counterintuitive to POW and POS developers as it requires the ratio between two variables that are fixed in their networks (cost of block production and income from producing blocks) to float. It also requires something missing in both POW and POS: cryptographic signatures that track who routes fees inwards towards block producers. Saito then tightens the noose further on wolves through a cryptographically-biased lottery that makes collecting payments less statistically likely for deep-hop nodes.

To conclude: security mechanisms in blockchains do not identify bad actors by intent. In this sense, those who insist it is impossible to tell the difference between “wolves” and “sheep” in blockchains are forgetting something they used to know: blockchains have always imposed cost-of-attack by taxing behaviors which must necessarily be exhibited by wolves and simply not caring if the trap ensnares a few unlucky honest sheep in the process.

 Written by David Lancashire