Smart contract for company stock

Question

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?

Answer 1

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.

Answer 2

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.