Redesigning Paladin Governance

TL-DR: Move governance to an optimistic council governance structure

Dear community,

Paladin has now practiced decentralized governance for over two years, and executed ~90 proposals that have enabled us to evolve from a product with no future into a still small but sustainable ecosystem. There is a ton to learn from these past two years of very granular governance, both from successes and failures.

Rationale:
The current system has proved to be relatively successful at allocating resources and validating broad strategic plans. It is however, a large failure when topics become too granular or technical.

Here are a few examples:

  • When discussing treasury management few give their opinion, and even fewer are actually knowledgeable enough to take correct decisions;

  • When designing new products publicly, once again, only a very small subset is knowledgeable, motivated, incentivized to do so. Tokenomics 2.0 were a stark example of this;

  • It is far easier to create interference than meaningfully contribute (this is a general problem of public actions);

  • Current DAO frameworks are terrible at making clear of the scope of contributors;

In multiple instances, I’ve had numerous community members confide to me privately they felt out of their depth and would rather not participate. I think it’s time for a change.

The current governance process (writing a proposal, the discussions, and the 5-7 days of the vote) implies that Paladin simply cannot react quickly to opportunities without bypassing governance. This is a problem regarding treasury management (ie: we’re potentially losing a window to painlessly unwind our loan with Mimo) and other ephemeral opportunities. At current rate we have close to 2 proposals per week, which is way too high for anyone that isn’t full time on Paladin governance.

In terms of operations, the 9 signers have to coordinate regularly to manage the ever-growing tasks needed to operate Paladin (manage PoL, claim rewards, swap to ETH/stables, vote with strategic assets, distribute PAL incentives to active stakeholders, etc…). This creates new organizational risks that cannot be durably fixed with simple signer rotations.

Additionally, the current structure is not optimized for efficiency:

  • It is increasingly hard to operate in acceptable windows in terms of gas costs;
  • With an average of a proposal every 7 days, voters simply give up;
  • There is no framework for most contributor work;
  • We mostly fail to attract specialized contributors when they are needed;
  • There are no transparency frameworks, which results in contributors struggling to communicate their actions properly and creates a growing frustration among active community members, who rightfully feel sidelined;
  • We lack systems to truly empower skilled and motivated newcomers to stick with Paladin and share their brilliance.

We have entered a new cycle and it is up to us to be better, faster, and smarter than the rest of the market, to cement ourselves as a top protocol.

Proposed new system:
We currently have 3 active actors that intersect:

  • Delegates & active community members;
  • MS Signers;
  • The DevCo;

The goal is to empower all four, improving the efficiency of our organization without reducing accountability. After several months of research I would like to propose we switch to a council system, reliant on optimistic governance to maintain stakeholder sovereignty and accountability.

This means that instead of the upcoming signer rotation, we would hold a whole new election for Council Members elected for a 6-month term (max of 3 consecutive terms). Councillors are expected to be elected for an agenda. They will either be simple signers with executive power, or tasked with specific jobs (non-exhaustive list, keen to debate):

  • Liquidity Manager (Incentive deposits and liquidity distribution);
  • Ops Coordinator (Making sure DAO proposals are executing and organising the signing sessions);
  • Ambassador (representing Paladin on DAOs it builds on top of);

Specialized Councillors will be whitelisted to solo execute specific recurring transactions like swaps and votes via Zodiac. For the sake of efficiency and diversity it would be optimal to reduce the threshold to 7 councillors with a 4/7 threshold in order to increase signing speed. We believe this new system can have a reduced number of signers as votes will be executed via oSnap with a timelock, marking another step towards becoming an immutable organization. Ideally we will also have one of our two multisig under this timelock and the other under the management of the Councillors, this would prevent the risk of an evil signer cabal.

In such a structure, the hPAL holders are akin to a legislative body that directs the entire organization by electing representatives each cycle and greenlight roadmaps from the several service providers they fund. This would significantly reduce the number of votes the holders are expected to intervene in (3-5 per year) and highly raise the quality of such votes. They remain entirely sovereign, but delegate daily management and budget needs to the Council and its treasury.

