Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit transfer of tokens until network has full functionality #841

Open
yourheropaul opened this issue Oct 24, 2018 · 0 comments
Open

Limit transfer of tokens until network has full functionality #841

yourheropaul opened this issue Oct 24, 2018 · 0 comments
Assignees

Comments

@yourheropaul
Copy link
Member

General problem

In the early stages of the kUSD (and possibly other) network(s), token holders are not allowed to sell or otherwise transfer token ownership. This is for legal reasons around securities laws in the US. At some date in the future, they will be allowed to move their tokens as they like.

Considerations

  1. Token transfer must be initially 'locked' at the smart contract level. If a token holders tries to send locked tokens, they must see an appropriate error message, and the transaction should not take place.
  2. There is an exception for mining: token holders are allowed to send tokens to the mining contract as part of the validation subscription and update process. When stopping validating, they must get their tokens back after the freeze as normal.
  3. At some point, the tokens will be unlocked, and transfer will be possible without limitation. Unlocking must be enacted by the network govenors.
  4. Ideally, unlocking would be on a per-account basis. That is, the governors could unlock account A and give its controller free transaction while account B remains locked.

Possible implementation patterns

One possible route is to prevent all transfers, except those to the validator contract addresses necessary of mining. This has the drawback of not allowing for per-account unlocks.

Another avenue is to implement a more complex system of explicit unlocking using some kind og registry. This is a little more complicated and harder to build, but it allows for more flexibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants