Issues - GenusDev/genie-portal GitHub Wiki

In my mind, the following are considerations that we need to figure out sooner rather than later. Why? Because smart contracts are immutable. Yes, I have designed a system that allows for upgrades, but the process for upgrading requires mass participation on the part of investors and will therefore likely be a drawn out process. Convincing investors that certain solutions are necessary may be more difficult than we can anticipate. This will be especially problematic if investors are reluctant to embrace changes that we are introducing in an effort to comply with evolving legal frameworks. Furthermore, many of the issues here relate to the design of ERC20 tokens, which will not change. The remaining issues here need an initial solution for the first iteration of the contracts, even if we decide to change our approach later.

Upgrading Contracts

Since the contracts are all amenable now, theres obviously the potential for certain groups of voters to usher in contracts that benefit them at the expense of all others involved. While it's true that any upgrade would be built by us and therefore we can simply not create dysfunctional or 'unjust' upgrades, that's not exactly a decentralized solution bc ultimately we are just a company that can be swayed to produce software that benefits the highest bidder. Even if we wouldn't do that, it's not a sustainable system for maintaining the integrity of decentralization because our time at the company and on Earth is finite. Decentralization by definition needs to be built into the architecture of the system to actually work.

If the number of votes an account has depends on how many tokens they own, the rich can potentially disenfranchise everyone else or create contracts that steal everyone else's ether. On the other hand, if voting is one vote per account, then the majority can potentially do the same to the very rich.

I'm thinking a happy medium might be to create a tiered system, where the number of votes one account has maxes out at something like 8x the votes as the account with the least tokens. Under this system, theoretically the majority wouldn't be able to get upgrades passed without some compliance from the most wealthy and vice versa. Every new contract would need support from a mix of wealthy and the regular investors, evading 'class warfare'. However, a user can cheat this system by buying tokens with multiple accounts. To avoid this, there would need to be a more sophisticated way to authenticate users across multiple accounts, which is something that we're going to have to figure out for taxing reasons anyway. Keeping the threshold for passing an upgrade high, say 80% in favor or even higher, could also help.

One obvious safe guard we can put in place would prevent upgrading contracts that hold account balances and distribute funds to accounts. So under the current contract system, ERC20 tokens,Dividends and Reimbursements would all be immutable. However, there are still indirect ways in which dividend or reimbursement distribution might be compromised. For example, a new project factory contract could be created which passes a different dividend address to projects to forward funds to. This new address could connect to a contract which disburses funds in unintended / unjust ways. The same could be done for reimbursements by creating a new crowdsale contract.

External Exchanges

We need to figure out how our token is going to interact with external exchanges. Are we keeping a list of valid exchanges? This needs to be sorted out because our ERC20 token will not change.

Authentication

We need to figure out what information we need to collect about our users initially. The nature of this data will likely change, but we still need to know where this authentication process will fit with respect to the current application. I'm thinking that the buyTokens method will need to have a buffer contract. The buffer contract will authenticate investors, and then hit the crowdsale and buy tokens on its behalf. As legal requirements change, we can upgrade the buffer.

The ethereum community has built several tools for authenticating users based on personal information. They all operate by hashing the information with their keys. Whenever a user wants to do something, they need to re-enter their information. The hash produced by this information is compared to the hash stored in the contract.

The problem with all of these approaches, however, is that they keep all of the user's data encrypted. Consequently, we wont actually be able to access the personal information and let regulators know who our investors are. What we can potentially do is store personal information on the blockchain in private variables that only we can access. Moreover, the content of the information we store about users can change as requirements change. This could be accomplished by storing the information in stringified JSON objects. This way, the quantity and types of data will be unlimited. In order to enforce that users are up to date with the current regulations, we can set a closing date for existing information that gives users time to update their data. However, since data is not typed, users could upload arbitrary strings without any useful information in them.

We can potentially use this data to implement a more democratic voting system, too. We can allow one vote per set of personal information. Obviously this system would still have holes though. Users can just sign up entering slightly different information, like a different address, or just straight up lie about who they are.

Escrow

Legit ICOs do not forward all funds to the developer without the developer proving their legitimacy first. Currently, we are incrementally forwarding funds to developers as new projects deploy. The logic here is that if a developer runs away with the funds without delivering on his promises, people will just stop investing in new projects. However, it is conceivable that a developer can have multiple projects deploy before investors see any return. To limit the degree to which a developer can scam users, perhaps we should require that investors are receiving some return before further projects can be deployed and more funds are sent to the developer.

Another approach would involve forwarding funds to an escrow account that requires that a trusted third party signs off on the funds being forwarded. There are several companies in the ethereum space that offer services like this. Here's one: https://ibcgroup.io/services/ico-escrow/.