Like the Synthetix Spartan Council, Councillors publicly vote on daily issues and are held accountable for these decisions. This is facilitated by their obligation to write a monthly transparency report (template of such report here), subject to validation of Delegates and individual stakeholders.

In such a system, delegates are effectively expected to become a counter-power akin to the judiciary branch in a traditional democracy. Unlike normal stakeholders, delegates are paid and expected to make the Council accountable for its action, by grilling councillors and their monthly reports, and, if deemed unfit, launching Inquiries through optimistic invalidation of their monthly reports. For this reason, it will not be possible to accumulate a councillor seat and a paid delegate position.

Similarly, we need to build frameworks to avoid having service providers create their own framework of payment. Proposal creation, if valuable, should be rewarded, same for ops, BD or development. Additionally we will have to Revamp the rewards for seating Councillors. A sitting councillor will earn 1000$ in PAL (and hopefully in stables instead starting in a few months), while a specialized council will earn 1500$ in PAL. Delegate pay will remain as it was decided in PGM 46.

Implementation Logic: :

  1. Integrate both Zodiac and oSnap into the Paladin multisigs;
  2. Vote a Genesis Council instead of doing a signer rotation - the process will be exactly the same (example here);
  3. Amend rewards for the new roles;

Poll:

  • For
  • Against
  • Abstain
0 voters
5 Likes

Hello,

This seems like a good proposals to have a more efficiency governance.

I just wants to have some information regarding a few points that aren’t clear for me:

  • How will we know then needs for specialized or generalized councilors (for example right now should we have special ones with which tasks and how many ?)
  • What would be the tasks of the Ambassador ?
  • What happens if a delegate apply to become a councilor ? (Does he needs to forfeit his status for the duration of the term ?)
1 Like

Hello,

This proposal of restructuring the governance is very interesting and in my opinion, great way to align the interests of everyone.

I only have a question regarding a specific role : are the BD positions part of the council or are they under the DevCo ?

1 Like

That’s kind of the unanswered question, I guess it depends on needs? Rn we need PoL and incentive management, external representation and internal organisation, maybe there are more needed? The Ambassador would vote with CVX + AURA in Warlord, and maybe the Aave ? Still unsure on this part.

If a delegate becomes coucillor, I don’t think we should ask him to stop being active or doing his role, as delegation user base is hard to grow, but he cannot claim delegate rewards during that period.

Imo that’s something that should be discussed in another topic, but for full disclosure, I have no idea yet.

Does this mean a monthly vote by delegates on the work of each councillor? Or will a vote only be triggered if there is debate about the work done?

Its optimistic gov, so unless a certain threshold is reached (let’s say 10% of hPAL) nothing happens, if threshold is reached, then a thread is creating justifying the issue

1 Like

Thanks @Figue for this well written proposal,

I agree with the vision that if we want to have an efficient DAO we don’t want to have votes on everything. Traditional organization have a hierarchy and some specific departments and that’s for a reason. We want to have the most knowledgeable people on the topic to make decisions. If everybody is voting on everything we could easily fall into the risk of the tyranny of the majority or in voter apathy.

I really like the tripartite set-up proposed that allows for more efficiency while keeping checks and balances and trying not to give too much power to one group of people.

- Executive layer - Council: If I understand it well we will now have this setup:
One Safe msig 4/7 for recurring txs where the councillors will have the full power.
A second Safe with an oSnap module that will be used 3 or 5 times a year linked to the Paladin snapshot space for long term startegic direction.

I would be happy to help on this if needed, I also must admit that I am biased as I am working at Kleros and we have a similar product to oSnap called Kleros SafeSnap but that is fully customizable. This could be use to make sure that any proposals and txs are compliant with Paladin Constitution or protecting the DAO from Governance attacks. We have some specific ressources like Dev and Policy Writer that we could leverage if the DAO wants to explore this.

