This is why we use the term General Grievous Attack at Saito to describe the hardest variant of the 51% attack to solve — the version where the bad guys just ignore the good guys, refusing to relay their messages or even include any transactions forwarded by them that might trigger routing payouts to other nodes.

This makes the attack impossible to punish in proof-of-work and proof-of-stake mechanisms under majoritarian conditions. Our attackers are not producing fewer blocks after the attack than before. They are not processing fewer fees. And they are still producing blocks faster than their honest counterparts while controlling all the “votes” that determine who gets paid — so how can it be less profitable for them to produce blocks?

In this blog post, we’ll show how “routing work” solves the General Grievous Attack. And in the spirit of generosity, we’ll do it while giving our attackers a formidable 75% of all first-hop routing work, 100% of network hashpower and 100% of the ATR payout. Other consensus mechanisms have long since collapsed. But routing work continues to function.

To see how, assume our blockchain processes 100 USD in fees per block. Our pre-attack payouts are as follows:

The mining payout consumes its reward in energy costs, making the attacker’s pre-attack income 62.5 USD:

Right away, we can see why cooperating with honest nodes is beneficial to the attacker. Were our attacker to produce a chain with only the transaction fees they are collecting, they would lose 25% of their 75 USD in mining costs and earn only 56.25 USD. But their results are even worse under the General Grievous Attack. Consider the changes:

Post-attack income is consequently:

Attackers have gone from earning 62.5 USD per block to somewhere between 31.25 USD and 56.25 USD. Not only is attacking irrational, but it is even provably costly in any network where infrastructure providers pay competitive rates for inbound fee-flow. And any rational users can increase this cost-of-attack further simply by withholding their transaction flow, or sending it to another node.

Advanced Commentary on Asymmetricality

Our attacker blockchain will eventually settle into a lower-fee equilibrium. Once enough golden tickets go unsolved (burning the routing payout for good) mining difficulty will drop. And as censored transactions join the ATR loop, their fees will help buffer some of the collapse in fee-throughput. But losses are suffered during the transition, and bourn by the attacker who proposes the blocks during this period.

Cost-of-Attack can be increased further by having consensus observe and punish any drop in new fee throughput, expansion in the set of UTXO subject to rebroadcasting, or any sharp increase in aggregate routing work by simply burning a portion of the fees collected during this period before payouts are calculated. This conditional-burning is a second type of asymmetrical tax, as it does not affect honest block producers cooperating in equilibrium.

The symmetrical attacks of proof-of-work and proof-of-stake vanish. We transcend them by shifting away from “voting systems” where any majority can impose costs on any minority and towards an efficiency tax powered by a fee-unlock “flywheel” that punishes nodes who push the network into a less efficient state. All nodes will rationally spin up the flywheel if they have access to third-party fees. More fees means more blocks for them and greater profits. And all honest nodes will accept these blocks as any efficiency gain elsewhere in the network increases their own profitability.

But attackers? Because attackers are deliberately orphaning efficiently-produced work, they must either spend and burn their own money to maintain the network in a state of artificial efficiency (burning their own money to avoid greater losses) or accept the cost of slowing the flywheel by letting it consign a quantifiable amount of the fees they are contributing to oblivion.

In this way, routing work achieves a quantifiable and asymmetrical cost-of-attack that punishes attackers without introducing symmetrical attack vectors on honest minority nodes. Problems unsolvable in the old system melt away in the new paradigm. When General Grievous threaten to abandon ship, the best strategic move is simply to let them go.

The post The General Grievous Attack appeared first on Saito.

The paper is deliberately short (2 pages) both in a nod to Paul Samuelson’s similar 1954 paper on public goods provision, and because brevity makes the material easier for non-economists to understand.

Feedback and suggestions are welcome. I’d be interested to learn from anyone more current on public choice theory if we have any non-blockchain examples of mechanisms that evade Samuelson and Hurwicz’s impossibility conjectures by inducing competition for collection of a private payment. My suspicion is that what we have is indeed new, as prior to the invention of self-provisioning ledgers all communications channels would require a trusted third party to provision, and private provision removes non-excludability.

For computer scientists wandering into fee-optimization problems, I hope the paper helps understand how economics models this class of optimization problem. It is surprising how few people in distributed systems cite the work of Paul Samuelson and Leonid Hurwicz. This is particularly surprising given that Hurwicz invented the term “incentive compatibility“, authored a seminal paper on “informational decentralization” and won a Nobel Prize for mechanism design theory.

In this specific case, a lack of familiarity with their work can lead to fundamental analytic errors:

