Laika - A perpetual Testchain / onboarding opportunity

An ounce of prevention is worth a pound of cure.

I would like to see a permanent testchain that is upgraded before the primary chain. In order to flush out and avoid issues like we are seeing with the Granada upgrade ( and the kinds we have come across in the past ).

I don’t think it necessarily needs to be subsidized. Perhaps in the beginning. I think a testchain where the value of the coin is forced to zero ( thereby making all transactions non-taxable ) could be used as an onboarding opportunity for people to learn crypto without risk.

Which also makes it a fantastic marketing opportunity.

You could force the value to zero by making the coin centralized and explicitly stating that you will delete the balance of any exchange addresses.

Since it’s not necessarily meant to be decentralized a node owner could allow access to testing teams. Those teams could update or roll back various parts of the networks version in order to test varying conditions or simulate the current conditions ( or whatever desired ) of the mainchain.

Updated 12/11

What do we need to test on this network?

Should the test networks run the same protocol as mainnet or a patched version?

What power should the admin have?

What is the plan for the network to be self sustaining?

Sources of funding / sustainability:

  • Advertisements on a webpage and or in an app. Why would people see ads on/in a testchain? - Because it is used as a means of teaching crypto to people that have no experience with it but are curious.

  • A crowdfunding DAO. The DAO offers tokens during a fundraising phase. The token holders vote on the admin keys once or twice a year. Make it explicitly clear that the DAO is in no way shape or form, for profit. It’s mission is to provide value to the Tezos blockchain while remaining self-sustaining.

  • Sell use of the chain to dev teams, when the chain is developed enough for this complexity. For example, the chain could be paused with a snapshot, the team runs it’s tests and when it is over the snapshot is reloaded and the chain starts up where it left off.

  • Another option is for the testnet to run a bakery with a higher than average fee, say 20%. With the understanding that ( for example ) 80% of proceeds go to funding the testnet.

( When you don’t start from the position that the TF must / should / is best to fund it, you suddenly get a lot more creative with your solutions )

Update: 12/16/21

From feedback some Dapp developer teams are going to want a perpetual testnet without characteristics different from mainnet, such as faster blocktimes.

For that reason a second network with the working name “ghostchain” will be developed at my own personal cost at the moment.

Links to different community platforms:

Element chat -
Telegram channel - Telegram: Contact @Teztchain
Slack - #laika-testchain <— channel name
Discord server - Laika - The blockchain playgound


It’s hard to disagree with you today that we need additional testing but isn’t there a testnet chain spun for every update for this purpose? Need more testers/bakers to make it look like mainnet?
We can incentivize people bake on a testnet just like TCF allocates some tez for grants every month.

1 Like

I would love to see something like Kusama and Polkadot. Their testchain Kusama acts like mainchain itself which is basically a test in production environment.


Testchains like edonet or florencnet are not the same thing. They are forever on that one protocol.

A testchain as I am describing would upgrade to the newer proposed protocols before the mainchain. It would also roll back if a proposal were rejected.

Preferably without rolling back the transactions.


My suggestion is after end of proposal period, a fork of test chain will automatically generated and all bakers would also onbard both mainnet and the testnet by default. This behavior should also formally be part of Tezos protocol, the testchain lives until mainnet take over the new protocol.

This way, we can even remove the adoption period entirely, currently the adoption period mostly is just a pure waiting game.

As a large scale distributed system which requires mutiple upgrades each year, a smooth and less surprising way of upgrading process is as important as other parts of this project.

Also it would be better if there were some upgrade checklists on (or explorers etc), show key metrics like testchain missing rates, average block time, branches, average CPU, RAM, disk IO, node versions etc. With all these data at hand, bakers can have more confidence to vote during promotion period other than just vote yay/nay blindly.


I agree with this. Might be good to follow polkadot’s/Kusama’s example and make a testnet with cheap Tezzies so bakers can be more incentivised to help out. We definitely need to make these upgrades more fluid or big corporations won’t even consider Tezos for their projects.


I am seeing this topic come up more and more in the community.