-Legislative layer - hpal holders: I like the fact that this group is similar to the shareholders in a traditional company, they are voting strategic orientations and budgets 3 to 5 times a year. My understanding is if they don’t want to follow governance, they still can delegate their hpal power to Delegates right ?

- Judiciary layer - Delegates: Making the Council accountable by reading the monthly reports and asking questions is a good point. However, what are they concrete ways of action if they disagree with the behaviour of the Council ? You mentionned that if they manage to reach a specific threshold they could create a Forum thread that could lead to a Snapshot vote. However, I think we can go even further by implementing something like Hats Protocol. Each Councillor, could have a specific role that allow them to be a signer of the operational msig, however if the Delegate challenge the behavior of one specific councillor they could push a Snapshot vote that remove this role and defacto prevent him to be a msig signer anymore. This would allow to have true accountability and real on-chain governance power for Delegates.

Eager to have your viewpoint on this and to explore this new governance setup

1 Like

I think we’ll just need to double check if both implementations technically work for us. Other than that, np to put it up for vote.

Yes but they won’t vote on these choices, delegates will. Delegates are basically paid super voters here.

We call these Inquisitions

It’s kind of where we were going with Zodiac / Gnosis Guild and the concept of Specialized Delegates (there would be 3 of them rn).

For the Treasury we’d likely put all the PAL in a smart contract with a Timelock, not a Safe. It was highlighted the DeFi strategies and harvests would be quite complex if we also put them in at Genesis, but this is the final goal.

1 Like

Thanks for your answers !

Ok great would be happy to follow up on this if this proposal is sucessfully passed. Technically it souldn’t be an issue: here you can see on Shutter DAO both choices were considered.

Not sure to understand what is this notion of “specialized delegates” and why it would be limited to 3 ? Or you were meaning “Specialized Councillors” right and it is the Liquidity managers / OpsCoordinator / Ambassador? In my view there shouldn’t be any specific cap on the number of Delegates.

I really like the concept of having these “Inquisitions” and this tripartite model, this is getting popular among DAOs with mature governance frameworks and that’s a good thing to see Paladin following this path. Some examples: Rethinking Legitimacy in DAOs — MangroveDAO or The Lean Governance Thesis - Pokt Network

1 Like

Thank for this post @Figue! I’m supportive of a significant overhaul of Paladin’s governance model to enhance agility, especially given the current market cycle where swift action is paramount. Traditional governance structures in most DAOs have proven to be inefficient, characterized by low voter participation and decision-making dominated by small groups, among other well-documented issues. As such, I strongly believe that minimizing governance wherever possible is an experiment that should be pursued. In fact, I hold the somewhat unconventional view that DAOs might eventually evolve towards governance-free models or even embrace Algorithmic Governance. Our team (HundredX) is currently delving into this topic and compiling our findings into a research paper.

One crucial action I urge the council to take is the establishment of clear frameworks for “external” contributions from community members, should they occur. This would not only address the challenge of attracting specialized contributors, foster a more inclusive environment where diverse voices can contribute meaningfully, but also promote DAO partnerships. Prioritizing frameworks for BD and other value-adding activities, including proposal submissions and approvals, is imperative.

On a related note, I’m a fan of Kleros and am curious to see the possibility of integrating its mechanisms into Paladins governance framework. If feasible, implementing an additional layer of compliance aligned with Paladin’s Constitution would safeguard the DAO against sybil attacks, offering an invaluable enhancement to the protocols security . I eagerly await further details on this potential integration @alex_eth.

2 Likes

Hello, thanks for drafting this proposal !

This topic include many points, some of which I agree & other where I disagree here, so will share my feedback below:

To date, the Paladin DAO voted on XX proposals:

  • 51 PGM over 58, including 2 replaced & 5 canceled or denied.
  • 22 PIP over 27, including 5 pending vote
  • 2 PIR over 2
  • 1 PEP

That’s a total of 76 proposals voted over 88 proposals, the full breakdown can be found here (updated often)

While I agree that not all possible topics were included in the initial governance framework (which seems impossible), we always have the ability to include some to make it more complete, so I disagree when you say it has proved to be a large failure.

