Discussion: Dividend Standard

[rolandkofler]

A dividend standard (more general: a return on claim standard):

1. Is useful to crypto investment funds, (de-)centralized exchanges, wallets, security token users, tax authorities and token creators.
2. Is limited in a well defined scope, that can be expressed without touching other needed realms like regulations and taxation or bearing incompatibilities with existing standards like ERC20.
3. Is generic enough to comprehend all variants of revenue generating financial instruments possible (not only stock dividends, but REITs, bond interests etc.)

Therefore we believe that there is an opportunity for an Ethereum Request for Comment (ERC) targeting dividend disbursement, that can become a de facto standard in the spirit of the famous ERC20. It’s time to build a community around this endeavor.

A more in depth problem domain analysis can be found here:
https://docs.google.com/document/d/1ERjxWZbsGXp4J6ZKotyoniTlLNjaZO4JSwg66UHc-p0/edit

[clemlak]

I've been exploring a similar idea for the past weeks so I think it can be interesting to share my thoughts here!

First I feel like the concept of a dividend standard could easily become a new alternative way to raise funds in the crypto-world. In some cases, ICOs are not the most adapted way to go and this could be a solution to avoid "useless / non-pertinent" tokens. This concept could allow companies to raise funds by providing an "asset" really related to their activity. For example, we can easily imagine an exchange or a marketplace raising funds selling "assets", collecting fees during its activity and then giving back X % of all fees as dividends to the owners of the assets.
Also even if my first thought was more related to companies, as you mentioned there could be a lot of different applicable fields with a generic standard.

About the standard itself, I've been thinking about a "Dividend distribution contract", more or less in the spirit of the ERC20. The goal of this contract would be to define what are the assets, how many of them exist, who owns them, etc... almost like a classic token.
However, this contract would be different on some points:

• There will be no decimals (having 0.03 of an asset doesn't make sense)
• The contract may receive funds, and then distribute them to the owners of the assets (or allow them to withdraw their dividends)
• The contract will need to have a specific "timeframe" for the payouts
• Possibility to create different types of assets within the same contract: asset X will receive more dividends then asset Y (I'm not sure about this one)

[OFRBG]

This could be useful for scheduling the payouts: #1339.

[adamdossa]

Some thoughts on this:

• how to deal with pooled wallets / custodial wallets - i.e. single addresses that hold an aggregate token balance with several beneficial owners. Should the pooled wallet receive the aggregate dividend for all of its beneficiaries and then be at their discretion as to whether they pass this on, or should we define a standard around beneficial ownership to facilitate this automatically.

• as a base for dividends you need some way to consistently determine token balances as of a particular point in time. There are a few different implementations of this, including MiniMe, OZ checkpoints, NeuFunds checkpoints and Polymath checkpoints - standardising this may be a useful sub-project.

• when we've talked with issuers about dividends, the following topics also come up:

  • withholding tax (i.e. withholding some portion of the dividend for certain classes of investors)
  • excluding certain addresses from the dividend calculation (this was needed partly as a workaround for the pooled wallet issue above and to make sure that dividends aren't paid out to contracts from which they are then unreachable).

[jo-tud]

A dividend standard (more general: a return on claim standard):

This is a great discussion which adds great points to the work we've done. I think the problem should be approached as general as possible - avoiding the term dividends.
I just proposed a standard for a claims token and would love to discuss it:
#1843

[Roger-Wu]

This is another related interface standard and implementation for a dividend-paying ERC20 token.
ERC-1726: Dividend-Paying Token Standard #1726

Let's have a discussion and try to reach a consensus!

[jo-tud]

I'm not in favor of using the term "dividend". Dividends are a very loaded term with various meanings in finance. Something more neutral, like our "ClaimsToken", or even "ReturnOnClaimsToken" or "PaymentDistribtionToken" would be better.

As @rolandkofler put it, a dividend standard would just be a specialization of a return on claim standard.

"A dividend standard (more general: a return on claim standard)"

[jo-tud]

@adamdossa

• as a base for dividends you need some way to consistently determine token balances as of a particular point in time

If I understand your point correctly, this should be taken care of in @Roger-Wu 's implementation and ours (#1843). The DividendPayingToken does this by keeping a dividend per share variable, which is adjusted at deposit & transfer time, ClaimsToken keeps account of processed and claimed funds and adjusts at transfer & withdrawal time.

[mswezey23]

@jo-tud

• as a base for dividends you need some way to consistently determine token balances as of a particular point in time

If I understand your point correctly, this should be taken care of in @Roger-Wu 's implementation and ours (#1843). The DividendPayingToken does this by keeping a dividend per share variable, which is adjusted at deposit & transfer time, ClaimsToken keeps account of processed and claimed funds and adjusts at transfer & withdrawal time.

I looked over the code in #1843. I did not see where it was tracking a historical balance for balance_A .

For reference, looks at OZ's ERC20Snapshot contract here: https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/drafts/ERC20Snapshot.sol

Feel free to point me in the right direction if I overlooked a piece of code.

[jo-tud]

I looked over the code in #1843. I did not see where it was tracking a historical balance for balance_A .

Well, to be efficient, historical balances are not tracked directly in the ClaimsToken. Instead, there are two additional mappings per token holder, that track the processed and claimed funds. They make some accounting at every transfer and payout - but only for the active account. With this mechanism it is possible to distribute payments at exactly the token distribution at the time of payment, without going through all accounts and without tracking all balance changes explicitly.

Here's a very good explanation of the principle by @Arachnid: https://medium.com/@weka/dividend-bearing-tokens-on-ethereum-42d01c710657
#1726 takes this approach. #1843 is a bit different (see my previous comment) but avoids checkpoints in a similar manner.
These approaches scale very well to large numbers of token holders and payments.

Does that cover what you meant in you original point about dividend distribution for historic balances?

[mswezey23]

Quick reply! Thanks, I'll respond here versus editing my previous comment.

I see now, after a closer inspection. The code is updating during transfer & transferFrom function calls. As you stated above. And following the table of events, I see how it keeps track, over time, of available funds for withdrawal. Very cool approach!

I will further digest the code and mull it over.

Besides from a pure technological problem you're solving, have you any insight on how this standard can meet current legal regulations? (pending on your location, of course)

[jo-tud]

Besides from a pure technological problem you're solving, have you any insight on how this standard can meet current legal regulations? (pending on your location, of course)

I don't think this should be part of the standard. It should be simple and modular to be integrated with compliance frameworks like #1400 . The ClaimsToken aims to do that.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.