The Universal Basic Information Dashboard Framework
As introduced in previous articles, the Universal Basic Information (UBI) Dashboard is an on-chain, hive-mind repository that pays DAO members to provide data that governs the organization ultimately via smart contracts. While the DAO evolves, the continuous, verifiable, aggregate pulse and knowledge of its members are fundamental sources of assessment, planning, budget allocation, and direction. Once we test and prove the concept with DAOs, every city can incorporate a Public UBI Dashboard that incentivizes citizen intake, input, and voting. For simplicity’s sake, for the rest of the article, “member” means either DAO member or city citizen, and “DAO” is interchangeable with “city.”
Here is a simplified, high level version of the process flow:
Member logs in to Dashboard and reads DAO data/updates >> Member unlocks next section and can now provide input >> Member unlocks next section and can now vote >> With all sections completed, member receives UBI payment at end of round >> Current UBI round input becomes part of next UBI round updates >> In next UBI round, member reads DAO data/updates section and cycle repeats
UBI System Architecture
Ethos and Intent
The UBI Dashboard is an emergent-property tool from which members can quickly tell if they are aligned with the DAO or not. This allows for efficient self-selection. If a person finds that after a few UBI rounds there is a wide gap between their thoughts and the DAOs, that can inform their departure from the DAO or sale of their membership NFT.
Just like traditional voting, participation is optional, but it comes with benefits well beyond UBI distributions, including improving the health of the DAO. There has been talk around the DAO ecosystem of introducing penalties like degrading governance NFTs — “if you don’t use it, you lose it” sort of thing. But that decision is of course for each specific DAO to make.
One of the biggest benefits that are possible with the UBI Dashboard is that for a large percentage of members, it can abstract away the 7,000 tools, links, and softwares needed to be used or checked to get a current holistic view of the DAO. In its most successful implementation, the Dashboard can act as proxy to much of the DAO tooling stack: Discord, Discourse, Polis, Snapshot, Opensea, Dework, Mirror, Gnosis Safe, the DAO’s website, Notion, Google Docs, Github, Dune Analytics, etc. The core contributors will still need to use all of these separately (until a better system comes along), but they are theoretically being paid more than the average member and are spending more time in the DAO as it is. For the average member that has 5–10 hours a week or less to put toward the DAO, the Dashboard becomes a super convenient option.
UBI Round Interval and Estimated Time Spent
A given DAO needs to cultivate repeated engagement and interest in its members to attain and keep healthy voter turnout (same for a city). Anyone who has spent time in a DAO knows it can be overwhelming and discouraging to have to constantly check if a new proposal is up for discussion or up for voting, on top of all the other communication channels. Since people also don’t want to and can’t continuously read discussions or provide data, we need a way to batch proposal actions, so this variation of a UBI system features a consistent interval structure. This way members don’t need to keep logging in to see if they’ve missed any proposal or discussion. The system alerts members when each interval or round opens and closes, but due to the set schedule, the user can establish a Dashboard routine at whatever time during the week works for them. The main drivers of the UBI system design need to be time efficiency and predictability.
We want granular and frequent governance, but there will be a point of diminishing returns. If we set UBI rounds at one week intervals, there might not be enough developments to provide new feedback on that we didn’t already have. Once a month seems too infrequent as there could be a few major changes, and the amount of reading, the number of questions, and voting should be kept to manageable levels. Two-week intervals might be the sweet spot, and with a streamlined, thoughtful UI/UX, the process could take no longer than one hour each round to cover the pertinent high level information. Even with the transient nature of DAO membership, this could be viewed as the bare minimum for DAO member participation. If a member can’t commit one hour every two weeks (which equates to two hours a month, only 24 hours in an entire year) to participate in the DAO, then they are basically absent as it stands, aren’t up to speed with DAO activities, and their voting becomes uninformed, untrustworthy, and unproductive. At this point, it would be hard to even call that person a member.
Member Access
No fungible governance tokens around these parts. No delegation of votes allowed. Delegation disincentivizes knowledge gain and member/citizen participation while also increasing centralization. In my mind, it’s a lose-lose. DAO members could access the system with wallets that contain governance NFTs with mechanisms that try to minimize the voting power to one NFT per person, but it’s preferential to be accessed via Proof of Humanity or some other digital, decentralized identity system.
Once members have logged in to the Dashboard, they work through three sections, but the DAO Knowledge section is the only one visible at first. Each section gates the next one. Voting is last to ensure the members are voting in an informed manner.
Once each UBI round closes, the Dashboard can show who has voted and when, but no further individual voting or UBI details are displayed or able to be accessed. This ensures individual voting privacy while keeping overall voter turnout statistics open and verifiable.
DAO Knowledge Section
If you’re starting this series with this article, the dashboard can look something like Decentraland’s (props to the team that built it!), but with interactive functionality throughout. The first section conveys DAO-wide data, community and project updates, previous round’s proposal data, and background info for proposals up for voting in the current UBI round. All sections are critical, but this section repeatedly lays the foundation.
The gating in this section can be either a time-locking mechanism so that the user cannot skip the section (e.g. there might be three time-locks at five minutes each requiring three different clicks. This makes the user sit there and wait for the timer, so they might as well read and get educated.) or using an automated, easy-to-moderate difficulty quiz that only lets users advance after achieving a passing grade. We gate with reading comprehension. High voter turnout does not suffice. High, informed voter turnout suffices.
Member Information and Sentiment Section
After the first gate, DAO members will be prompted to enter their data, feedback, and current DAO sentiments through focused questions, some of which are informed by the previous section, others by the state of the DAO. Keeping flywheels in mind, the feedback can become part of the source data used in the next UBI round’s DAO Knowledge section.
One of the key puzzles to solve is how these questions are generated. At the initial stages, the questions would be heavily rooted in hard math and on-chain DAO data, but as the system grows and matures, the need for abstraction and subtlety increases. But minimizing or eliminating human gatekeepers altogether is a major goal. The community could be the decentralized decider of the questions, but on the surface, polling on polling questions seems cumbersome, time intensive, and inefficient. An AI program might not be the most desirable filter of critical querying, but it might be the best current option for more complex objective questioning.
Taking an idea from an essay by Ralph Merkle, one entry in this section is the same for every UBI round: the DAO Collective Welfare score (DCW). (For towns and cities, this could be called the Democratic Collective Welfare score or similar.) Each DAO member is asked to enter their present state of satisfaction with the DAO. This should be on at least a 10-point scale. A 100-point scale is better. Granularity is coveted here, since this will be asked many times in a one-year period. This is a very potent metric to utilize, and it makes sense to make it the last entry of this section.
The community’s pulse and sentiment on pertinent, timely DAO operations and updates should now be recorded on chain, while further solidifying each member’s grasp on the current state of the DAO.
Proposal Section
Having absorbed DAO information and submitted their own to the Dashboard, the Proposal Section will become visible. This section is split into two parts: proposals for discussion and proposals for formal voting. Members can participate in productive governance, now adequately equipped with background information from the DAO Knowledge section.
Before the two-week round begins, new proposals are submitted for forum-style discussions using a service like Discourse or similar, which is embedded directly into the dashboard. Once the round starts, submission is locked until the next round. This is the first opportunity to discuss/vet new proposal ideas. Each member can comment or ask questions and give a pre-vote for if the proposal should move to the formal voting stage. This serves as a community filter, so that formal voting is reserved for higher relevancy proposals that have some measure of backing. If the proposal hits a certain threshold of “yes” votes, then it advances and is formally voted on in the next UBI round. If it does not meet the threshold, the proposers address as many questions as they can, and everyone can read the discussion in the Knowledge Section of the next UBI round. The proposal team can resubmit their proposal for discussion after a community-established waiting period (e.g. two UBI rounds).
Concurrently, proposals voted past the discussion round can now be formally voted on, with previous discussions and new answers displayed in the Dashboard for reference. Each proposal must go through at least one two-week forum-style discussion stage and one two-week formal voting stage before being able to be officially approved. Similar to the proposals for discussion, the proposals for voting must be submitted before the UBI round opens.
Keep in mind the proposal background info and discussion submissions will always be available, and conversations can and will happen outside of the Dashboard context. But the aim is that the meat of the conversation happens in a streamlined manner within the Dashboard.
When the UBI round closes, all entries are automatically aggregated before being published on-chain in one transaction (or as few as possible). If a proposal meets voting and approval thresholds, it is codifie — in the case of DAOs, quite literally. When applicable, the bytecode is created for any technical changes and is sent to smart contracts and oracles for implementation.
UBI Payment and Token Choice
At every round’s end, each member with verified voting transactions will be distributed a UBI payment. Of course, with vacations, illnesses, family reasons, etc., most people will not be able to complete every UBI round, so thresholds could be put in place (e.g., members must keep a rolling percentage of completing at least 70% of UBI rounds to be eligible for UBI payments). We want to incentivize medium-to-long term commitment and engagement, so some sort of multi-round requirements should be implemented.
DAOs could use stablecoins or other assets as UBI payment, but for out of article scope reasons, this probably isn’t feasible for most DAOs. Instead, a DAO-specific UBI token could be distributed and value-initialized by setting DAO perks equal to a certain quantity of tokens.
Genesis UBI Round
As blockchains begin with an undisputed genesis block as the root, the initial UBI round must be undisputed and noncontroversial. The round seeds governance with member data and on-chain numbers, so that the UBI token is mined via community participation and verifiable truth. Thus, the initial questions should be heavily math-based and Likert scale-esque.
For initial rounds for brand new DAOs, only the DAO Knowledge and Member Information Sections would be visible. As examples, the user could provide feedback on why they joined the DAO, quantifiable onboarding data (oldest wallet transaction, degen score, home city, etc.), and thoughts on future direction of the DAO. Members would not be asked to give a Democratic Collective Welfare score until the second round, to give time for news to happen. The big goals for this round could be to establish and clarify the DAO’s mission, populate a directory of talent, and build a priority list.
If the DAO is existing, the genesis round would include all three sections. Members would be educated on the DCW score and be asked to enter their first value. The existing forum and proposal systems would of course need to assimilate into the UBI system.
Round Results and System Assessment
Round results can be displayed in summary visualizations immediately after polls close. If it is desired, a rotating UBI Assessment Team could be put in place on day 0. They analyze, verify, and confirm round results. In the event of wonky outcomes or bugs, the Assessment Team can flag certain parts of the rounds or the round as a whole, and the community can vote on what to do with the results, pausing the system if appropriate.
A member must be in “UBI good standing” to be considered for election to the Assessment Team (good standing could require participation in more than 70% of UBI rounds in the last six months, member voting data within a max standard deviation % from DAO-wide voting data on DAO direction, etc.). Elections, team pay, whether they can vote, team rotation frequency are decided via proposal. (Guild Facilitators and other paid roles could also be required to be in UBI good standing.) The Assessment Team could also have a role in managing the Sentiment Polling questions, but one bigger effect (dare I say goal) of this system is to minimize or make obsolete any kind of gatekeepers or politicians, and the Assessment Team starts to resemble something in that ballpark, so after the system has reached a productive homeostasis, the team should have a diminished role or be discontinued.
When assessing the UBI system as a whole, many Key Performance Indicators (KPIs), tailored to each DAO, can be made to measure DAO productivity. The aggregate DCW score in theory is one of the best KPIs. With increased communication, education, and alignment, over the medium-to-long term, the score hopefully goes up as the system progresses, all other factors being equal. If the DCW is decreasing, then members can vote to overhaul or completely remove the UBI system.
The Roadmap from DAO to City
There needs to be heaps and heaps of testing and experimenting via DAO daily governance before the system sees non-DAO use. Different scenarios can be simulated by setting up “UBI zones” in Decentraland, Sandbox, or other metaverse platforms. A DAO buys a sector of land or makes a trade/partnership, and Citizens can participate as if they were living in the city. All get paid to participate. This features low stakes and fast iteration. Instead of two-week UBI rounds, they could be two days or even shorter. Participants try to break the system at these stages. Implement lessons learned and constantly tweak the system.
- Phase 0: Build beta versions of Dashboard, smart contracts, and tokens. Deploy on testnets.
- Phase 1: Test Bed 0a — Metaverse City-building Simulation 1: DAO members participate as if they were living in the city. All get paid to participate. After the testing period, process results, iterate. Research, create, and implement improvements to all governance.
- Phase 2: Test Bed 0b — Metaverse City-building Simulation 2: Again, all DAO members participate and get paid to participate. Stricter rules, penalties, and a more focused system. Process results, iterate, etc.
- Phase 3: Test Bed 1 — Implement and test UBI system for the DAO. Process results, iterate, etc. Explore a partnership with a small town.
- Phase 4: Test Bed 2: Implement system in said small town. Practice alongside the legacy system. Concurrently, build the production version of the governing suite to sell to governments and businesses.
- Phase 5: Go Live — small town
- Phase 6. Test Bed 3: small city. Practice alongside legacy system
- Phase 7: Go Live — small city
- Phase 8. Test Bed 4: large city. Practice alongside legacy system
- Phase 9: Go Live — large city.
CityDAO as an Example Case
Phew. So, with the thinking behind the main elements out of the way, to recap, here is one possible high level view of the system using CityDAO as an example:
CityDAO UBI Dashboard System Layout
Since Medium doesn’t like formal outlines, here’s a PNG summary of the system using CityDAO-specific details.
There can be additional sections/pages in the dashboard that are always available to peruse, but the previous three sections are the only sections for UBI system use.
CityDAO UBI Token Features
In order to develop and preserve the UBI system, the UBI token can only be mined through participation in and completion of the UBI rounds. Subject to voting, the tokens initially would not be used for bounties and not have official liquidity on DEXs. You could also get a little wild and crazy and code the token contract to not allow transfers until a certain date, say three or six months after UBI system implementation. This means that the only way to mint and receive UBI is to have a Citizen NFT and vote, i.e. to be a Citizen of CityDAO. This closed, feedback loop economy aligns everyone and further incentivizes joining the project and being an active Citizen. Once the system has reached a productive homeostasis, the tokens could be opened up for transferring, bountying, and funding of projects. Detailed tokenomics would be determined via community discussion and Citizen vote.
Possible UBI use cases:
- Book stays on CityDAO land / property where Citizen does not hold an NFT. (Citizens could also register their personal property to be eligible for stays purchased with UBI.)
- DAO merchandise
- Purchase non-voting CityDAO NFTs
- While UBI tokens cannot be used for formal DAO governance voting rights, they could be used to vote on non-operational, “fun” decisions for the DAO, like what kind of events to host, shirt designs, naming assets, etc.
- Unlock access to certain fun events
- In the medium-to-long term, tokens can be used in quadratic funding of projects or paying/tipping other Citizens for their work or their awesomeness
- In the long term, UBI can be spent on any services offered within a partnering DAO ecosystem
- In the long term, UBI can be invested into pools for CityDAO Data Markets (see previous article)
And that’s it. Thanks so much for reading through this thought experiment that kinda spiraled out on its own. If you’re interested, please click the Github link below for a code repository with simple examples of what the smart contracts could look like. Also, there is a simple version of a UBI Dashboard I have deployed on the Ethereum Goerli Testnet, which you can also interact with via a live dApp. But read the README in the Github repo first!
This is the fourth article in a four-part series that focuses on information and voting in DAO and civic landscapes. Here is the series list:
Article 1: Digital Symmetry Coursing Through the Network City
Article 2: DAO Voter Turnout and Other Impossible Feats of Humankind
Article 3: Universal Basic Information: Mining the Renewable Public Good
Article 4: This article.
UBI Dashboard Github Repository: Back end — Deployed to Ethereum Goerli Testnet. Instructions on how to interact with the contracts are in the README.
Live “Minimum Viable Product” website: UBI Dashboard dApp