As a reminder, the current governance framework can be recap as follow:

  • PIR Category: Integration Request so anything related to whitelists, gauges approval for external projects, and any partnership / cross communication related topics

Short voting period and low quorum as each category has specific parameters depending on level of importance for the protocol & the DAO (3 days voting - 10% quorum for PIR)

  • PGM Category: Governance Management so basically anything related to treasury such as strategies, incentives, allocations, expenses etc (5 days voting - 15% quorum for PGM)

  • PIP Category: Improvement Protocol: Concerns anything critical about the DAO/Protocol so signers decisions, gov framework update, sc migration, new product etc (7 days voting - 20% Quorum)

  • PEP Category: Emergency Protocol: Enables to recap emergency actions taken by the committee & discuss action plan (1 day voting - 5% quorum)

I believe it’s needed to have different levels based on importance and hope the framework is easy enough to apply, but note that a recap is available in the 2nd tab of this doc posted on each proposal.

I do agree that sub frameworks such as for grants & service providers were never really defined, but it can just be proposed as a new PGM.

It depends on which actions, as explained above some topics allow us to react quickly, but treasury topics should always be discussed imo, especially as opinions between stakeholders are often different in Paladin, which is not a bad thing.

Yet it happened a few times that you bypassed the governance anyway, for example when switching from USDC to crvUSD for vlCVX delegation rewards (saw users wondering about it in discord), or when partnerships are announced under Paladin without being discussed first.

If I’m not mistaken the loan has been unwinded before this proposal was written, so I guess you forgot to update this before posting ?

8 proposals were voted over Q3, which makes an average of 2 proposals every two weeks which is twice less than what you said.

  • Not sure how your proposal enables timing of low gas costs ?

  • 1 proposal every 14 days based on Q1 2024*

  • We do need a grant framework but this isn’t a reason to change everything

  • Not sure how I should take this, but imo the reason for failing to attract other skilled contributors is the lack of recognition & compensation for anything made in the DAO.

  • Wdym by transparency framework ?

If you mean something like Coordinate enabling contributors to self report their actions, there were a few attempts of setting this up but simply not enough interest from the community.

  • On that note it’s very surprising as people could have expressed it on the forum, but something that could be worked on would be an onboarding process to get more people involved, what do you think ?

The signers framework was approved recently, so I am struggling to understand the rationale behind this. We know finding available & knowledgeable signers is hard and agreed that all good ones should remain if they accept, so this should not be changed imo.

Moreover, this is not the first time that the core team is posting another proposal on a topic already discussed/voted on but proposed by someone else to simply change everything (Happened in the past with a PGM which was just ignored & replaced by PGM-31 written by the core team) and concerned that councils will only increase this.

The above points lead me to think that approving this proposal will lead to centralizing decisions made by a small group of people rather than improving decentralization.

I’m strongly against this drastic reduction, but I do agree that councils could have defined scope where they can act freely, in which case it needs to be detailed in this proposal. .

What do you mean by “are held accountable” ?

Writing a monthly report doesn’t change the fact that they will be responsible in case they take a bad decision, which might already be too late to react. The responsibility of taking such decisions shouldn’t be on a few people only, especially if no concrete action can be taken in case of an issue.

Also struggling to understand how this would improve efficiency considering it requires more work for the delegates (need to go through everything that happened over the month, might require to verify stuff on chain without always the good context etc), and most importantly it might just be too late to react.

It also increases the task of signers / committee members which now have to write very detailed reports in addition to managing daily ops, which in the end doesn’t change much since the majority of ppl commenting on the forum are the delegates (& the core team).

Finally, it increases the friction for people to participate in governance by integrating solutions like oSNAP which, from my understanding, is great from a decentralized pov but requires technical skills to implement a payload & funds available to bond, in addition to required voting power, to post a proposal.

I believe implementing a solution like oSNAP would require a detailed explanation of its functionment & changes it will make in the proposal creation process, as it will create a barrier at governance entry.

