This is a ‘working’ paper and will change over time. It is a thought experiment on paper.
The numbers used have been used for demonstration purposes, there is a lot more thought to be put into it.
The intellectual property in this paper belongs to e_labs
TL;DR
A web3 native, decentralised and community lead communications and organisation system. The web3 ecosystem is expanding, with more users onboarding not only into the technology of web3 but the ethos and need for decentralisation, permission-less and trust-less systems. Though so many of the services that communities in the space use are centralised and not optimised for web3.
CONVO will fill that hole. Combining the best features plus more, DAO and web3-centric tools, it will create a central place for decentralised communities to socialise, organise, govern and prosper. Built to be decentralised, a protocol built on top of current proven and trust trusted technology. To create a safe, secure and resistant protocol we will build a network of nodes that host and maintain the service.
Using a well defined system to incentivise but also secure the network much like a PoS system it will allow anyone to host servers while getting rewarded for keeping it alive and safe. Using a staking and fee/rewards incentivisation system to encourage hosts and maintain a security level.
This paper looks at the theory behind how to build a protocol like this, the structure of the network and how users participate. It also looks at possible tokenomics, how to secure and incentives the network and finally the tools and value it would bring to the ecosystem.
Most people in the space understand the benefits of taking a product like this into the decentralised and distributed world. This paper looks more at the how over the why, as the why is kinda obvious.
Introduction
The web3 ecosystem is built on a decentralised and self-sovereign community that by default is split by geographic location, time zones and even access to tech. This brings the need for tools and applications that bridge not only the physical distance but provides the methods to collaborate, build and socialise. Right now the most popular service for this is Discord and Twitter as a more public forum, but other options are used, ie, Mastodon, Guilded and Slack.
These products provide a space for individuals and communities of all sizes to congregate, using text and voice-based messaging systems, file sharing and programmable tools. With third-party bots/plug-ins, the amount of tools available to the servers is quite large, though there is a distinct lack of web3 native integrations and interactions and security. Features that would enhance and streamline communities, tools for DAO’s and make use of native web3 authentication and decentralised social graphs.
To achieve a platform in this style we need to build a protocol that can be deployed and hosted by anyone, it's secured and incentivised onChain but utilises already proven and trust external services and technologies. This will include creating a tokenomics system that allows us to create a security layer, an incentivisation layer and a governance layer and an operational layer.
Theory
A multi-tooled decentralised communication platform isn’t as easy as it sounds, though there are already a range of proven and trusted systems that can be implemented to help create and support such a protocol. When we first think about decentralised systems we think of a raspberry pi sitting in the corner of a bedroom running an old open-source program. Ideally, we don’t want to go too far from that vision.
How can this work? Well, it's (not so) simple. The first step will be to design and build the CONVO backend system, the operating system and the network itself. Think very much like a Bitcoin or Ethereum full node and validators, the node will host the backend server and systems that allow CONVO to run the network. For node-based networks to be successful you normally need a large number of node hosts, the aim behind CONVO’s network will be to reduce that reliance by utilising other secure and active services.
Distribution
To create a modular, scalable and resistant system we can define a couple of node types.
Full Node | The full node will be the backbone of the protocol. They are the keepers of data and storage. These nodes will store the full historical state of CONVO as well as execute protocol-wide operations. |
Channel Node | A Channel node runs individual channel operations. They update to the full nodes on the channel's set interval. They run channel-specific programs and instant messaging. They hold up to [72 hours] of data. |
Gate Keeper | A Gate Keeper is the router of the network. Connecting all of the full & channel nodes, verifying users and clients and maintaining a resistant and scalable service. |
The idea behind building a multi-layer of nodes is to create a scalable and resistant network but also modular and accessible to a range of users and hosts. Creating smaller barriers to entry to run or host a server/node increases not only the security but participation. The security level will come in the form of a staking and rewards system. Lower levels of the network will have a smaller staking requirement than higher-level nodes.
_ Full Nodes
The full nodes will work much like an Ethereum full node. There only needs to be 1 full node active for the service to run. They will be the most storage-intensive and designed to be running on a dedicated server or dedicated personal tower.
Their main job will be to store all of the historical protocol data, provide an execution layer for protocol-wide operations, provide an entry point to the service and verify each incoming state update. The node which verifies and confirms the update first gets rewarded for doing so. This Intel aggregates all of the channel nodes’ data, confirming there aren’t any bad actors, and saving and hashing the data.
The full node is supposed to be the most critical part of the network. If a full node goes offline for more than n minutes, without declaring maintenance time prior, it incurs a slashing event. There could then be an operator's governance system to reset the slashing strike upon reason delivered and a vote cast.
_Channel Nodes
Channel nodes contain very recent and real-time messaging data, with fast communication and verifying channel data between themselves. It hosts the channel execution layer, supporting all of the tools and products that the channel implements. At set intervals, set by the channel controller, it is passed on to the Full Nodes to be hashed and back stored. The channel nodes are what clients use for real-time communication & operation.
Any time a channel node comes online it will sync with the full node network to bring its state up-to-date. The channel node will be designed to run on a small server or raspberry pi with attached storage. They will need a fair amount of storage but a fraction of a full node.
_Gatekeeper
Then we have the Gate Keepers. These are the lightest nodes on the network and could be built into the CONVO client. They keep track of all of the full nodes that are online and pair the channel servers to the full nodes and the user's clients. They act as a CDN or ISP - connecting the peer-to-peer network in the most efficient way.
The Data Cycle
The data path of the network is very important and will add towards the security and decentralisation of the protocol. Full nodes hold the historical state and tool set states, and channel nodes hold the most recent data and process the communications. Gatekeepers create a distributed way to access the protocol.
Arguably the work horse of the network will be the channel node. They will be processing the live data transactions for each channel. The more active a channel is, the harder the channel nodes will have to work. Splitting each channel into their own nodes allows for a couple of things; A) it's a smaller and easier node to run, becoming accessible to more people to run. B) this will increase the security, decentralisation and redundancy of the protocol.
At a set interval the channel nodes update their state to the full node network. This interval is set by the channel host, the more often the more immutable the channel i.e. if the interval is set to 1 week, and within that week, if all of the channels nodes go offline, the channel would have lost any data between the last update to when the node went offline.
Account Types
Channel Hosts
Each channel needs a controller, the person that created the channel, we call them the channel host. The host is the overall admin of the channel, with the ability to delegate and distribute roles, actions and responsibilities. There will be the option for this to be a governance system, controlled by the channel users, built into the service.
Channel hosts don’t have to run any nodes or have maximum uptime. They will just use a normal client, but will be advised to run a channel node to ensure access of their channel. To create a channel there will be a cost involved and an ongoing service fee that incentives all other participants in the network.
They will need to maintain the balance of the channel in-order for it to keep running and covering the service charge. When setting up the account, a couple of things are included;
1) A pool of CONVO to cover X amount of channel up-time.
2) A channel node key, allowing for an already staked node to be turned on and allow them to start using the channel. - If a channel host is slashed, the channel will stay online as-long as there are other channel servers online.
The channel host will be able to configure the channel, this will include turning tools and products on and off. Each product they turn on will have an associated price to it. They can create the architecture of the channel and migrate control over to the channel DAO. A channel host will be able to download their channels full - or part of - historical data.
Operators
Operators run nodes and gateways. A single operator can run multiple nodes and gateways. But has to maintain the upkeep of these nodes, if a single node in the operators account is slashed, all of the nodes under the operators can be slashed.
When an operator registers a new node service, once they stake the fee and configure, they will be provided with their node key (full key, channel key, gate key), this is used to activate the physical node and links it back to the operator.
Rewards and fee’s will be made to an escrow wallet attached to the operators account. The operator will be able to withdraw from this wallet at any point it has funds init. Allowing for a daily withdrawal.
Users
All users will have a proof-of-registered soul-bound NFT. When a user first sign’s up and goes though the required security process, they are minted a personal token. The token can be transferred to another wallet, but the user must go though a transfer process, its not as easy as just transferring the NFT. We do this because the NFT will be the key to the users profile and allowing users to share accounts easily will compromise the service.
Each channel that a user joins will mint an access token for that channel. These are attached to the profile NFT, so if the profile is transferred, so will all the channel access. It will be down to each channel if they charge for access. They can put a cost on the mint, allow a free mint or even cover the gas costs of the mint too.
We can offload some of this to a decentralised social graph like Lens Protocol, or allowing integration. Helping build the interconnected web3 and let users carry their personal data and settings between products & platforms.
Users will also be able to download all of their data from any channels they are apart of. Allowing users to self-backup.
The Protocol
Stepping back and looking at the protocol as a whole and what it needs, we know that there are specific architecture services that we need to build into it. These come in the rage of;
Chat Server | Fast chat service allowing the transportation of text across clients |
P2P File Share | To allow for file sharing directly between users but also between nodes & channel nodes |
Distributed Storage | Highly secure raid system to store data across the node network |
Video & Audio Services | Allowing for voice and video chat rooms |
Blockchain connectivity | Allowing for direct interaction with onChain apps & contracts and for chain native functions. |
Web2 API servers | Allow CONVO to interconnect with web2 products like twitter |
Custom Databases | Distributed databases that can scale and be structured for any need |
Backend Servers | Decentralised systems to run channel plugins and network operating services. |
Encryption | Simple, secure and customisable encryption system for channel, P2P and protocol critical services |
Account System | Account system, for users to stay decentralised and have a huge amount of customisation |
Technology
Thankfully we are at a point in the evolution of the web3 space that there are already some incredible solution for these needs. Utilising these pre-existing technology's and products not only reduces development time but also includes CONVO within their ecosystems security and already found trust. What might these integrations look like?
Chat Server | ㅤ |
Distributed Storage | We can utilise the IPFS service to host static data storage. Only needing to save the file hash in the CONVO network reduces protocol-level storage needs. This can be opened up to utilise other emerging technology like Cudos. |
Video & Audio Services | There are open-source P2P streaming codecs and protocols that allow for distributed V&A communication. the webM codec from Google is a great start. |
Blockchain connectivity | Blockchain RPC endpoints are normally provided by centralised parties. We need to have a wide range of chain endpoints to cover the whole ecosystem. Can these be built into the network? |
Custom Databases | ㅤ |
Backend Servers | There are a few prominent decentralised BaaS products available, the two biggest are ICP (Internet Computer Protocol) and the CUDOS network. Both allow users to rent computing in decentralised manner. |
Encryption | With the upcoming zkRoll ups that are starting to go into public use, we can start to utilise onChain proofs, confirming sensitive data without needing to reveal it. This will increase the security level that can be placed on certain data and features. |
Account System | We may need to implement a couple of account system options. We want to stay decentralised but also want to give different user skill levels easy access. We can utilise a decentralised social graph system like Lens for users to build their profile on top off, but also should offer a simpler way of account management for newer or less technical users to get going quickly. |
More so, building tools that create easy-to-deploy full, channel and gateway nodes on to decentralised computing systems instantly bolsters the network. An operator could run their node at home or on a centralised computing service, if there are 100 across 50 different services, that creates decentralisation. But if we can encourage, and create a low barrier for, operators to deploy their nodes onto decentralised computing systems the network’s security and redundancy is increase by magnitudes.
Tokenomics
There are a few thoughts behind the tokenomics for the protocol and a lot more thought to be put into the subject. First of all why do we need tokenomics? The most important answer is security. We need to secure the protocol so that bad actors can’t maliciously access or modify data and services. This is best witnessed in the Ethereun 2.0 staking system. It uses the value of ETH to secure the validators, if they act badly they are punished in the form of a monetary penalty and network access - we need to employ this level of self-security in CONVO.
Here we face a second big question… to token or not to token. Creating a native protocol token brings its advantages and disadvantages, but what would be the alternative? Well… using the host chain’s native token, this would bring an answer to the downsides of the creating our own, namely; using the already defined security of the networks currency, less liquidity issues and less likely of a run on the token. But it also brings downsides, of witch a-lot are fixed with a ERC20 style native protocol token.
These are; less capital to stock operational tokens, easier programmable manipulation (an ERC20 is more malleable in code than a chain native token). We will, however, need to bootstrap a trading pool and be at the mercy of trading bots, the first 24 hours of a new token can be vital and hectic. How do we mitigate over trading and speculation of the token?
We need to have well thought out and defined tokenomics that carefully release liquidity as the protocol grows. A another positive aspect will be that the token is an actual utility token, it will be used to secure CONVO, but more importantly be used to pay for services and maintaining channels.
Keeping the total possible supply relatively low, way below 1billion, with a defined release schedule. It would be interesting to look at an elastic supply. When new nodes and servers come online they are created with newly minted tokens, with a minimal up-time requirement. When bad actors are punished the tokens are burned and removed from circulation.
Possible release schedule
- 100,000,000 target total supply.
-
Receiver | Amount | Vesting | % of Supply |
CONVO Studio | 10,000,000 | 2/3 yes
1/3 no (Market Making & incentives) | 10% |
Crowd Sale | 10,000,000 | No | 10% |
Protocol Incentives | 10,000,000 | 4 year program | 10% |
Liquidity Pool | 10,000,000 | ㅤ | 10% |
Investors | 10,000,000 | yes | 10% |
Full Node Register | 50,000 * nFNodes | 3 months | ^20% |
Channel Host Register | 100*nChannels | 3 months | ^15% |
Channel Node | 1000*nCNodes | 1.5 months | ^10% |
Gateway | 250*nGateways | 1.5 months | ^5% |
* CONVO studio would be the development and corporate management team/company. We want to decentralise governance but feel that a (de)central entity tasked for the maintenance and development would be most efficient for the protocol.
note: When an operator is setting up a new node they can ether stake CONVO they already have or pay for it via another currency. The protocol will then ether mint new CONVO if the minting allowance for that node type has space, or buys it from the open market. With the mandatory locking period when setting up the nodes it will deter bad actors from spinning up nodes to increase the supply and sell quick.
The ecosystem will rely on the operators to sell their CONVO into the open market, allowing channels to buy it to fund their service.
Security
Keeping a network secure is arguably the most important aspect of the protocol. It is relied upon by so many other parts of the ecosystem, there's no point in having 100 great tools if it’s dangerous or never up. But it can be hard to regulate a decentralised network. This is where staking has become a great tool to manage, reward and punish participants.
We will lean heavily on this proven method. Each level of the node will require the user to stake a number of the protocol's token in order to start operating. Depending on the level of node you are running will determine how much is required to stake. If any particular node is caught acting bad, trying to change data or post incorrect data, routing to a non-registered node or other malicious actions, it will have its staking slashed. This will take the node offline, requiring the operator to deposit more funds to the node.
A nodes rewards aren’t added to the node wallet, so slashing will still require a node to transfer and stake the new funds to bring it back online.
After each slashing the punishment will increase for said node (operator) until it has used up its strikes and will be fully liquidated.
Service | Stake Fee | Slash 1 | Slash 2 | Slash 3 | Slash 4 |
Gateway | [250] CONVO | 15% Node | 25% Node | 30% Operator | 50% Operator & 100% Node |
Channel Node | [1000] CONVO | 20% Node | 40% Node | 30% Operator | 60% Operator & 100% Node |
Full Node | [50,000] CONVO | 25% Node | 25% Operator | 50% Operator & 100% Node | ㅤ |
Data will be secured in three places. First of all the channel nodes will validate the data between them selfs. If a channels 3 out of 4 nodes decide that 1 of the nodes is providing invalid data then they can trigger a slashing event on the bad acting channel node. So each channel regulates its self.
On the gatekeeper level, at set intervals all of the keepers will sync and confirm each others connections. If a gatekeeper is found to be providing bad routs to clients the other gatekeepers will trigger a slashing event.
Then at the full node level, full nodes can trigger slashing events for all three node types. They will hold a continued record of routs and endpoints, meaning on state updates they will see if a gatekeeper is acting bad. Also on the state update while they are verifying the channel data they can determine if a channel node is submitting bad data and trigger an event.
Full nodes also govern each other. Part of the state update verification involves each full node to verify the channel data, and then confirm that verification between the other full nodes. Here the full nodes can see if one of the others is trying to submit bad data and trigger a slashing event.
incentivisations
Keeping the protocol running will require a range of people being hosts. Operating and maintaining the node will cost, wether it is for electricity to run a channel node at home or space in a decentralised storage system for a full node. We need to make sure that the operators are rewarded for participating and maintaining the network.
These incentivisations will mostly come from fees generated from channels, but there will also be a protocol funded incentivisation program to encourage operators to join the network. This will be a decreasing allocation over-time, supposedly as the operators & channels grow. They will support all three node types. We can also incentivise people to register channels, giving away incentives that cover joining fee or on-protocol credit.
Protocol fees will be a moving amount, depending on the activity on channels, and will be defined by a range of metrics; ow much data the channel is storing, how many connections the channel is making and then any bolt on product fees. Below is a basic version of what this could look like. We also need to remember that the cost of CONVO will also be a variable, so that means that the algorithms variable will also change to represent the actual cost.
(Costs are for example)
- StateUpdate (SU) : Based on the basic cost of updating a full node state | 0.5CONVO
- DataStorage (DS) : How much data is being stored on the full node | 0.01CONVO/GB
- BoltOn (BO) : Dependent on the fees of the product + network usage | ~CONVO
- BoltOn Service (sBO) : Network processing fee for using the product | 0.15CONVO
The more often a channel is updated to the full node state the more ofter they will need to pay the StateUpdate fee, though this regularity brings security.
So then we have to work out how the supporting nodes are rewarded from that fee. Below is a chart showing the potential fee distribution. Allotting funds to the channel node, full nodes, gatekeepers, protocol and products. The fees are automatically distributed once a day.
Each node group has its own way of splitting the fees it receives. Each node will acquire shares according to the groups metrics;
- Channel Node
Uptime + connections made + channel incentive(if active)
- Gatekeeper
Uptime + proportion of connections made
- Full Node
Share of network + Bonus (Daily fee trigger, first to confirm State Update)
Uptime is a big player in the rewards process, we want nodes to be on, constantly, this allows for a more robust protocol. For full nodes, its a slash-able offence to go offline with out declaring maintenance time prior. There should be n shares awarded for each [minute] any given node is online in the period.
We then can look at thought-put, witch node has worked the hardest. For channel nodes, even though each node gets updated as soon as the first one received the data, the channel nodes witch are mostly used (assigned via gatekeeper*) will do more legwork, especially when tool products are being used.
* The gatekeepers assign a client to the most reliable, quickest and in turn normally closest channel node. Though it will aggregate when getting busy. This does mean certain nodes will see more ‘first’ usage.
There will also be bonuses to reward nodes for securing the network. Mostly full nodes will be able to access two bonuses.
1) For triggering the daily fee distribution. It will be triggered on the closest state-update to the timeframe.
2) For being the first node to verify and confirm all the channel nodes data and store it, creating a confirmation for the other nodes to process.
Channel nodes can also gain a bonus, this is set by the channel host and is optional. They can decide if they want to reward/incentivise their channels nodes.
Protocol Incentives
To encourage operators to start supporting the network we will have a protocol sponsored program rewarding node for participation. Much like a standard liquidity incentive in DeFi, each day a set amount of CONVO will be put into the fees pool to fill in for low initial traffic and try and build users. This program will slowly reduce overtime to zero and will be included in the final pool that nodes draw their shares from.
Product Features
To start we should take Discord as a template product. It is well designed and is proven to be useful efficient. The same features that do this for Discord are the starting blocks for CONVO. Manageable chat rooms, implementing text, images, graphical communication and voice. But these are the bottom level building blocks witch will make the protocol.
So what other features and tools should CONVO build to help strengthen DAO and decentralised communities? These can be broken down into a selection of categories to help understand why and who they are made.
Open Public Social’s
Alongside channel-based communities, the overall protocol will act as an open social network. Implementing current and in-development account abstraction systems and portable social graphs, it can host and combine a range of social network-style applications including a decentralised ‘twitter’ system hosted across the Full Nodes.
Every Day Tools
To create a truly harmonious space to collaborate and work we should be providing the tools and apps that we use every day, into this safe, decentralised and single place. These tools might be things like a version of Google Docs/Sheets/Slides, allowing teams to work remotely in realtime. We can include a decentralised file storage system, or allow users to connect to an already proven service. We can host blockchain RPC end points for channels to make use of.
Product Switch
A built in dashboard that allows channel hosts and admins too easily visualise the tools & products available to their channel. They can switch these products on and off in real time and have a clear and prominent overview, in realtime, of the fee’s and costs of these products and the channel.
3rd Party Plugins
Develop a safe and governed process for developers to implement products within the network. This could expand to be a ‘plugin’ marketplace. It does need a lot of thought on how to secure this process, making sure that bad code can not make it onto the network. A process close to Ethereums EIP process, forcing open auditing and ridicule and proving on test networks.
Self-sovereign Account
CONVO needs to stay true to the ethos and values of the web3 space, user accounts is one of the most important, but also difficult, aspects to action this. We need to design a mechanism that can stand on its own or use other proven decentralised account and social graph systems. On a stand along system this could look like profile NFTs for each user with access tokens for channels, all stored on the protocols native chain. On a third party level Lens protocol has proven the decentralised social graph and self-sovereign data is possible and is happening.
Web3 Native
To be a web3 native product we need to support web3 from the ground up. Allowing wallet connections for account creation and maintenance. This can be a user connecting their wallet to sign in, prove ownership or to use external decentralised social graphs, like lens protocol.
With the underlining execution layer more complex tools can be built. These can include integrating already active products like Dex’s, in-app minting, in-app portfolio tracking and management.
DAO Native Tools
The existence and growth of DAOs is an awesome thing. Filling the spots where a standard corporation is a dodecahedron peg in a traipse whole. Unlike a traditional corporation there is not a whole industry of tools and utilities to increase efficiency and reduce mundane tasks.
The way in witch DAOs are conducted is still very inefficient and split across a plethora of tools. Creating a centre to conduct DAO business, from community chats, proposal & voting systems though to sub-DAO governance, distribution and organisation.
This can be achieved in a couple of ways. Providing custom-made tools that look after each of these specifications but also opening the platform to 3rd-party plugins, allowing popular products to be used in the environment. These tools can range from on and off chain proposal and voting mechanisms, group documents and editing, wiki pages, automation of new users and treasury tracking… to name a few.
Containing all of these features into a single location will drastically increase efficiency and collaboration, but also reduces barriers to usage for new users, no need to move around 5 different websites or products to achieve what we can in a single tab.
Yet keeping data away from centralised computing mammoths and putting it into the hands of the users.
Traditional Social integration
There are already a huge amount of products for communities and individuals, possibly the most important being Twitter, but lately, more decentralised social graph systems have popped up, i.e. Lens Protocol. We think that the web3 way of life should be inclusive and efficient. Creating a customisable home timeline for users
Distributed Channel Servers
Creating an incentivised aggregator for channel servers will allow new channels to hire server space from operators. The operators provide a channel node for that channel for an extra fee on top of the standard service fee.