As a project admin, I create a new EthKan project so funders can send crypto to tasks on project boards to earn project tokens when the task is verified as completed.

[kingflurkel]

EK-001 - As a project admin, I create a new EthKan project so funders can send crypto to tasks on project boards to earn project tokens when the task is verified as completed.

Abstract:

In General
EthKan is a website/app that allows anyone to create an ITO (Initial Token Offering) for every card on a project board. This gives anyone the ability to organize, communicate, and crowdfund any project and any task all from EthKan.

The Problem EthKan is solving
ICOs work by sending ETH to a smart contract that mints new tokens and sends them to the sender. So value is transformed from one token to the other. The problem is that the initial token is not burnt, but keeps on living as “project funding”. With the rise in value, this means projects end up with sums of eth which outfactor the initial goal. This results in challenges for governance, management of the funds etc.

We believe the value should be transformed when added value for the project is created, thus transforming the ETH into actual value creation for a specific project.

This enables people to decentralize project funding and project execution.

How it works:

A project manager logs into a EthKan project management website to set up a new project. In EthKan, boards are created and linked to the new EthKan project. Then, the project manager may create task cards on the EthKan project board. Each card is a step towards completing the overall project goal, and anyone viewing the board can easily see and conceive of the value of each step.

When a card is created, a new token is created along with it. Each card also has an Ethereum address. Project investors send Ether to the card address to help fund that particular task. Card tokens will be created proportionally to the amount of Ether sent, and given to the project funder that sent Ether. That token gives the card funder(s) the right to decide when the task is done.

The card token also helps express how potential project investors view the value of that card in the scope of the entire project. The more the card is funded, the more valuable the task.

Then, service suppliers (including the project manager) may “claim” the task. To make sure suppliers have incentive to not spam the board by claiming a task and not completing it, suppliers are required to put a certain amount of Ether in escrow in order to be allowed to claim the task. The supplier escrow amount will be determined when the card is created.

When service suppliers complete tasks, they must prove it by attaching that proof to the card itself. Project investors who hold tokens in that card may vote to approve the task completion. Once approved, the Ether is released to the supplier and project tokens are minted for the card investors. Project tokens represent stake in the overall project, and token holders benefit from “owning” a piece of the project itself. Card tokens are burnt when the funder receives the project token.

What it looks like in front end:

Link to clickthrough model on Invision

Documentation / references

♡

[GriffGreen]

Cool so a new token for every card, generated 1:1 for ETH? So 1 board can have 100's of tokens coming out of it.

That can work :-D and i would imagine we will have a lot of flexibility with that model, their might be a benefit to assuming we use a side chain for this. And build a sort of bastardized TCR model....

Where you have a "cross chain crowdsale" ETH is sent to a "Card" but really that ends up as a send to a bridge contract with data attached logging which card it is backing (or is given to a project admin to distribute to the cards they and then it gives the user the Classic ICO token on Mainnet.

That token is the currency people are building the board to create a value premise around. These tokens always have a premine right? In a classical ICO the premine is vested to incentivize the team running the ICO...

well now what we can do instead is have the project admin(s) have a token multiplier so that the people that complete cards get ETH and Tokens on the Main chain (after x days for security via time delay)

I think that instead of voting tho, we really rely on the Project admin(s) to be the reviewers of the task and to incentivize them with Vested Tokens and keeping them honest via transparency... making them claim and address and instilling a culture of communication.

If the Project Admin wants to appoint someone else to review the task they can, but then maybe that other person should just start a board and add the cards that they are going to be responsible for. In the end we still rely on the original donor to pick what board/project admin to send the money to

[GriffGreen]

Of course what will kick this up several levels is integrating Liquid Pledging to it ;-) so then lazy donors can just send money to someone they trust to manage it for them effectively... this will make sending money to a board way more simple, removing the extra step of thinking about what card to donate to. but probably starting with 1 board and one project admin for one relatively small project with just eth and tokens (no multiplier) is probably the way to go... and in this model a website could be built that the project admin could use to suggest specific cards to be funded could make it easy for people to pick their card...

Just dreaming here

[GriffGreen]

then to throw something crazy into the Mix... ERC Triple 8!
ethereum/EIPs#888

what yalda said here might be interesting for us as well:

[kingflurkel]

@GriffGreen ERC888 seems the way to go! Although in a first iteration I would like to keep this as simple as possible and only prove our first point; can we create a project, add a board to it, fund a card, let a project admin mark the card as "completed", then burn the card token and get project tokens in return.

@GriffGreen 1:1 ETH / Card token; this is a custom "setting" when creating a new project maybe?

@GriffGreen Of course we need liquidpledging! :)

[GriffGreen]

Definitely, we need a PoC then an MVP before we start thinking crazy like... almost everything i put down shouldnt even be in scope till our third iteration of the backend IMHO

[sponnet]

I dream in third iterations all the time.