How to Build a Decentralized Crypto Fund?
Our company has been building a crypto index fund to make basic income universal. The name “Joint Commonwealth Fund” (or JCF) is an indication that it’s a “people’s fund”. For the people, by the people.
The intention was a mechanism that may deal with the upcoming “automation revolution” by AI and robotics, which likely will replace many existing labor-related jobs, even cognitive ones in the near future.
Instead of being “replaced”, why not “leverage” the strengths of automation to build wealth and to re-distribute wealth, so that a community of people may be protected financially at the most basic level?
Although we’ve been excited at JCF’s prospect, we’ve also been concerned about some of its current designs. Namely, that of trust and security, and a though still distant, but fundamentally important one, which is the centralization of its power.
You see, while we’ve set the fund to have a “social purpose”, the fund is still managed centrally by our company. Meaning that key aspects of the funds are still being controlled and overseen by a small number of people.
Of course, this is out of necessity at the moment. By as with any other systems, centralization of power will face scaling issues as it gets big. A centralized design also means that the system has a single point of failure and bottleneck, and a single point of potential corruption.
Facebook is perhaps one recent example. While originally a benign well-intended college project, as it’s grown to cover over 2.3 billions of active users, even its co-founder is now calling Facebook to be broken up.
The reason is simple: Facebook’s founder Mark has too much power. Whether Mark is benign or not, it’s too much power for one person to own or control.
The same goes to our fund: while we’re still small, the first and last question people would ask about a fund is: can it be trusted for our money? is it secured? can its management be trusted for good behaviors on the participants’ behalf?
When all key aspects of a great resource is held on just a few people, or even a single individual, it not only isn’t safe by design, it’s also not scalable, nor sustainable over long-term.
So that brings out the question I’ve been thinking about recently: can we build a “decentralized” fund that does not have a single point of failure, so that it’s relatively safe from catastrophes or ill-intended behaviors of a few individuals?
Most democracies today have been designed with this issue in mind, to avoid the concentration of power, and to ensure that different powers are in check of each other. While not perfect, most people would agree that it’s still more trustworthy than alternative designs.
While I don’t claim that we’ve got a solution yet, it’s a good start to laying out the required pieces of an ideal design. Namely:
1) A decentralized custody of assets
“custody” in the crypto world refers to the holding of various crypto assets such as Bitcoin and Ethereum. Most people are not aware that when you open an account at a crypto exchange and perform trading, you’re essentially giving the private keys to your assets to the exchange.
If the exchange is “hacked”, there’s danger in your assets been stolen and moved out by the hacker. It’s why most experts recommend keeping your crypto assets at your own offline “cold” storage/wallets.
The same is true for any kind of centralized keeper of crypto assets, whether it’s a crypto bank or a crypto fund. When you’re investing, you essentially are trusting that the company can safely keep those assets for you.
But it’s only a matter of time, and how high the “stakes” are, before one serious security incident happen at one of the top crypto exchanges. As when the potential reward is much larger than the risk, someone’s bound to hack/leak important aspects of the system and have it compromised.
So a much safer mechanism by design, is to spread the assets across multiple holders, while still allowing legitimate access and operation of the assets at appropriate times.
2) A “constitution”-like contract for operations
For a crypto fund, the most important operations are:
A) funding
B) withdrawing and
C) re-allocating assets.
While A) and B) can be part of the smart contract, and thus be fairly transparent and decentralized, as C) involves human judgment (or at least supervision, as in our case, where an index algorithm is used for judgement), currently it’s done mostly by some human pushing the button.
However, this makes that “human” as a single point of failure. A better design is that even this “pushing button” is automated, and that it happens at specific, predefined time.
Also, whenever this “constitution” (some smart contract initiated by the fund company) needs to be updated or re-written, it should undergo some kind of general voting, so that no single individual can change the rules of the game alone.
3) Non-reliance on specific exchanges
To perform basic fund operations, you need to buy and sell certain assets to keep the portfolio of assets in line with the fund’s objective.
In our case it’s some holding ratios determined by market cap rules. In other actively managed funds, it could be the holding ratios determined by more sophisticated rules and perhaps by human judgments.
Once the ratios is determined, it’ll potentially involve performing trading at one (or a few) of the exchanges out there, or perhaps via decentralized exchanges (DEX).
The reliance of a single (or a few) exchanges is again a centralized bottleneck: you face a single point of failure, and also the availability/accessibility of the exchange could hinder the fund’s normal operations.
An ideal scenario thus is if somehow most (if not all) exchanges can be used as places to perform asset re-balance. And the fund’s basic mechanism is not rely on any single (or few) predefined exchanges, but by the availability, speed, and cost of doing re-balancing at candidate exchanges.
While the above may sound difficult, there’s already publicly available open source libraries (such as CCXT) that allows the querying and trading at over a hundred exchanges!
The above are some the “solution requirement” to the problem we laid out, and we might need to wait a bit before a solution comes out. Please feel free to share your views/comments, and if you’ve already got pieces of the puzzle solved, we’d be more than happy to hear from you!