A big disparity I am seeing is on whether it need to be incentivized via some external funding.

It seems as though many are not willing to take action unless they are funded. I’m certainly not against that but it is not necessary to get started and demonstrate why you might deserve funding and how you might intend to operate once the funding is gone.

The people in 2018 who made a big stink about testing gave up because they convinced themselves that they had to have funding. If they have slowly built things up since then, than today we would have the testchain we want and they probably would have gotten at least some funding at some point.


A improvement of protocol upgrading test indeed does not absolutely require funding. The key issue here, our existing testnet is not designed for blockchain project like Tezos, it’s more like bitcoin testnet which a clean from scratch genesis block with total new test bakers. This works only for PoW blockchain, because miners compete eachother with CPU powers.

This is not the case for Tezos though, Tezos baking right pre-allocated to bakers according to their size, so the clean testnet can not simulate the real mainnet edge cases.

Simply fork the mainnet after proposal period and use the same chain history for testnet can improve the test dramatically. Somebody may say not all mainnet bakers willing to participate testing, well that’s actually better for testing. During real mainnet upgrade, some bakers offline ,some bakers run old version, some bakers simply late due to timezone issue. A wild situation can expose and capture more bugs with small well look after testnet.

Back to incentive topic, well my sugguestion is TF can simply delegate some of their tezzies to those bakers who actively tested, even better delegate to them and ask for less or zero baking reward.

1 Like

I would like to see a permanent testchain that is upgraded before the primary chain. In order to flush out and avoid issues like we are seeing with the Granada upgrade ( and the kinds we have come across in the past ).

The proposal testnets (such as Florencenet and Granadanet) are upgraded before mainnet. The transition from Florence to Granada in particular was tested on the Granadanet.

What is special about the testnet being permanent? How would this help detecting these kinds of issues?

I think a testchain where the value of the coin is forced to zero ( thereby making all transactions non-taxable ) could be used as an onboarding opportunity for people to learn crypto without risk.

How does this differ from the current situation? Testnet tokens are worthless because you can get them for free at the faucet.

Testchains like edonet or florencnet are not the same thing. They are forever on that one protocol.

Not exactly, they start on the predecessor protocol precisely because we also want to test the migration. They migrate in the early days of the testnet, usually through an on-chain vote.


Quite a lot of code would have to be written (and tested!) to allow to roll-back protocol upgrades. For example, if a protocol introduces a new Michelson instruction and some smart contracts are originated with it what should we do about them?

1 Like

We tried a variation of this for several upgrades (until Florence), the main problem is that because testchain tokens are worthless, a deny-of-service attack on a testchain node is cheap so it is not a good idea to run a baker on the same machine than a testchain node. See Draft: Add a draft for the deactivation of the test chain (!141) · Merge requests · Tezos / tzip · GitLab for the other reasons to deactivate this feature.

I don’t see the relationship between the adoption period and testing. The adoption period is about uncertainty on the result of the promotion vote.


Deny-Of-Service can and had happened on mainnet too, actually every upgrade always come with some level of “Deny”-Of-Service attack, that’s why I said it’s even more valuable for testing purpose. One or some big bakers can literially performance Deny-Of-Service attach by accident, and our chain should survival in such situation as much as it can. This is actually another area Tezos should improve, for example binance, coinbase and all TF bakers offline for what ever reason for several cycles, Tezos blockchain in theory should slowly back to normal rather than be impacted for all that period.

No need to make the testchain token valuable at all, some small incentive can be done by TF using the delegation as bonus etc would be enough to onboard enough bakers.

1 Like

What do we need to test on this network?

I am interested in feedback from the dev groups on what they would like to test. At bare minimum the great value I see is the having a place to test a proposal before it is even voted for. Competing dev teams could bid on who gets to have their protocol tested. This could help fund the chain.

Should the test networks run the same protocol as mainnet or a patched version?

The Aristotelian mean we should reach for is, similar enough to the mainnet that the tests are relevant / valuable but not so similar that it competes with the mainnet or could be used to deceive / scam others.

The addresses should be different and the great effort should be made to distinguish both chains. It should not be possible (if possible) to send tokens from the mannet to the testchain or vice versa.

