Staked Competitions by Stove Labs & Tezos Commons

Building a re-usable competition platform for decentralized artists.

Matej Šima
Jul 1 · 5 min read
Work in progress at the Stove Labs office in Vienna


Staked Competitions is a suite of tools, with the intention to provide the Tezos community with a fair and decentralized way to run an on-chain competition, revolving around Digital Assets hosted on the IPFS network.

“Staked” — because contestants will be required to pay a fee before submitting an entry, therefore creating a form of stake or a certain level of gamble to prevent wrongful behavior or abuse.

This article is a beginning of a series that will discuss design, implementation and a testing/production run of the first Staked Competition on Tezos Alphanet & Mainnet.

We’d love to gather feedback on the competition design from the community.

The first use case

The idea to build Staked Competitions came to life when we first realized that there isn’t a single Tezos sticker pack on Telegram*. No matter how silly it may sound, it sparked an in-house discussion about how to get people from the community involved in creating a truly decentralized sticker pack.

Image by smalllikeart

Telegram is a messaging platform with a vivid community, check it out here.

* There might already be an existing sticker pack, but we wanted a community curated set of stickers.

Competition mechanics

Overview of how the competition should be laid out is relatively straight forward — it’s going to be implemented in two main parts:

  • Competition smart contract
  • User interface to submit/vote/interact with the ongoing competition

There are two main types of users:

  • Contestants → people who submit an entry (or entries) to the staked competition
  • Voters → people who vote for their favorite submission in the competition.

There are three phases of the competition:

  • Submissions phase → during this period the contract will accept submissions into the competition by contestants
  • Voting phase → during this period the contract will not accept submissions into the competition by contestants, but will accept casting of votes by the voters.
  • Rewards phase → during this period, votes or submissions won’t be accepted, and instead the rewards for winners will be paid out.

There are a few constants that define the economical aspects of the competition, all of those can be changed or tweaked depending on the current competition context:

  • Submissions phase end date→ this will represent a time(stamp) until when the contract will accept submissions, and the end of this period, the voting period starts automatically
  • Voting phase end date → this will represent a time(stamp) when the voting period will stop, and the contract will no longer accept any votes. From now on it enters the Rewards phase, where the rewards can be paid out by executing the contract.
  • Submission fee → fee that’s charged when a contestant submits an entry to the competition. Designed to prevent spammy behaviour on the side of the contestants. Submission fee is the amount of XTZ required to submit an entry to the competition — the amount is accounted towards the contract’s balance.
  • Max fee per vote → fee that’s charged when a voter submits a vote for his favourite submission — the amount is accounted towards the contract’s balance.
  • Maintenance fee → fee that’s charged when a contestant submits an entry to the competition, or when a vote is cast. Used to support the off-chain infrastructure required to run the competition, or previous/further development efforts. Amount computed as the maintenance fee, is not accounted towards the contract’s balance, but rather transferred to the account that created the competition.
  • Prize pool percentage → Percentage that defines how much of the contract’s balance is considered as the prize pool.
  • No. of winners→ Number of submissions considered winners, as a result of the voting process.
  • Reimbursement percentage → When the competition is over, e.g. 50% (Prize pool percentage) of the prize pool will be split evenly between the top e.g. 5 (no. of winners) submissions, and the rest of the contestants will be (partially) reimbursed from the remaining prize pool.

It’s important to define the competition mechanics in a way, that the competition is not worth abusing for profit. If you have any doubts or improvements, please let us know on social media.

Walking through an example competition

In theory, anyone can create a staked competition, so let’s walk through a concrete (yet theoretical) example of how a competition could play out.

  • Submissions phase end date = 15th of August
  • Voting phase end date = 30th of August
  • Submission fee = 20 XTZ
  • Max fee per vote = 1 XTZ
  • Maintenance fee = 10%
  • Prize pool percentage = 90%
  • No. of winners = 3
  • Reimbursement percentage = 10%

A contract is deployed together with it’s respective user interface, this automatically opens the competition for submissions from contestants.

Each submission requires a fee of 20XTZ (+ minor network fees, storage etc.)

Until this date, contestants have submitted 5 entries, and the voting period starts. Voters can vote for one, or multiple entries by sending XTZ (votes) to the contract.

Balance is now 5 x 20 XTZ = 100 XTZ

Voting period is over, now the rewards phase starts. Which means that the contract can be called (by anyone) to pay out the rewards.

During the voting period, there have been a 1000 votes, each one carrying a voting power of 1 XTZ. Balance is now 100 XTZ + 1000 XTZ= 1100XTZ

Counting in the maintenance fee, we end up with a prize pool of 1100 XTZ * 0.9 = 990 XTZ and a maintenance fee of 1100 XTZ * 0.1 = 110 XTZ

Prize pool consists of 990XTZ * 0.9 = 891 XTZ, and it’s paid out evenly to the top 3 winners. Which means that there will be a reward of 297 XTZ for each submission that has placed in the top 3.

Reimbursement pool consists of 990 XTZ * 0.1 = 99 XTZ, which means that the two remaining contestants get a reimbursement/reward of 49.5 XTZ each.

Keep in mind that the reimbursed amount for contestants who were not lucky enough to win, may or may not be equivalent to the submission fee paid when entering the competition.

Tezos Commons

Updates and insights from the global Tezos community

Matej Šima

Written by

Tezos Commons

Updates and insights from the global Tezos community