I wrote this document today while on a plane which I encourage you to add suggestions and comments to. It includes thoughts I've been thinking for many months with regards to my involvement in eosDAC and the challenges we've all faced with Steem and Steemit for years. This may be part of the solution.
SteemDAC
Exploring the use of eosDAC technology for decentralized Steem community governance.
Foreword
At this time, this document in no way represents a commitment by anyone to do anything. It's simply a collection of thoughts started by Luke Stokes to explore future potentials. It was created while flying from Puerto Rico to Colorado on Sunday, January 20th 2019.
What is eosDAC?
eosDAC is a decentralized autonomous community powered by smart contracts on the EOS Mainnet. In the future, it may exist on DAC Chain, an EOSIO-based blockchain to be developed which will include the main contract elements (token membership, custodian voting, and worker proposals) as core system contracts for all DACs to use on that chain. eosDAC has been operating for some time on EOS with an active community of workers with development progress on multiple projects including EOS block production, the EOSDAC token explorer, the DAC Member Client, multiple EOS smart contracts, and eventually the DAC Toolkit enabling easy creation and deployment of DACs. You can learn more about eosDAC here:
https://www.youtube.com/eosdac
Why?
The Steem community needs effective decentralized governance. Steemit, Inc and the large early-mined (some say “ninja-mined”) stake it controls represents a very real threat to this need ever becoming a reality. Without getting into a debate about the effectiveness of Ned Scott, the CEO and Co-Founder of Steemit, Inc, this document will state as a premise that Ned has lost the confidence of the majority of STEEM stake holders and is not the right person to create or lead a decentralized community effort or long-term governance of the Steem blockchain. Those who disagree with this premise may find little value in reading further. Those who agree with this premise will hopefully find value in exploring one possible solution using the eosDAC technology stack.
This approach does not, at this time, suggest a solution to the overwhelming stake currently owned and controlled by Ned through Steemit. This is a fundamental DPoS problem which may not have a solution on the current chain. The hope in exploring these ideas is to create an attractive solution and path towards decentralization. Ideally, it becomes so attractive that Ned may decide to divest a significant portion of this stake to support it and solve the centralized token distribution problem at the same time.
eosDAC Explained
To fully understand what I'm proposing for SteemDAC, it's important to understand what has already been built for eosDAC and what is up and running today. The code running eosDAC will be modified to run SteemDAC.
To really understand eosDAC, please read through the eosDAC constitution available here: https://members.eosdac.io/constitution or on github here: https://github.com/eosdac/constitution You can see an example of the current DAC Member Client below:
Every member of the DAC must hold EOSDAC tokens and agree to the constitution. A hash is stored on chain for their member account for the version of the constitution they agreed to:
Only members with the latest version of the constitution are active. Others are asked to sign the constitution again when they login.
The DAC itself exists as multiple smart contracts on the EOS Mainnet. You can learn more about that here: @eosdac/eosdac-custodian-candidate-voting-is-live including how accounts like dacauthority ensure all funds and code permissions are managed by multi-signature control. In the future, these contracts may be moved to DAC Chain as mentioned above. You can learn more about the DAC Chain Initiative here: @eosdac/the-dac-chain-initiative-announcing-an-exploratory-into-how-usage-of-eos-side-chains-and-separate-chains-may-create-benefits-for
The DAC itself, including funds and smart contracts, are controlled by 12 elected custodians. They serve for a 7-day period and are responsible for approving and denying worker proposals. eosDAC members elect them via their token-weighted vote and every 7 days, the top 12 voted custodians are elected. The multi-signature permissions on these accounts are updated automatically when the New Period function is called which also distributes pending custodian pay. Note: members only need to vote once (just like they only vote for Steem witnesses once) as their voted stake will be used according to their votes for each pay period.
Members can create profiles on the DAC and submit themselves as custodian candidates to be voted on. They can also create worker proposals for custodians to review and approve. When submitting a worker proposal, they include an auditor or subject matter expert who will review the work after it's done in the case of a dispute between the worker and the custodians once pay is request. Funds for active worker proposals are put into an escrow account contract with nulled keys that only a 2 of 3 code-based multi-signature approval can release where the three parties are the DAC via the custodians, the worker, and the arbitrator.
For more questions about how eosDAC works, please ask away in the discord here: http://discord.io/eosdac or, again, review the constitution.
Now that you have an understanding of how eosDAC works with the EOSDAC token, let's consider what SteemDAC with a STEEMDAC token equivalent might look like.
The STEEMDAC Token
On-chain governance requires smart contracts which can be interacted with using a governance token. EOS is currently the best platform to accomplish this because the performance requirements can be met, the contracts can be updated as needed by the community, and there are no fees for interacting with the contracts (once enough stake has been set for account network and bandwidth needs). The purpose of creating and using an EOS-based token like STEEMDAC is not to move Steem users away from Steem to the EOS blockchain. Others may claim this or even try to use it for this outcome, but as the original author of this document, I, Luke Stokes, can honestly tell you this is not the purpose of this token. The point here is to solve a very serious problem with Steem centralized governance.
STEEMDAC will exist to accurately represent the token holdings on the Steem blockchain of those who want to actively participate in on-chain governance of Steem beyond just witness voting which relates more to block production and chain definition. It is a non-transferrable token and balances can only be updated via cross-blockchain communication with Steem (or a partly manual equivalent done transparently on chain by elected custodians). The governance scope of the token will include the management of community funds for Steem development up to and including core blockchain code, shared code libraries and toolkits, exchange relationships, marketing, translation, outreach, and more. This will be accomplished via the eosDAC tools running on EOS or possibly DACChain in the future. There are many possible ways the STEEMDAC token could accomplish this, but for example sake, I'll outline one possibility here. Others may be better.
Example Token Flow
The SteemDAC Member Client and smart contracts require the STEEMDAC token for membership, custodian voting, and all other token-related functions of the DAC. This outlines just one possible example of how this token could be created and used. I have not yet run this design by smart contract experts such as Dallas Johnson or Michael Yeates nor have I spoken about it yet with Steem developers like @someguy123 or @buildteam who have done somewhat similar things and may provide input.
If the Steem user doesn't have an EOS account, services for obtaining them can be created (some free account creation codes exist as well).
Possible EOS SteemDAC member table structure
- id <auto id>
- steem_account (matches Steem acount name)
- STEEMDAC (Steem Power balance as of last update)
- steem_power_last_updated (date)
- is_validated (boolean
- is_pending (boolean)
- steem_transaction_id (transaction hash from Steem blockchain for the validation transfer)
- agreedterms_version (version of agreed terms)
- member_status (starts as PENDING, then ACTIVE when is_validated = true. Might also be SUSPENDED if removed from the DAC by custodians for violating the constitution).
The example below assumes there is no true cross-blockchain automation between Steem and EOS yet, so much of this is done via manual validation by the elected custodians who are the only ones with control to validate STEEMDAC member balances.
Member Client Interface (user actions: example lukeeosproxy account)
If is_pending = false AND member_status NOT SUSPENDED AND steem_power_last_updated is empty or > 7 days:
- Ask for Steem user name (example: lukestokes)
- Connect to Steem API to find account, get Steem Power Balance (70000)
- Present user with confirmation:
- "lukestokes, 70,000 SP?"
- Call smart contract function update_member
- store table id, steem_account = lukestokes, STEEMDAC = 70000, steem_power_last_updated = today's date, is_validated = false, is_pending = true, steem_transaction_id = empty
- If steem_account already exists but for a different EOS account, throw error, otherwise update existing account.
- Ask user to send STEEM to @steemdac with the following memo: lukestokes|70000|1|lukeeosproxy (the “1” being the auto id of the RAM table record saved in EOS).
- This transfer would probably be a very small amount (like 0.001 STEEM) though a larger “membership fee” might also be collected to help fund development if that makes sense.
- The Steem @steemdac account owner permission would be controlled via multisig of the top 25 active Steem witnesses. Based on a measurement of witness turnover, this could be updated regularly via multisig by the witnesses. The posting/active permission would be set up as a multisig to possibly include a group or individual voted on by SteemDAC as an active worker proposal to manage those funds (this could also just be the witnesses, depending on how things work out).
- Scan Steem chain for transfers to @steemdac account matching steem_account. Do a lookup on the EOS RAM table based on id, make sure the Steem Power amounts match, the accounts match, etc. If they do, save Steem transaction id to the table.
Note: at this point, none of the data within the member table can really be trusted since they could run their own member client and hack it to ignore the Steem blockchain and claim they have millions of Steem Power.
Member Client interface (custodian actions)
- Review list of valid, pending token validations. Client will again scan the Steem chain, verify transactions and data in EOS and present a bulk "approve all" for everything that matches.
- Multi-signature transaction created to update the is_validated for specific accounts and set is_pending to false.
- The transaction id will have to be a valid transfer from the named account to @steemdac and the Steem Power balance of the named account must be >= STEEMDAC balance in the table at the time of validation.
Note: The trustworthiness of the msig transaction directly relates to the trustworthiness of the custodian and the EOS and Steem node they are connecting to with the member client they are using.
On Chain:
New Period:
- New Period can not be run if there are more than <X> pending updates which are greater than 5 days old.
- For every <X> amount of Steem Power validated, all custodians get <Y> pay.
- Idea: Custodian bonus pay lottery where chances to win increase for those who validate the largest bulk msig. (game theory: keeps the number of interactions the custodians have to deal with low while also ensuring they don't just wait for too long. The pending accounts should, in theory, be approved multiple times a week, or at least the bulk of them should be.)
- Before each period, member client creates a bulk msig (or a template for any custodian to create) which scans the Steem blockchain and sets is_validated to 0 for accounts having Steem Power < STEEMDAC balance. This effectively removes anyone who powered down in the last 7 days but didn't update their SteemDAC account. Accounts that powered up or earned Steem Power will be left alone to cut down on the processing costs.
Note: this will be a process intensive thing, so it will probably have to be done offline and presented as a msig for review. Maybe multiple msigs to keep the amount low.
Ideally, this will all be done automatically on chain via a cross-blockchain communication process when such a thing between Steem and EOS exists.
From this point on, STEEMDAC balances with is_validated = true and steem_power_last_updated < 7 days ago can be trusted and used for electing the next round of custodians.
Things can be kept up to date by on member login, scanning the Steem chain and if needed showing a user a "Hey, you powered down or powered up more than <X> percentage, please verify your balance again." which then sends the transaction to update the members table (sets is_pending = true, updates values, etc) so that update gets included in the next round of validations for that week’s voting.
First Steps
Sound interesting? Worth exploring more? Here are some action items we could take to start seeing this exist in reality:
- Make copies of all the eosDAC system contracts (eosdactokens, daccustodians, dacauthority, etc) and modify them for SteemDAC use. They can be found here: https://github.com/eosdac
- Deploy the modified system contracts as new EOS accounts for SteemDAC.
- Copy and modify the DAC Member Client with Steem logo, colors, language, etc. https://members.eosdac.io/ via https://github.com/eosdac/eosdactoolkit
- Copy and modify the EOSDAC token explorer. https://explorer.eosdac.io via https://github.com/eosdac/eosdac-token-explorer
- Develop the SteemDAC constitution (possibly use the eosDAC constitution as a starting point: https://github.com/eosdac/constitution)
- Set up required EOS nodes and servers (or partner with eosDAC for this) to power the explorer and member client (blockchain scrapers / indexers are needed for the explorer, member profile, and msig proposal system).
- Develop a website (I recommend using a static Jekyll site) for explaining SteemDAC. This site can be maintained via github pull requests approved by the elected SteemDAC custodians or the active worker proposal team tasked with maintaining the website.
- Develop social media teams, media, logos, style guide, etc.
- Create a SteemDAC Discord and/or use an existing one. Another possibility is to create automated cross-posting between discords. Possibly include posting summaries on the Steem chain as well.
What Could SteemDAC Look Like?
With a constitution and on-chain governance in place with an easy-to-use interface for member registration, profile creation, custodian candidate registration, worker proposal creation, custodian voting, and custodian tools (msig approvals, worker proposal voting, etc), we'll have a decentralized model of elected custodian leadership managing the funds of the community. These elected custodians will be put in place via STEEMDAC token voting which accurately represents stake on the Steem blockchain.
Funds sent to the @steemdac account (and/or the EOS equivalent) would be used to pay out worker proposals. To avoid legal concerns, fiat currency would be avoided completely and any fiat costs required for work done would be accomplished by the active workers directly (as in, they would be required to handle their own cryptocurrency to fiat conversions as needed to accomplish their work). Depending on the legal advice gained once this structure is fully defined, a traditional service company (like how eosDAC uses Dacoco) may be used to handle worker employment contracts and remove joint and several liability concerns from the DAC itself.
As people understand the system, the decentralized permissions securing the smart contracts and the funds, and the effectiveness of token-based voting and custodian oversight, we might collect more donations to fund the DAC. The most important donation would hopefully come from Steemit, Inc to vastly decrease their current centralized holdings. Ideally, at least for now, they would also be the most active worker in the worker proposal system continuing development on things like RocksDB, Condenser, Hivemind Communities, SMTs, and more.
SteemDAC would be inclusive, but still governed by its constitution and its code of conduct. A member's STEEMDAC voting weight represented by their a non-transferrable token balance could be invalidated for voting by the custodians (member_status set to SUSPENDED) if there was a credible violation of the constitution and a multisig proposed to the custodian board to change their status passes a Special Referendum. Ideally, all communities within the Steem ecosystem will actively participate including Utopian, Oracle-D, PAL Net, and more.
Just as with eosDAC, changes to the constitution or smart contract code would have to be approved by Special Resolution approval of the custodians.
The Result
A decentralized system for governance and funding for future Steem development which is controlled by Steem Power holders. Custodians, like witnesses, would be voted in (and paid, just like in the eosDAC model) to represent the will of the token holders in a transparent, trustworthy manner. With elections every 7 days, the leadership will be directly accountable to the token holders for approving valuable worker proposals and responding to community needs. They'll have skin in the game and the community will have one more reason to power up STEEM. Their voice can now be heard on far-ranging topics impacting Steem beyond just block production.
On-chain, transparent, non-violent governance: This is what we want and this is what we deserve.
This document represents just one of many possible solutions being worked on by some fantastic, passionate people. Let's keep the ideas coming to form a better future for Steem and the community who values it and creates its value.