Dividend/Profit payouts for ICOs (and other share holder societies)

CORI the ERC20 Token behind Corrently

During the last weeks, we from STROMDAO moved parts of our business from a domain-specific blockchain for energy to the public Ethereum Homestead chain. The main reason for this major change in our architecture are some specifics of our product that makes ownership of digital assets the main differentiator in our market space.

So what is Corrently? (and what is CORI?)

Corrently is a bonus programme for our electricity tariffs, that allows customers to do micro invests into generation facilities (mainly photovoltaics and wind). Of course, those micro invests have some revenue, that wants to be shared. For customers, this is simple as they get their energy bills deducted automatically. But what about other people that hold shares? We are using an ERC20 Token called CORI (Corrently Invest Token) to cover share distribution.

As soon as the sun shines we run into to the challenge that we have to distribute profits. That was no real issue by the time we were using a domain-specific blockchain, as this chain had a proof of authority consensus mechanism. Now in Ethereums main blockchain with a proof of work consensus mechanism, distributing nano-payments to micro-investments is not efficient. Every transaction costs a small networking fee called “gas”. Ironically we would receive a gas bill for trying to reduce customers electricity bill.

Seeking for best practices

Naive that I was, I thought with all those ICOs there should be an efficient way to distribute revenue to shareholders. Having read a few dozens of whitepapers I learned that dividends payment or any other sort of paybacks tend to be described a bit “wakey”.

I wonder that I never read something like “Give us your money — we might think about how you get it back… if we find some time… maybe…” — It seems crazy to me that people invest into a project without a clear way on how to get a profit of it. I would not call that investment — I would call this donation.

Getting to code

Real value was a post by Nick Johnson on “Dividend-bearing tokens on Ethereum”. Nick describes in his post, how you change the way you think about payouts. Naturally, you would think that first, you have something to share and in consequence, you directly distribute in (sub) transactions. The problem would be, that you would have to pay for all the gas.

Some of the whitepapers of ICOs describe actually this. Every time dividends should be paid they want to deploy a new smart contract with a table on who is getting what. This saves some gas for them — but what if their servers die?

Efficient Dividend Sharing

Comming from Nick’s code we came up with the proposal to have a smart contract that generally allows receiving Ether. In our particular case, asset owners will transfer the revenue from their generation facility to the address of the smart contract.

function () public payable {
if(msg.value<1) revert(); //revert if no ether is send
if(totalDividend+msg.value<totalDividend) revert();
if(token.totalSupply()+totalSupply<totalSupply) revert();
totalDividend+=msg.value;
totalSupply+=token.totalSupply();
divMultiplier=totalDividend/totalSupply;
emit Dividend(msg.value);
}

There are some fields our smart contract requires:

uint public totalDividend = 0; // all Ethers received by contract
uint public totalSupply = 0; // sum of totalSupply of original Tkn uint public divMultiplier =0; // the famous divMultiplier from Nick

As soon as our profit sharing contract receives Ether, we check the bound token contract on its totalSupply. Than we increase two fields (totalSupply and totalDividend). Finally we calculate divMultiplier.

Actual Shareholders payment

Holders of our ERC20 token need to do a transaction on a withdraw function. This needs to ensure that they are only able to receive Ethers they are entitled to.

function withdrawDividend() payable public {
uint due=(token.balanceOf(msg.sender)*divMultiplier)claimed[msg.sender];
if(due+claimed[msg.sender]<claimed[msg.sender]) revert();
claimed[msg.sender]+=due;
totalClaimed+=due;
msg.sender.transfer(due);
emit Payed(msg.sender,due);
}

You could even remove the totalClaimed field as it provides no functional value to this smart contract.

CORI — Bringing it all together

As mentioned during the introduction, we had to solve a problem we already had solved in a different blockchain. So for the CORI Token as it is deployed on 0x725b190bc077ffde17cf549aa8ba25e298550b18 we will use one instance of a profit-sharing contract per provider.

You could see the full source code from our PoC deployment at:
0xa050b90B0C60900E304774Eb39220dFB2C5fFf0F

(don’t hesitate to send some WEI to this address… our customers will thank you)