Image source: spigotmc.org

Decentralized Bounty Distribution Mechanism | Episode 1: Bounty Contract.

In this article, I am going to try resolving some aspects of a Decentralized Bounty Distribution Mechanism. To make it be able to work and easy to implement, I will set some assumptions that the bounty mechanism will be based on.

For now, some assumptions are still in my curious questions, but in the first looks, I believe that it’s not impossible to find a right way to prove it.

I will leave a 💣 behind the assumptions that I still keep thinking (it means not yet have the solution 😄).

The assumptions

1. Do it on Ethereum: For sure, I have no idea about another blockchain, but smartcontract on Ethereum is still good to make a Dapp.
2. Bounty is represented by the worth token: The worth token are native token (ETH) or some other token (ERC20). By this, the mechanism can be spreaded to many projects.
3. The Sponsor who creates a challenge with bounty or simply donate to an existed challenge.
4. The Hunter who tries to find the solution to submit it and get the relevant bounty.
5. The Judge the trusted guy who will tell you the solution is either correct or not. 💣

Simple, frank and truthful.

About Judge

In my first views, the judge can be a smartcontract that stores the proof of winner including the winner’s address, Proof-of-Solution... Further, to decide which hunter will be the winner, we need a council that is incentivized by Proof-of-Stake.

For now, the council we need, is represented by the judge.

Analyzing attackers

As we knew, smartcontract is the lines of code living on Ethereum network and anyone can interact it. Follow by that truth, we seperate the participants of the bounty into 3 main parties:

1. The sponsor: Could be an attacker because they have reasons to get free solution from hunter.
2. The hunter: Could be an attacker because they have reasons to get bounty without providing the correct solution.
3. The judge: Can not be an attacker because the assumption that the judge always acts well.

We have already known about participants of the bounty and who is able to become an attacker. We will construct a bounty contract that tries to deter all of risks.

Bounty contract

I decided to remove the fixed bounty and let it floats in the supply-and-demand mechanism, more bounty more interest. In addition, we take a side affect that is possible for multiple sponsors. (1)

With multiple sponsors, we must save the info “who staked and how much?”. Why do we need to save it? The reason is when the challenge ended and no one win, obviously the sponsors want to get their money back. “Who staked and how mush” is the way to validate who is legal to withdraw bounty.

It easy when staking by ETH because of fallback functions. But with token, it becomes a different story. When you transfer tokens to a receiver address, actually you are sending a transaction to the token contract and the receiver has no idea about that transaction.

To make the bounty mechanism work with token, we need a way to solve it.

We create a deposit() function, this function looks like a transfer-token proxy. Instead of directly calling transfer() to the token contract, the sponsors have to call deposit(). Firstly, sponsors have to call approve() that a standard function of ERC20, then call deposit() function of Bounty contract. In deposit(), we just re-constructs the data to call transferFrom() function in the origin token contract and then tracks “who staked and how much” down. (2)

That was a paint when we have to do 2 transaction for a simple work. I still keep thinking to find a better approach. One 👎 for me.

What happen if the sponsor is an attacker?

First of all, we understand that bounty contract should be created by a central party or just the sponsor.

If the bounty contract will be created by a central party, so that party can be drained their all money if exist too many requests of creating bounty contracts. So, it sounds too centralized and vulnerable to a trap door of DDoS.

Thus, we let sponsor create their bounty contract. Notice that, the sponsor can create but not means they can modify the code or even put some traps on it. We are possible to create a kind of master contract that have a function createBountyContract() with un-modifiable code or just release whole the bounty contract code and let the sponsor deploy it manually. Because on blockchain, we can see the code obviously so it easy to know that someone did modify it. (3) 💣

Btw, I still hesitate which one is better so I am 💣-ing it at the end.

Another aspect, if I am a sponsor, I would like to get the solution without paying or just send a smaller bounty than what I promised.

Obviously, to prevent it. Sponsor must be send the bounty into the bounty contract and we will find the way to not allow sponsor to reject paying the winner.

By basing on the judge, we do a strategy: (The duration is a period of time that the challenge is available.)

1. If the duration is not over, the sponsor cannot withdraw the bounty.
2. If the duration is over and have a winner that accepted by the judge, the sponsor cannot withdraw the bounty.
3. If the duration is over and have no winner that accepted by the judge, the sponsor can withdraw the bounty.

Gosh, thank for The judge.

By these restrictions, once the sponsor deposited the bounty, they have no way to withdraw during the challenge time and even at the end if having a winner. (4)

What happen if the hunter is an attacker?

In the case of the hunter attacking Bounty contract by withdrawing bounty illegally. To prevent this kind of problem, we just let Bounty contract have the ability to communicate with the judge (5). If some one try to withdraw bounty as a winner, Bounty contract will validate them by ask the judge that the sender is whether the winner and decide to release the bounty or not.

