Building tools for community managers, a considered approach
The crypto space is in the pursuit of scalable but also mainstream friendly payment capabilities on the blockchain. The name of the game in the race to develop those capabilities is to keep a delicate balance between privacy, security and ease of use. Our goal is to give community managers and community currencies issuers the tools to harvest the power of community currencies on the blockchain and enjoy the benefits of decentralization to launch their enterprises bottom-up.
In order to achieve that goal, The CLN team spent the last six months researching the different blockchain technologies out there, along with developing the DApp and the upcoming product the Inventory manager.
After this research we narrowed down our next steps in to four possible solutions, all with their own pros and cons. We would like to involve you, the community, by gathering your perspective on what would be beneficial now and share your thoughts on where development should go from your perspective. Developers, entrepreneurs or issuers with use cases in mind for community currencies are welcome to asses the possibilities and share your feedback in the form located at the bottom of this post.
A) On chain — simple solution:
The first solution is the easiest one. Keep everything on the main ethereum chain. In this solution, Issuers could issue their coin using the DApp and distribute the tokens to their users as they like using ethereum tools that already exist in the market, like truffle.
How the solution would look:
We can create some SDK that connect to that truffle to help the developers connect to the market making contracts and logic, but that’s basically it.
Pros:
- This is the simplest, and quickest developer tool that we can offer.
- Everything is on-chain so it is the most secure and most decentralized solution.
- Key management is done by third party wallets, like meta-mask, trust or toshi Coinbase.
Cons:
- Everything is on-chain so it is very expensive and not very scalable.
- Adopting barriers is high, since users should know the basics of ethereum, private keys management and gas fees.
B) On chain — complex solution:
Another solution is to create on-chain accounts. Those accounts are smart contracts, allowing users to create a transaction intention and sign it, while someone else is transmitting it and paying for the gas fee. In that case, issuers can pay for their users transactions with CLN or their issued Community Currency while the issuer \ third party backed service will handle the exchanging, paying and transmitting the transaction to the main chain.
What could be in the MVP:
In this solution we can create the smart contract of the accounts and the backend service to transmit and pay for user’s signed transaction intention.
Pros:
- Users don’t need to hold or even understand ethereum.
- Issuers don’t need to hold ether also, only CLN \ their own issued CC.
- Everything is on-chain so it is the secure and decentralized solution.
Cons:
- Everything is on-chain so it is very expensive and not very scalable.
- If the implementation is done correctly, it could even be censorship resistant, but, to transmit a user transaction that the service censored requires the user extra knowledge of ethereum.
C) Off chain — centralized solution
In this solution, user balances and the transaction ledger are managed in a centralized database, while proof of reserve is transmitted to the blockchain in an aggregated way.
This means that the community manager will have tools to manage its users balances in a centralized way and have several ethereum accounts that will represent his funds and his users balances and once a period of time has elapsed, tokens will shift between accounts to represent the accurate state of the community.
What could be in the MVP:
Currently Colu is working in this manner, and in this solution, should we choose to develop it, we propose to give issuers open source tools to mimic this architecture, utilizing tools like the inventory manager for aggregating transactions.
Pros:
- Easy onboarding for community users since there is no private keys involved for users and no fees from users required.
- Battle tested with Colu.
- Fast transaction, scalable.
Cons:
- Centralized. Users need to trust the issuers with their community currencies.
- No transparency.
D) Off chain — decentralized solution (semi-centralized)
The last solution, which is probably the most preferable, is to create an ethereum compatible sidechain specifically to a single community currency. This chain manage the transaction ledger and the users balances along with possibly exchaning the CC’s with CLN’s. Users can always peg in and out of this sidechain to the main ethereum blockchain with their tokens.
Only problem is, unfortunately, that this technology is experimental and in the very early stages of development. There are several solutions that are being built but they are not yet in MVP state. The most promising solution in this space is Plasma and Plasma cash.
Notwithstanding the above, we can still go in that direction and develop a sidechain with Proof of Authority (PoA) 2-way pegged where the community manager is the authority that provides the pegging out to the main network.
What could be in the MVP:
In that case, we will develop tools for setting up this side chain with its corresponding smart contract to manage its bridge in and out of the main chain. An SDK for client side integration will also be built for the users, and of course an explorer tool for transparency.
Pros:
- Semi decentralized, everything is transparent.
- Users don’t have to pay fees.
- Fast and scalable.
- Users could peg out to the main chain.
- A step to fully decentralized community.
Cons:
- Semi centralized: until the Plasma will be released users still have to trust the community managers.
- Users holds the keys, can complex users onboarding.
A, B, C or D?
We have already spoken to many issuers, entrepreneurs & developers, who are looking to access the API & SDK early on this question.
We now have a short form to gather feedback from you, the wider community.
If you would like to provide your input and thoughts around the proposed technical implementations then please do so!