What power should the admin have?

The more the better. Destroy tokens, magic any amount into any address, Invalidate a baker etc… To make sure the testnet does not experience lag from baker drop off, until baking is stable, the vast majority of the network should be validated by testnet foundation bakeries.

What is the plan for the network to be self sustaining?

To begin with, self funding, donations / community funding and possibly foundation funding ( without relying on it ).

IMO the best avenue is commercialization through turning the testnet into a crypto noob onboarding platform. A modicum of ad space in wallets and webpages should pay for the network. This is also a means of obtaining organic traffic on the test chain which simulated networks cannot achieve.

Another eventual avenue for funding is for dev teams to be able to take over the network at a cost to them. The network would take a snapshot of it’s state before the test, after the test is over the snapshot is reloaded and the network picks up where it left off.

1 Like

I don’t think many people would pay to learn to be a baker right now. There just isn’t a cost benefit to it. Also website advertisements don’t pay that much money. I’m not sure if the revenue stream ideas you bring up match the e goals of the testnet, unless I am misunderstanding them. Also you would have to find someone passionate about all these areas and connect them all together if you really think it will work.

You’re misunderstanding my proposal.

Not looking to have people pay to learn to bake. You market and offer the perpetual Tezos testnet as a tool for people with no experience in crypto to learn how to use it with no risk. This brings users to the ads. Ads are highly lucrative done right, and should provide plenty enough revenue to pay for the network. Tezos is economically efficient after all.

I have been evangelizing crypto since 2013, often to groups of people. I spent last week at Art Basel doing the same. I am quite confident there is demand for such a thing. It would also be a great place for devs to learn blockchain at no cost or risk. This I believe could be a breakout mechanism for Tezos.

Also, there is the DAO option I eluded to in the OP for initial bootstrapping.

1 Like

Weren’t you the one advocating to let people pay ~$100 to start baking on Kaizen? It’s literally in your original proposal Kaizen - A perpetual, incentivized, every-improving testnet

No, the actual incentivization would come mo the down the line. Please reread the proposal.

Baking would be free with the hopes that we could get it incentivized months down the line. All projects need funding or hope of compensation. People need to feed their families.

More in general, what’s the main underlying reason for rewarding users of this perpetual testchain?

If you’re a developer or Tezos enthusiast the intrinsic value for wanting to run a testnet baker is to support the community and to enable developers (including yourself) to have a reliable way to test dapps before deploying smart contracts to mainnet.

We’ve been running protocol proposal testnets for a while now and I don’t understand why there have been such strong discussions lately about monetary incentives for testnets. IMO these incentives shouldn’t be an hard requirement for running a perpetual testnet. I agree they would help keep the testnet bakers more accountable but the rewards could be implemented at a later stage.

1 Like

I largely agree with where you are coming from and agree that there is enough intrinsic value in running a perpetual testnet that it should not be hard to have a large portion of the network ran by bakers and supporters. Hopefully the whole thing with a DAO holding the admin keys one day.

I don’t think things will start that way though and to guarantee the networks uptime and actually happening, I would not want to rely on volunteer validators. That means expenses in terms of machines and bandwidth.

There are also costs around dev time for customizing the code here and there and making adjustments.

I personally want to champion Laika as a risk free on-boarding tool for newcomers to crypto. That means paying devs to fork wallets, then that also means support etc… I think those things will pay for themselves via ads, donations and price action for Tezos, but not necessarily right away.

Maybe eventually a Laika DAO could amass enough donated Tez that it’s baking rewards pay for it’s operation.

The only way to fund this is by donations from private individuals or TF donations, or with a monetary emission inflationary tax.

@tezosfoundation doubtly will not donate any to fund this initiative, we have seen this with the failed LB experiment (that we still funding it by the way), they could had perfectly fund LB with their block rewards but they turned a blind eye and we had to fund it ourselves by taxing ourselves with monetary emission.

The thing is that TF is extremely conservative with the war-chest, to the point that we can’t call that conservative anymore, but miserable.

1 Like