DAO Product Policy discussion

This is not a proposal, but it is an aggregation of multiple.

The Frabric is not an autonomous entity, it’s governed by the DAO members.

This means that for The Frabric to work, we as a community need to define rules of operation; what’s permitted, expected, and what’s ban worthy.

What I’d like to start here, is not only a list of potential DAO decisions or things we need to decide on, but also the driving forces behind how DAO Product Policy is directed.

2 Likes

In terms of types of Policies; these are some high level stubs that we’ll want to refine.

  • How are Policy Decisions decided? How are they Ratified?
  • When does The Frabric determine when to mint new tokens?
  • What are the Terms of Use for regular tokenholders? What kind of Offenses are punishable?
  • What’s the minimum information required to make a proposal?
  • What should the Upgrade Procedure look like?
  • What do we do in the event X happens?
1 Like

These can be worked through as we can benchmark from other examples on how DAOs operate.

My concept of Policy comes rather not from the DAO Ops dimension but actually the real world ramifications of potential RE and facility disputes:

  1. To execute or modify covenants which relate to who or how a property is sold;
  2. To remove and/or replace Governors of specific assets;
  3. To force sell / liquidate an asset in certain conditions (such as insolvency, legal trouble, etc)
  4. To remove / replace property caretakers/facility maintenance 3rd parties under non-performance or substantial duty clauses;
  5. To gather and ratify property sale/management decisions if certain sites become under group-sale / en-bloc mass buyouts if another entity offers this, as well as responding to potential sites becoming under eminent domain
  6. Evictions of tenants behind due on rent or other possible scenario where someone on a property needs to be removed for various reasons

And so on.

Here are some basic suggestions on how the following points may be addressed. As an eventual DAO there will be expected to be more input from a diverse body of individuals, and trying to address varying concerns and motives will be central to be able to keep the DAO governance process running.
Having said that, my personal opinion is that projects should be governance minimized to reduce overhead, voter apathy and ensure continuity and smooth flow of operations.

They can be raised like other types of paper proposals with a defined scope, period of discussion and ratification mechanism, such as Snapshot or the Frabric’s bespoke governance platform.

As there is no hard code to cap token minting at this point this presents a risk for a governance attack. I suggest to keep incentives and objectives aligned between key token holders so that they are able to understand and be informed the pros/cons of additional token minting and the reasons behind it.

I suppose this should be answered by someone with legal expertise but directionally the usage should be something which does not undermine the health and the economics of the platform as well as not committing anything illegal. Punishable offences would be a temp or permanent blacklisting of the ID to use the platform, depending on the severity of the offence.

This depends on the type of proposal. If its acquisition of property then a prospectus and legal framework/entity should be provided, as well as particulars of the Governor supporting it.

My understanding is that functionality Upgrades should ideally be limited to be proposed only by the developers of this project due to their deep knowledge, and those who are developing an integration to the Frabric platform. These Upgrade proposals would identify what is being upgraded and why, with a simple on-chain vote to be compliant to the governance process. I find that some mundane Upgrades being brought through the entire governance process will cause governance bloat and may paralyze the project if users are mal-informed and vote to object a potential upgrade.

We cannot anticipate all types of events, so hard to plan here.

Having said that, I suggest that we implement a model of governance with a reasonable timeframe before anything can be executed and ratified to allow for adequate discussions or investigations into the merits and mechanics of a proposal, with a veto mechanism (or emergency governance safeguards) so that attack vectors can be mitigated.

Obviously, having a strong team dedicated to Policy would also be extremely helpful, so don’t forget the humans participating in this project!

2 Likes

In 100% agreement with this regarding areas of focus, but I will argue that both dimensions are important to consider. We should certainly focus on the product policy side (which coincides with your RE and Facility Management points) first however.

I suppose this should be answered by someone with legal expertise but directionally the usage should be something which does not undermine the health and the economics of the platform as well as not committing anything illegal. Punishable offences would be a temp or permanent blacklisting of the ID to use the platform, depending on the severity of the offence.

