I'm new to Ethereum and would like to make a company stock contract. shareholders would vote on company policies dividend can be distributed to shareholders and the shareholders can vote on a stock split or reverse split.

I have been reading all the Ethereum tutorials and can't find out how to get a map of all shareholders with the number of shares they own. When making votes, paying dividend and split/reverse split of stock would need to know the number of shares each shareholder has and for split and reverse split would need to change the number of shares each holder has.

My question is, how can a transaction get a list/map/array of the shareholders and corresponding shares so that it can be read and modified?

2 Answers 2


There is not a standardized solution to contracting securities that can execute the features you described above, yet:

  1. Dividend (Push) Distribution
  2. Stock Split
  3. Reverse Split

There is, however, a standardized contract for basic tokens, which are transferable and are able to give other addresses permission to transfer on the owners behalf. See the ERC20 Standard. You could issue those as proxies for your securities. The ERC20 Token Contract uses a map to keep track of token holders.

In addition to the ERC20 Contract, you could set up another contract (or series of contracts) to give the stockholders voting rights, which would help you determine a Stock Split or a Reverse Split. An example contract to manage stockholder voting can be found at the beginning of the DAO documentation of the Ethereum Website under "The Blockchain Congress: The Code" - see functions newProposal(), vote(), and executeProposal().

The reason the three features above are tricky is because of there is a gas limit to the Ethereum Virtual Machine; only so many computations can be executed per block. If you wanted to push a distribution for dividends, for example, you'd need to run a loop on an array. If you only have 10 stockholders, this would be pretty easy and the number of computations required would be less than the gas limit. But if you get up to, say, 10,000 stockholders, this would likely exceed the gas limit and be inexecutable.

The solution to Dividend Distribution may be to deposit all available dividends into a pool fund. Stockholders wouldn't have their distributions automatically deposited into their account via a push; instead they would be required to pull for their dividends manually. A withdraw() function could be used here.

The Stock Split and Reverse Split would also require computationally demanding loops. But a possible solution could be to use a modified ERC20 Token Contract. The modification could be an additional condition added to transfer() function, which could be named checkForSplitReverseSplit(). This checkForSplitReverseSplit()function might call for a bool somewhere in your blockchain congress that lets the ERC20 Token know the token has been split or reverse split, then change the stockholder's wallet amount accordingly before sending; or deny the transfer but adjust the amount (for user safety).

Additionally, similar to the potential withdraw() solution for the Dividend Distribution, there could be an adjustAmount() function that stockholders could voluntarily call.

  • Do you know if they will be working on any efficient methods to accomplish mass changes to a list of accounts values? Jan 24, 2017 at 14:09
  • Not as an on-chain solution, no I don't believe so/I'm not aware of. An off-chain solution will likely emerge that could watch contract events, such as transfers, and record all transfers to a private database, thus keeping track of all accounts and balances off-chain. If the blockchain congress admins maintain this, they could automate a (loop intensive) script off-chain to interface on-chain, which would ~efficiently call all the withdraw() and adjustAmount() functions one-at-a-time on the stockholders' behalves (note: but at the blockchain congress's expense). Jan 24, 2017 at 17:01

You've discovered the tip of a very big iceberg. I think it's a right of passage to come to grips with everything that isn't present as much as what we have available to work with.

There's nothing SQL-like. To implement that sort of thing, you take ownership of every single byte. That means things like the generalized nosql collections, b-tree system I'm working on have to be coded.

Upgradability is a hidden challenge, because Smart Contracts store data inside compiled contracts. Upgrading the software appears to mean abandoning the accumulated data. There are solutions that take some time to understand. It's very different from server-centric structures.

Looping over storage in Smart Contracts is, IMHO, an anti-pattern. It's seldom, if ever, a good idea to work with more than one record at a time in the contract. You can have privileged users and clients that handle loopy stuff offchain.

There are new and strange structures to learn about so you can make informed decisions about which to use. Contract factories and tokenization, for example.

Given the costs, performance and other factors, one should generally look to onchain storage for the minimal facts that must be true at all times and look into offchain storage for supplementary storage that should be fast and flexible. We get into some architectures that approach things from that perspective.

Having said those things, I would turn your attention to a simple candidate pattern I've used with success. One answer to "Okay, so this is reality, I still need to store some data, so how?"

The pattern uses an iterable mapping. "Iterable" meaning access the data by row number. Mapping meaning random access by primary key in one move. The contract maintains the structure through insert, update and delete operations.

Query multiple smart contracts' public data

Have a look at how the "Hub" in the example maintains a list of created records through the create and delete operations. It's only tracking primary keys, so there's no update operation in the example, but it's a simple matter to extend it laterally.

If you send me a list of a few (few) field attributes for one entity, I'll be happy to crank out an adaptation that might be more immediately cognitively accessible. You'd be able to compile it in the web compiler and play around to see what the operations are doing.

  • I was going to start with using the example they have of a democractic voting system and change the voting math to work based off the number of shares the person had. Then add in all the other stuff like buying, selling, transfer of shares, splits and reverse splits. But the stock part got me stuck as not a single example on the main site shows how to call back all the users that have the tokens. I was thinking I could use the meda currency example to build out the buying, selling and transfer of stocks as its close to what i would need for that part. Jan 24, 2017 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.