How to Build Your Own SCP App: Domain-oriented PoS Design — Token DAO
In our last blog post, we introduced a domain-oriented PoS design. We foresee that in the rising era of WEB3, developers will not be limited to traditional Layer1 blockchain and EVMs. Still, there will be more paradigms to build WEB3 applications.
SCP is a smart choice for WEB3 development architecture designs, allowing developers to focus on domain-oriented PoS designs. This article will provide an in-depth example of domain-oriented PoS and explain how to solve the trust problem through domain-oriented PoS, and create a trustless DAO for collaboration between users through PoS.
Token security is an oft-criticized topic in blockchain security. On blockchains, anyone can issue tokens, and the quality of these tokens varies. There are even hackers who maliciously issue tokens that can only be bought but not sold to scam users. In the blockchain industry, smart contracts are the law. Still, the terms of these contracts can only be identified by professional technical experts. It is difficult for users to distinguish between valid and secure tokens and malicious tokens in hundreds of lines of code.
imToken has created a token profile, where token projects submit token information themselves on GitHub. Those submissions will be reviewed by an authority (imToken) before being displayed in the imToken wallet. If there is a malicious token, it is usually fed back to the authority by the user and re-audited by the authority, which is a long and troublesome process.
everFinance has encountered malicious tokens EVER. The lengthy auditing process, which requires interfacing with various agencies and media, has dramatically delayed the flagging and publicizing of the malicious token. So, do we have a decentralized and more efficient token identification mechanism? And make the process of labeling tokens transparent and trustworthy, accurate, and fast through financial incentives?
Common Auditing Process
The typical approach of token security relies on a centralized authority for auditing. The risk control mechanism for tokens is summarized in the flow shown below:
In the above figure, the token issuer or user submits token information. The status of the token audition is yellow. The authority will audit the token information and mark the tokens as green for security tokens and red for risky tokens. If the authority audits the token incorrectly, auditing is started over, and the token status is re-labeled after re-auditing.
In the traditional security world, this process is repeated by an authority every time a new token is created. The user of the token information needs to trust the authority and wait for the authority’s re-audit when the token information is faulty.
At the same time, the security of the token is repeatedly audited by different authorities, and absolute trust is not always reached for other authorities. We can see that security-related information is produced in a disparate and untrustworthy information network and managed independently by different authorities.
There are two crucial problems with the existing mechanism:
- The applications completely trust and rely on the authorities. There is a massive single point of risk for the token information.
- Security information is scattered among different authorities. There is a huge trust gap between authorities, with a time-consuming information-sharing process.
Authorities and Trust Gap
Trusting authorities generates a huge single point of risk. It is why many apps build their own security risk control systems. Single point of risk may lead to untimely token information updates or even wrong token information. When the business pays much attention to security, the application provider needs to conduct a repeated review of the content in addition to the authority, which reduces the efficiency but also increases the cost of sharing security information.
Due to trust issues, the security of the token is not quickly agreed upon among organizations. When a risky token is labeled, repeated audits and lengthy verification processes are often required between authorities before the final token security information can be updated.
Altcoin, Big Risk
For some small-cap altcoins, due to the high audit cost, will lead to the fact that no authority verifies them. The authority will be alerted only when the altcoins lead to significant financial problems. Such security information lag commonly happens.
Using DAO to Govern Security
The Storage-based Consensus Paradigm (SCP) advocated by Arweave and everFinance opens up new possibilities in the field of token security:
- No more trust gaps, token information is trustworthy, and the consensus of the DAO is the only trusted source
- No more reliance on authorities, decentralizing token information so that anyone can get accurate information
- No access control, any institution or individual can participate in DAO without permission
- Faster token information validation, with DAO’s economic incentive model incentivizing members to process new token information quickly
How to Build
Reasonable financial incentives are a vital element in creating a DAO. The traditional security auditing process cannot solve the consensus on security information or the single centralized point of risk.
We can develop a tokenDAO node, an off-chain smart contract for DAO members’ collaboration. The node’s code defines the template for uploading token information, the token mechanism, how to conduct voting, rewards, and penalties, and other related rules.
There will be a token called TOK on tokenDAO. TOK is a profit-sharing community token, and anyone can go to everPay Swap to get TOK. TOK functions include:
- Incentivize correct token information uploads
- Incentivize correct token labeling
- Vote on token information
Token information will be uploaded to Arweave and must be uploaded according to the data template specified by tokenDAO. Incorrect data fields or duplicated uploads are considered invalid. Once valid data is uploaded to Arweave, it is loaded into the tokenDAO node. tokenDAO nodes automatically store the uploader address of each piece of data. TOK can be staked to each token information. The more TOKs are staked for each token information, the more TOK rewards the uploader receives. However, the TOK reward for the uploader is much lower than the reward for staking tokens for labeling since collecting information is much easier than labeling information.
Any user holding a TOK can stake their TOK to valid token information. TOK staking is a ternary operation consisting of: no staking, stake the token as safe and stake the token as scammy. When there is no staking, there are no rewards for the units of TOK. Staking a token as a safe or a scam can result in a reward or a penalty. The holder of a TOK needs to correctly determine if the token is malicious. The penalty for a wrong stake is greater than the reward of a correct stake to keep the quality of each stake and avoid arbitrary stakes.
A TOK can be staked to any number of token information. Different stakes can be chosen for different token information: stake for safe or for dangerous. A unit value of TOK is less profitable if it is staked to only one token, and most profitable if it is staked to all tokens in the network. A TOK can also be delegated to a third party to stake.
The graph shows the results generated by TOK stakes. The green bar represents the number of safe stakes, and the red bar represents the number of dangerous stakes. tokenA has a large amount of TOK staked as safe, while tokenC has a large amount of TOK staked as safe and a small amount staked as unsafe, which is a controversial token. If anyone staked for danger for tokenA, tokenA becomes a controversial token, and the token enters the uncertainty state.
Within n hours of the token being controversial, the user can choose to change the stake type, and if a new consensus is reached within n hours, the token is automatically released from the dispute. If there is still a controversy after n hours, a voting phase will take place. Any user with a TOK can vote on the controversial token. Ultimately, the wrong side of the stake is forfeited and awarded to the voter and the staker with the correct choice.
How to Use tokenDAO
The DAO is entirely free, and anyone can download the tokenDAO node. Running the node will automatically sync token information from Arweave and generate staking and voting conditions for each token according to the transaction history on Arweave. Once the tokenDAO node is synced to the latest block on Arweave, users can access the tokenDAO API to get the latest, fully decentralized, secure token information consensus.
Arweave + SCP allows us to quickly create a domain-oriented PoS and DAO based on a domain-specific problem. The model can be adapted to a broader range of domains. Whether blockchainless DEX or decentralized new media mentioned in previous blogs, similar projects can all be economically incentivized by domain-oriented PoS design tokens. Arweave + SCP solve the consensus problem and provides developers with the freedom to develop architecture designs. Arweave + SCP will pave the technical path for WEB3.