I disagree here as this goes against improving efficiency since it prevents 3 of the most active community members from continuing their contributions since we all are both delegates & signers. (One of them actually announced to leave Paladin right after this proposal was posted btw).

Agree on this part, we need a clear compensation framework for contributors.

Fully agree on increasing signers compensation, this should have been done a long time ago imo.

However it doesn’t make sense to ask delegates for more work but for the same compensation, in addition to preventing them from being part of the committees, limiting their contributions.

TL;DR:

I support:

  • To improve gov framrwork by creating a compensation framework,
  • To create an onboarding process for newcomers,
  • To consider oSNAP/SafeSnap implementation if a detailed explanation is shared and if not too complex for the majority,
  • To define clear scope & budget for each council proposed, enabling to reduce yearly vote amount when possible
  • To increase signers compensation
  • To have “lead positions” in the council (specialized) and simple signers

I don’t support:

  • To completely change the governance framework
  • To drastically reduce voting opportunities
  • To create a entry barrier for people that want to make proposals
  • To prevent delegates from contributing to the councils
  • To request more work from delegates but for same compensation
  • To bypass the rotation framework approved to do a fresh election

Not a fan of reducing multisig thresholds to 4/7 as I believe it works well with the current setup when we have active signers, but no strong opinion about it.

I would have voted “Rework Proposal” but the option isn’t available so I’ll vote against it if this proposal is submitted in its current form.

Moved the topic to a research discussion, and will summarize into a proposal at it looks like the private feedback we got as well as current details are insufficient in order to push a vote.

This is lacking in the current setup. In general the hard part about these is they are easily gameable.

It is not, that is the whole problem, added to the lack of contribution framework, this makes particapating at Paladin close to impossible for newcomers.

Most people discussing it are riddled with conflicts of interests or not skilled enough to participate, treasury mangement should not be a beauty contest,

Third time I remind you that delegation is not a Paladin product, it is strictly operated by our company. Curious to see what partnerships you are refering to…

Giving swap or vote privileges with Gnosis Guild to one/ two / three councilors would enable them to push the transactions in a much more targeted fashion

I’m not sure how saying 2 or 3 skilled contributor is insufficient is an insult to you…

Transparency Template - Google Docs as posted in the proposal, nothing to do with Coordinape

We wrote the signing restructuring and realised it didn’t fix the problems highlighted, how is that abusive? We’re trying to empower signers into something more because the current setup is clearly insufficient.

Working on a more accurate draft, but the whole idea is that councilors manage less assets than current signers but with much more immediate authority. In exchange they get paid more for carrying more liability. This means they have less damaging power but more effective means, while being removable by DAO. Accountability here is meant by the fact that a councillor can lose his sit if he does not do his job well, he can also face legal consequences for his shortcomings if it comes to this.

It very much should as otherwise no one really takes the responsibility, this has happened on every single wrong decision taken here.

It is not more work since you don’t have to read as many proposals. You keep saying such system will be to late in reacting to mistakes but I would love examples as the council would not have the authority to do large actions without direct and explicit DAO validation.

It’s not like we do more than 30 tx a month, and not all signers have to justify the one, just its creator. We’re talking about swapping fees and voting in gauges.

We are open to any other solution but I will personally push with all my might to make at least partial decentralisation to happen in the next 3 months, Regulatory environment is tightening and we need to accelerate in effective decentralisation and automation.

[quote=“Dydymoon, post:11, topic:548”]
I believe implementing a solution like oSNAP would require a detailed explanation of its functionment & changes it will make in the proposal creation process, as it will create a barrier at governance entry.

Nom they can do both, just not be paid for both. If you can’t admit that mandate accumulation is nefarious for an organisation, then I’m not sure what will convince you, it should be pretty obvious.

This is not for signers, it’s for councillors, we pay more because we expect more.

Much less assets will be in this multi sig.

Hey, Bobbay from UMA here. Glad to see this come to fruition. I already provided my feedback before it was posted on the forums. I want to leave a comment on oSnap since I’ve seen a couple of questions pop up and also highlight our features that have made it the leading optimistic governance tool used by DAOs like Arbitrum, Gitcoin and others.