Because the Frabric has built-in arbitration, those decisions are ours to make. The LLC that wraps the Frabric is flexible enough to defer to on-chain ratified proposals for bylaw definitions, this means that we can truly define what we feel should be within the terms of use, when users will be bannable; and when they are not. We obviously do need to be careful about this, which is why I’d argue this should be a crucial policy discussion.

My understanding is that functionality Upgrades should ideally be limited to be proposed only by the developers of this project due to their deep knowledge, and those who are developing an integration to the Frabric platform. These Upgrade proposals would identify what is being upgraded and why, with a simple on-chain vote to be compliant to the governance process. I find that some mundane Upgrades being brought through the entire governance process will cause governance bloat and may paralyze the project if users are mal-informed and vote to object a potential upgrade.

Agreed that the policy around upgrade proposals should require analysis to be done by respected members of the community, with their feedback being used as a locus for future voting. It is however a core part of the protocol to ensure that upgrade proposals can come from any source, and each require a normal majority vote to pass - anything less would lead the overal protocol open to attack.

1 Like

I started looking into governance models of other DAOs. A particular one stood out to me (it reminded me of gruads governor RoR for threads) and it was Polkadots on-chain governance structure. Put simply: their primary goal is to do everything in their hands to prevent fraud: Governance · Polkadot Wiki. I wonder whether we can implement something similar for the FrabricDAO.

How it works:

  • To table a proposal on polkadot a DOT holder must bond/stake their tokens.
  • The threshold for whether a polkadot proposal is passed or not depends on how many DOT coins are participating, with a higher level of consensus required, if there are fewer DOT participating and vice versa.
  • Instead of standard one token equals one vote, the weight of a vote depends on how long the token is locked up for, with a maximum 32 month lockup offering a 6x vote multiplier.
  • Each polkadot voting period is one month and if a proposal is passed it can still be vetoed by the community elected polkadot council.
  • Even if the proposal is passed by the polkadot council, if the proposal is found to be found a threat to the protocol by polkadots elected technical committee, the proposal is vetoed and the DOT bonded/staked by the proposer is burned.
  • If all goes smoothly, it takes another month before the proposal is implement.
  • Emergency proposal can be fast-tracked by the technical committee.

That being said, the FrabricDAO genesis squad members can agree on initial policy decisions. However, they can changed by community proposals IF these proposals pass the council and the technical committee.

I hope this answers your questions or at least give you clarity on what aspects of policy decision we have to focus on.

Just to document that matters relating to the types of collateral being able to be used for bonding is one aspect of economic policy that will need to be addressed, as we discussed on the Product call just now.
In that vein, perhaps the collateralization/reserve ratio as well as minimum bonding level obligations would be part of this discussion.

@zeryx

@zeryx @senad.eth

One model of governance that I quite like is documented here: Interest Protocol.

Primarily the consensus mechanism involve 2 tiers with a 3rd emergency channel option (adapting from the link above):

  1. Signal / Consensus Check
    This corresponds to the preproposal phase, and that this proposal will be created on snapshot (or some other gasless mechanism). The proposer must have some amount of governance token (in our case FBRC) to be able to upload a proposal. There must be at least a 5 day voting window, with a consequent discussion on the Discourse forum.
    For the vote to be successful, the vote must have a simple majority and pass the quorum of X% of FBRC holders.

  2. On-chain Proposal
    The second stage or on-chain formal proposal requires a passing Consensus Check vote, and should include final/audited code. This will require a higher initial token holding compared to Consensus Check to submit a proposal, and a higher quorum of passing votes again compared to Consensus Check.
    Given the higher limits, the proposer/sponsor of a Proposal does not need to be the same entity as the Consensus Check. This allows for collaboration of different individuals to find a party that meets the thresholds required to put forward a Proposal. There should be a timelock of at least 48 hours for execution.

  3. Emergency / Expedited Proposals
    This governance channel allows for expedited or critical proposals and greatly shortens the timespan for discussion and voting. This is directly voted on the on-chain platform, and while the proposer/sponsor requires X% of token holding, the quorum must meet at least 50% of the available FBRC token supply.

I like it, it’s simple - I’d also argue that some Policy proposals shouldn’t require on-chain final ratification.

Proposal open times are fixed to two weeks