I̶n̶ ̶a̶d̶d̶i̶t̶i̶o̶n̶,̶ ̶W̶e̶ ̶a̶l̶s̶o̶ ̶h̶a̶v̶e̶ ̶a̶ ̶k̶i̶n̶d̶ ̶o̶f̶ ̶o̶f̶f̶-̶c̶h̶a̶i̶n̶ ̶s̶y̶s̶t̶e̶m̶ ̶t̶o̶ ̶t̶r̶a̶c̶k̶ ̶t̶h̶e̶ ̶b̶o̶u̶n̶t̶y̶ ̶c̶o̶n̶t̶r̶a̶c̶t̶ ̶(̶c̶a̶l̶l̶e̶d̶ ̶t̶h̶e̶ ̶t̶r̶a̶c̶k̶e̶r̶)̶.̶ ̶S̶o̶ ̶i̶f̶ ̶t̶h̶e̶ ̶b̶o̶u̶n̶t̶y̶ ̶i̶s̶ ̶s̶m̶a̶l̶l̶ ̶a̶n̶d̶ ̶i̶t̶ ̶i̶s̶ ̶p̶o̶s̶s̶i̶b̶l̶e̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶h̶u̶n̶t̶e̶r̶ ̶t̶o̶ ̶t̶o̶ ̶d̶e̶s̶t̶r̶o̶y̶ ̶o̶u̶r̶ ̶s̶y̶s̶t̶e̶m̶ ̶b̶y̶ ̶m̶a̶k̶i̶n̶g̶ ̶a̶ ̶D̶D̶o̶S̶ ̶t̶o̶ ̶t̶h̶e̶ ̶t̶r̶a̶c̶k̶e̶r̶s̶.̶ ̶F̶o̶r̶ ̶i̶n̶s̶t̶a̶n̶c̶e̶,̶ ̶t̶h̶e̶y̶ ̶w̶i̶l̶l̶ ̶g̶e̶t̶ ̶i̶n̶ ̶t̶o̶u̶c̶h̶ ̶w̶i̶t̶h̶ ̶a̶ ̶l̶a̶r̶g̶e̶ ̶n̶u̶m̶b̶e̶r̶ ̶o̶f̶ ̶w̶i̶n̶n̶e̶r̶ ̶a̶n̶d̶ ̶i̶n̶c̶e̶n̶t̶i̶v̶i̶z̶e̶ ̶t̶h̶e̶m̶ ̶t̶o̶ ̶g̶i̶v̶e̶ ̶u̶p̶ ̶t̶h̶e̶ ̶b̶o̶u̶n̶t̶y̶ ̶b̶y̶ ̶a̶ ̶b̶i̶g̶g̶e̶r̶ ̶o̶n̶e̶.̶ ̶T̶h̶e̶n̶ ̶w̶e̶ ̶n̶e̶e̶d̶ ̶a̶ ̶m̶a̶s̶s̶i̶v̶e̶ ̶n̶u̶m̶b̶e̶r̶ ̶o̶f̶ ̶t̶r̶a̶c̶k̶e̶r̶s̶ ̶t̶o̶ ̶f̶o̶l̶l̶o̶w̶ ̶a̶l̶l̶ ̶o̶f̶ ̶t̶h̶e̶ ̶b̶o̶u̶n̶t̶y̶ ̶c̶o̶n̶t̶r̶a̶c̶t̶s̶.̶

T̶o̶ ̶g̶e̶t̶ ̶t̶h̶i̶s̶ ̶p̶r̶o̶b̶l̶e̶m̶ ̶o̶v̶e̶r̶,̶ ̶w̶e̶ ̶s̶e̶t̶ ̶a̶ ̶d̶u̶r̶a̶t̶i̶o̶n̶ ̶(̶6̶)̶ ̶t̶h̶a̶t̶ ̶i̶f̶ ̶t̶h̶e̶ ̶w̶i̶n̶n̶e̶r̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶t̶a̶k̶e̶ ̶t̶h̶e̶i̶r̶ ̶b̶o̶u̶n̶t̶y̶ ̶i̶n̶ ̶t̶h̶e̶ ̶p̶e̶r̶i̶o̶d̶ ̶o̶f̶ ̶t̶i̶m̶e̶,̶ ̶t̶h̶e̶ ̶m̶o̶n̶e̶y̶ ̶w̶i̶l̶l̶ ̶b̶e̶ ̶r̶e̶-̶c̶o̶n̶t̶r̶i̶b̶u̶t̶e̶ ̶t̶o̶ ̶t̶h̶e̶ ̶c̶o̶m̶m̶u̶n̶i̶t̶y̶ ̶s̶o̶m̶e̶h̶o̶w̶ ̶�̶�̶.̶

Dummy of codes

From (1), (2), (3), (4), (5) a̵n̵d̵ ̵(̵̶̵6̵̶̵)̵̶̵. I built a contract like this:

It’s just a dummy of codes, and pretty sure that it cannot work. Please use it for research purposes only. 🚫🚫🚫