Finally, it increases the friction for people to participate in governance by integrating solutions like oSNAP which, from my understanding, is great from a decentralized pov but requires technical skills to implement a payload & funds available to bond, in addition to required voting power, to post a proposal.

  • Technical skills to implement a payload
    • The transaction builder has pre-built templates such as sending funds and transferring collectibles which do not require any technical skills
    • A more complex TX will require creating a custom payload. More importantly, this payload will eventually have to be created, whether by the SAFE signers (in the current process) or by someone else who proposes the proposal (using oSnap). The SAFE signers can also do this to assist the proposer, if needed.
  • Funds available to bond
    • UMA has bots that validate valid oSnap-enabled Snapshot proposals and propose them to the optimistic oracle covering the gas cost and proposer bond. This is unique to oSnap.
    • The bot has no special permissions so anyone can dispute the proposal, if necessary. After the optimistic oracle has validated the oSnap proposal, we also cover the transaction execution.
    • This service makes governance decisions that go through oSnap automated and free for the DAO.
  • Voting power to post a proposal
    • This has to do with snapshot settings and less with oSnap.

Monitoring and Security:

We have heard from many DAOs that constantly monitoring governance modules to catch malicious or bad proposals is difficult. Therefore, we have focused resources on combining an automated and manual verification process for each Snapshot proposal to alleviate the burden from integrating DAOs:

  • Automated verification consists of a monitoring bot developed and run by UMA and third parties. This bot monitors for invalid proposals and automatically disputes them. Correct disputers are financially rewarded from the proposer’s bond, so there are also third-party verifiers that run bot instances. Here is detailed documentation that makes the bot setup process straightforward.
  • For manual verification, UMA sponsors a verification program that pays UMA community members to verify all optimistic oracle assertions. When any transactions are proposed through oSnap, a Discord ticket is created and a trained verifier from the UMA community completes a multi-step verification process that focuses on areas such as the transaction payload matching the intent of the proposal, ensuring transactions do not include interactions with malicious contracts, etc.

Continuous development and improvement:

UMA is focused on adding new features and improvements to oSnap. We recently launched a Safe app that improves the deployment UX, made improvements to the transaction builder, and Tenderly simulations to simulate transactions before included in a proposal and make it easy for voters to simulate before voting. Some of these features, such as Tenderly simulations, are not available to Reality users.

oSnap Workflow

oSnap is a module that is added to a Safe with rules on how to evaluate a Snapshot proposal. oSnap Safe app lets you add oSnap to your Snapshot space and Safe in a few minutes with no developer time required. A video demonstration of the oSnap Safe App can be viewed here.

Once enabled, Snapshot proposals related to the distribution of funds from the Paladin Safe can include transaction data with the proposal (details below). After a successful Snapshot vote, the transaction is proposed in Safe (put onchain) and verified by UMA’s optimistic oracle before being executed by the Safe.

The updated Snapshot flow for proposals would be:

  • An oSnap enabled Snapshot proposal is created. This process is the same as a normal Snapshot proposal with the addition of transaction data that will be verified and executed if the proposal passes. The Snapshot transaction builder is specifically designed to make it easy to create and verify transaction data for token transfers.
  • hPal holders vote on the proposal like any other Paladin Snapshot proposal
  • If hPal holders approve the proposal by vote, any address can post a bond (2 WETH) for a challenge period (1 to 3 days) and propose to execute the transactions onchain. UMA has implemented a bot that validates proposals (vote passed, meets min voting period/quorum) and posts the bond for DAOs along with covering gas costs for execution (there are no fees to use oSnap).
  • If no dispute arises about the proposal’s accuracy during the challenge period, the transactions can then be executed.
  • In case of a dispute, the proposal is not executed. UMA token holders vote to resolve the dispute, with the correct party rewarded from the opposing party’s bond. This bonding and dispute mechanism punishes incorrect proposers and disputers and incentivizes honest disputes. Any proposal that was incorrectly disputed can be re-proposed to the oracle for execution without requiring revoting. It is important to note, the dispute resolution decided by UMA token holder votes are not deciding if the transactions can be executed or not, only the bond allocation between the proposer and dispute.

