Wiki home for Tezos+RPI3


We have created a wiki page to help sharing info about running Tezos on RPI3.

Anyone in the Tezos community and beyond is welcome to contribute.


I thought there was over $200 million raised to roll Tezos out?!


DLS has made available extensive documentation ( and the Foundation is also preparing for the official release (
Meanwhile there is no reason for the community not to be proactive.


I have made some changes in the Home page.
I think your RPI3 notes are more visible now to the visitor.


I like the changes, Thanks!
any thought about the baking eco coop?


We should create a step by step guide , in order to encourage people to join the baking eco coop.
And put it in the front page of the wiki.

Have you already wrote some quick and dirty instructions about it?


that is the easy part, but before getting there we need some kind of roadmap and decide how this is going to play, I’ll add more later. There has been also some discussion on reddit (same post) please have a look and let me know what you think


"Only issue here is making sure the decentralized servers stay online and don’t screw up and lose the stake. Companies use things like AWS due to the unreliability of local internet providers. "

Is this a technical problem? What happens when you bake in the zeronet, and the 1 third of your 3 RPI3 goes offline? Can you test that?

As an answer to the financial problem, those who do not stay online they will not get paid. This is solved in Dash , the masternodes who dont stay online, they lose their payments. Of course, in the case of a RPI3 network, we need someone to write some code (similar to the masternodes payee of dash)

"yes, that is a very good idea, for example tezos holder Alice has 4000 XTZ and a machine to bake, tezos holder Bob has 6000 XTZ but no resources to bake (time, experience etc…). B delegates to A and A does the baking for both. The question is how to make this operation secure for B and make sure A is properly rewarded for his/her work and operational cost? "

This is also solved in dash. They decided that bakers(miners) get 45%, the masternodes (online nodes used for instant trancactions) get 45% and the rest (developers, marketing e.t.c) get 10%.

So, also in our RPI3 case, somehow these numbers should be decided/voted.

The ones who delegate XTZ to the bakers get a percentage of the total profit, and the ones who keep their machine online and bake they get another percentage of the profit. And let these percentages either decided hardcoded (like it is in Dash cryptocurrency case), or voted among participants.

Initally I would vote 50% bakers-50% delegators.

The 50% of the profit will be divided to the XTZ holders who delegate to the bakers, proportional to their stake. The other 50% of the profit will be divided proportional to the number of the online baking machines.

So in your example Bob gets 0,6*0.5 = 30% of the profit, and Alice get ther rest 70% of the profit.

But dont take my 50%-50% vote into account, you have better let Alice and Bod vote about it. Alice obviously wants 100% of the gain to go to the baking machines (she holds 100% of the machines). Bob obiously votes 100% of the gain to go to the XTZ holders who delegate their XTZ (he has no online machine, so this is the better vote for him). If we apply the average, the result is similar to what i voted, it is 50%-50%.:stuck_out_tongue: Of course you may also allow Bob to cast conditional votes of the type: IF (my gain is more than 25%) then (I delegate 6000 xtz) and (I vote 100% for delegation) else (I do not delegate and I do not participate). This is how Alice will be forced to vote a percentage more than 0% for the delegation, and not only vote in favor of baking.

"The question is how to make this operation secure for B and make sure A is properly rewarded for his/her work and operational cost? "

Write some code for it, what else? Maybe a smart contract that will pay the above percentages in predefined time periods (ex. every month) ? Michelson language is the key concept.