• forgetting that the token is a fungible form of value, which means that we cannot have an “optimal” transaction fee unless the user cannot get more utility from spending the same fee on other goods or services.
• not understanding that pareto optimality is a prerequisite for an incentive compatible and collusion-proof mechanism: if any subset of parties can costlessly improve their utility without making others worse off then that same group can always increase their utility by following a byzantine strategy.
• failing to differentiate between forms of collusion that lead to sub-optimal outcomes and forms of price negotiation which create optimal outcomes, which in turn indicates lack of awareness of optimal and sub-optimal market structures and collective action problems.
• incorrectly assuming that global pareto optimality (“Global SCP”) is harder to achieve than incentive compatibility (“1-SCP”), an error that seems to step from the idea it must be harder to coordinate an optimal outcome if there are more participants involved, whereas it is easier to achieve pareto optimality globally since it is a necessary but not sufficient condition for incentive compatibility, which is what is needed to make collusion irrational.

On a closing note, I believe it follows fairly directly from the work presented here that the ability of users to collude with block producers in ways that are socially sub-optimal depends on the ability of the block producer to increase their profits from another source: either free-riding on an inflationary block reward or on the unreciprocated and irrational willingness of peers to propagate unconfirmed transactions. It is possible that no mechanism with an inflationary block reward can ever be secure against collusion, as it cannot be secure against free-riding.

With luck, the issues with the way computer scientists are framing and analysing these economic problems in blockchain will self-correct as more people become aware of how powerful economic frameworks and tools are for analyzing these mechanism design problems.

The post Socially Optimal Transaction Fee Mechanism Design appeared first on Saito.

This post assumes readers understand how routing work (10 minute read) functions. It explains how this approach imposes asymmetrical losses on attackers who control at least 50% of network resources, achieving the “economically-expensive in the absence of collapse” (EAAC) property the above authors incorrectly claim is theoretically unattainable.

Cost-of-Attack comes from ATR Payout

Consider the case of two block producers who each control 50% of network resources. As required by routing work, both X and Y burn tokens to produce blocks and then burn hashpower to unburn their tokens and distribute them to network participants.

Because 25% of every solved block flows into a treasury that funds the “ATR payout”, and because this payout flows to holders of the oldest unspent UTXO, it follows that any block producer creating a stealth fork using their own tokens will push the balance of all future ATR payouts asymmetrically away from itself in perpetuity.

No Consistency Violation Without Payment

This tax is not symmetrical to non-attackers, because it only bites in the event of a successful consistency violation and that depends on who produced the last pre-fork block. If Y produced this block, no honest participant or observer is disturbed from their preference for the honest chain. If X produced this block, then Y will trigger a consistency violation when it releases its chain and assume its asymmetrical losses at the same time.

The only situation in which Y can trigger a consistency violation otherwise is if it spends its own money to speed-up the pace of its stealth-chain by creating “fake transactions” which nonetheless pay real fees. But including these self-generated transactions necessarily adds more asymmetrical losses for Y since a greater portion of Y’s wallet is now distributed to X via the ATR mechanism.

Can’t Y include the same transactions as X?

It is true that Y can theoretically avoid the ATR Penalty by including in its blocks the same transactions that X is using to extend its chain. This tactic keeps the balance of unspent UTXO between X and Y symmetrical and prevents Y ceding asymmetrical claims on future ATR payouts to X.

There are problems here that become self-evident as one gains an understanding of routing work. The first is that honest nodes maximize their income by not sharing transactions to which they have exclusive access with peers. So X cannot be expected to give free routing work to Y if they have equal access to transaction inflows. And Y cannot extract these transactions from X’s blocks without the cryptographic signatures X needs to provide to authorize the transfer.

Making matters worse for the attacker, even if X irrationally feeds its transactions to Y, as soon as Y adds these second-hop transactions to its blocks their inclusion makes X eligible to win the routing payout on Y’s chain. This creates a second cost-sink for Y unless it finds more hashpower to brute-force the payout lottery, which also requires majority control of network resources and a willingness to hash at a loss.

We also remind readers that the consensus layer has the informational ability to penalize attackers irregardless, since the fall in the efficiency of fee-inclusion created by disappearance of X or Y is visible to the consensus layer. This efficiency-drop becomes observable because unless Y controls 100% of first-hop routing work, its fork must either lower fee-throughput or increase routing-path length to generate a competitive chain. And consensus can punish this loss of efficiency by throttling payouts (adding a discretionary burn) which targets the routing and mining payouts and harms the block producer.

Closing Thoughts:

It is unclear if the failure of these authors to correctly characterize this problem space or its limits is a result of their being uninformed about modern techniques in distributed consensus or if they are simply constrained by the belief that these issues are unsolvable and focused on trying to universalize the limitations of proof-of-stake.

Whatever the reason, the conclusions of the paper are incorrect – the real limits of economic security are much higher than its authors imagine for reasons and through mechanisms they do not consider.

The post The Economic Limits of Permissionless Consensus appeared first on Saito.

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.