If anyone has any further questions on oSnap, feel free to @ me here

3 Likes

Hello @bobbay , thanks a lot for the detailed feedback !

There are a few points I discovered in your answer & other I might have misunderstood so got a few more questions:

Yes that’s what I had in mind, the issue is that in practice it’s quite rare to have a proposal executed for simple actions like transfers of tokens or collectibles. Moreover with the creation of councils, these will probably be included in their scope so not requiring a proposal.

There are some for sure (even though we have some payments approved but delayed in time), but most of the proposals include more complex transactions such as providing/removing liquidity, bridging, assets swapping etc, which are also time sensitive.

Good to know thanks wasn’t aware of this, it indeed reduce the entry barrier.

Not sure I understand this part. Sounds like the UMA bots are covering the entire cost, which makes sense for the gas cost since it’s executing the transaction, but how is it covering the proposer bond as it’s needed to push an oSNAP enabled proposal, which are the only ones tracked by the bot ? Do you mean it’s refunded to the proposer ?

Also, if bots are monitoring everything, is it common in practice that individual disputers (external to UMA communities) dispute proposals ?

Of course, I meant that implementing oSNAP or another tool would add additional restrictions on top of the current one being an amount of hPAL held or delegated.

Just to make sure I got this right, it means that if bots runned by UMA are disputing first, they will earn proposer the proposer bonds if they are correct right ?

Good to know thanks ! Does it happen before/after/at the same time as automated verification, or is it either one verification method or the other ?

Wdym by Reality users ?

A few questions here:

  • Is there a reason for the 2 WETH bond ? Assuming it’s the same amount as the proposer bond, seems a massive amount that not everyone might have or want to risk for a proposal
  • How is defined the duration of the challenge period if variable ? Assuming if the max is 3 days, then anyone can dispute in the following 72h after the proposal was accepted, but how can it be 1 day ? Does the challenge period end when one or several disputes happen and if at least 24h passed since approval ?
  • Does UMA have a solution to handle dynamic quorums ?

Asking because Paladin governance framework has several proposal categories with specific parameters depending on importance level, however since Snapshot doesn’t handle dynamic quorums, the only solutions are either to update settings manually before each proposal, or calculate the right quorum when each vote starts & post it on the forum (which is what I’m doing atm, but hard to track it with oSNAP as the quorum on snapshot is always wrong). Voting duration are also different but this is easier to track

Also, worth mentioning that if the challenge max duration is 3 days, it has to be taken into account when submitting proposals, which already have a discussion & voting period before execution.

However, it’s really interesting. There seems to be several improvements on oSNAP since last time I checked, I will play around with it on a test space & might come back with more questions.

Dynamic quorums are now on Snapshot: snapshot/src/composables/useQuorum.ts at 95a87b58805a508a7b6f1f3b6ef9b3483bc6c5d2 · snapshot-labs/snapshot · GitHub
We are working on its implementation

1 Like

Hey @Dydymoon, thanks for the questions, I have answered them piece by piece below. Let me know if you have any further qs

Yes that’s what I had in mind, the issue is that in practice it’s quite rare to have a proposal executed for simple actions like transfers of tokens or collectibles. Moreover with the creation of councils, these will probably be included in their scope so not requiring a proposal.

There are some for sure (even though we have some payments approved but delayed in time), but most of the proposals include more complex transactions such as providing/removing liquidity, bridging, assets swapping etc, which are also time sensitive.

For building complex transactions, the Snapshot transaction builder includes an option for contract interactions where you input the contract address and it imports the ABI and provides the required arguments. It also allows you to import transactions created in the Safe transaction builder and simulate transactions using Tenderly before the proposal is published. We have had several DAOs give us feedback that non-technical members of the team have had positive experiences creating and verifying complex transactions.

