Delegate Civseed

  • Delegate Civseed


    A delegated proof-of-stake social network is proposed to answer the problems which often occur in centralized social networking. Centralized social networking consequently allows dissenting opinions to be silenced by single authority. Issues with centralized social networking include but are not limited to a single authority’s ability to censor the network. They have a central point of failure as databases are stored privately and not shared. A large reasoning for the start of this project was after the consideration of alternatives - GNU-Social, Pleroma, Mastodon. I believe there is weakness in not sharing a global database. The Civseed project aims to solve these issues by launching on top of ARK which uses a distributed database with shared rules, under the governance of its community.


    Block validators in this delegated proof-of-stake network are elected by the voters in the network. These block validators are able to package transactions inside of a block. Transactions must fit inside of a particular rule-set to be accepted into these blocks, and the network chooses to accept or reject this block. A typical consensus of these blocks are when 2/3 of these validators are in agreement. The transactions in this network also allow easy access to signing messages. You can find and help broadcast these transactions by synchronizing with the blockchain running a lightweight software known as ARK-CORE, usually ran through the Core-Commander. However, running a node is not required to send transactions, transactions can also be broadcasted to peers through a multitutde of clients. Users that are running a node have a realtime PostgreSQL database of everything which is happening on the network. Those without nodes are able to get access through API. This means that almost anyone can run an “interface”.


    While other blockchains are currently over 1TB to store, ARK is light in comparison. This allows for more users to have the ability to run nodes to secure the network as they are more affordable. The Postgresql packaging of transactions allow a large accessibility to people familiar with traditional databases. It should be noted that the interfaces would most certainly be centralized. Messages, accounts, communities can all be silenced by the owner of an interface. A project goal for Civseed is to have open-sourced interfaces which are also easily distributable, and perhaps utilizing some sort of Admin panels so that anyone is able to run one, not just those familiar to code. There are many benefits for having an easily ran interface that anyone can run, because as previously mentioned, an outside authority is able to act against traditional centralized social networks. If you were in China for example, it’s easy to block, and since the database is private, you have lost access to that data.


    A language which offers traditional programming functions a home at Civseed, and hopefully other interfaces. This is done through crafting unique Civil addresses which can be used for each programming function, allowing for more things to happen on chain using the vendorField. These functional addresses should be standardized so that interfaces are all able to use the same functional addresses. As an example - A user sends an Ark-Civil address an image URL. Interfaces are able to read this address and set the user’s avatar accordingly. This allows for the blockchain to stay lightweight, but also carry utility. It should be noted that on an interface such as Civseed, showing the recipient on transactions is less important, which allows for even more functionality.


    A BIP-44 styled DNS is proposed. Communities are registered by creating a new address. After the user has created a new address(a community in this sense), they send the newly created address to the determined Ark-Civil address which then reads this address for extended publickeys. This way, you can use the publickey to derive new addresses through hierarchial determinism forming a family tree, which is already a lot like how communities and their forums work.


    Users should not have to deal with Ark-Civil/functional addresses or trying to figure out how to find their extended publickeys. I’ve already worked to simplify this(, and will continue to do so. Ideally the user should be faced with a client which allows them a lot of functionality that markdown offers in chat or forum software. This could be done in a dropdown where they see “set avatar”, which does the required actions on chain, yet the user only sees “set avatar”.


    A v2 ARK fork I’ve been running for the last couple of months The data was collected by a bot facilitating a bridge from a Discord server to a Matrix server so it’s a bit crude, rude, and disorienting. Multiple users were also sharing the same username, so here’s a warning that it’s not for the fainthearted.

    Contingency Plan.

    In the event of fork, and ONLY if not in violation of U.S. law. The same amount that I have collected in ARK would also be rewarded to my voters in CIV proportionally to their voter weight in total pool. At an 80% payout rate to voters, you would divide your regular payouts by five. If this isn’t clear - you would also be rewarded this, along with the ARK you have already received, but only if this contingency(i.e. fork) were to arise. This should also regard circulating supply, which would be useful in the event of circulating supply not being similar to Arks.

    Voter payouts are 80% of weekly rewards and it is paid out weekly. Proposal is liable to change upon announcement. I will keep this post updated, you can also see for version control.

    Contact info

    Matrix – (or you can visit here:

    Slack –

Log in to reply

Looks like your connection to Delegate Civseed was lost, please wait while we try to reconnect.