In terms of time-sensitive transactions, waiting for the challenge period to be completed is a requirement for transactions that use oSnap. For this reason, several integrations have alternative execution methods (multisig signers) if transactions can not wait for a Snapshot vote and challenge period.

Not sure I understand this part. Sounds like the UMA bots are covering the entire cost, which makes sense for the gas cost since it’s executing the transaction, but how is it covering the proposer bond as it’s needed to push an oSNAP enabled proposal, which are the only ones tracked by the bot ? Do you mean it’s refunded to the proposer ?

Also, if bots are monitoring everything, is it common in practice that individual disputers (external to UMA communities) dispute proposals ?

After the Snapshot voting period is completed, for transactions to be proposed it requires anyone to post a bond (2 WETH) for the length of the challenge period. Assuming the proposal is valid, the bond is held until after the challenge period when the transactions are executed the bond is returned to the proposer.

Therefore, the bot does not have any special permissions. The bot is verifying the Snapshot proposal is valid and posting the bond for the transactions to be executed so that the team/community does not have to. For your questions on external disputes, oSnap proposals are proposed to the same oracle contract that other UMA integrations (Polymarket, Across, insurance integrations, etc) so there are many external validators and it is common to also have external disputes.

Just to make sure I got this right, it means that if bots runned by UMA are disputing first, they will earn proposer the proposer bonds if they are correct right ?

Yes, the first individual that disputes an invalid proposal will receive the proposer bond. That being said, challenge periods for oSnap are conservative (1-3 days) and the bot polls every 5 minutes so we do provide a window to encourage third-party disputes before the UMA bot disputes.

Good to know thanks ! Does it happen before/after/at the same time as automated verification, or is it either one verification method or the other ?

The verification process happens in two stages:

  1. When a Snapshot proposal is created verifiers ensure the transactions aren’t malicious, transactions meet the intent of the proposal, etc.
  2. Once the voting period is over and transactions are proposed, verifiers ensure the transactions proposed match what was approved by the Snapshot vote, the vote results meet the minimum quorum/voting period, the majority is in favor, etc.

While there is overlap between the bot and manual verifiers, this is intentional to ensure accuracy.

Wdym by Reality users ?

DAOs that have enabled Reality.eth which is an alternative onchain execution method that utilizes the SafeSnap plugin in Snapshot.

Is there a reason for the 2 WETH bond ? Assuming it’s the same amount as the proposer bond, seems a massive amount that not everyone might have or want to risk for a proposal

While other UMA integrations use a smaller bond amount, we feel 2 WETH is an appropriate amount for oSnap to prevent malicious transactions proposed on DAO treasuries where some have over $100 million of assets in their Safe. This is also part of the reason UMA posts the 2 WETH bond on behalf of DAOs. We want DAOs to have the security of a higher bond value while also alleviating the burden of teams/communities required to risk funds when a governance decision is approved.

How is defined the duration of the challenge period if variable ? Assuming if the max is 3 days, then anyone can dispute in the following 72h after the proposal was accepted, but how can it be 1 day ? Does the challenge period end when one or several disputes happen and if at least 24h passed since approval ?

While we recommend using a value between 1 and 3 days, the challenge period is a configured value on the oSnap module contract that can be customized. The challenge period starts when the transactions are proposed.So the typical timeline is:

  • Snapshot proposal created
  • Snapshot voting period ends
  • If the Snapshot proposal is valid, transactions are proposed which starts the challenge period
  • During the challenge period, anyone can dispute an inaccurate or malicious proposal
  • If nobody disputes during the challenge period, the transactions can be executed. If someone does dispute, the proposed transactions are deleted and the transactions can be proposed again. It is important to note that if someone disputes a valid proposal, the Snapshot proposal does not need to be voted on again and you do not have to wait for UMA voters to resolve the dispute before transactions can be proposed again. This is intentional to make it costly for attempts to delay transactions from being executed.

Does UMA have a solution to handle dynamic quorums ?

Thanks Figue for pointing out the dynamic quorums. Let me follow up on how this feature could be configured with oSnap.