This proposal is published for community feedback by @AK_HoG on behalf of the proposal author @UhthredB, as requested.

Frontmatter

hsp: TBD
title: House of Stake - Conflict of Interest Policy
description: Check readiness to ratify Conflict of Interest Policy
author: @UhthredB
discussions-to: this post
status: Draft
type: Decision
category: Legitimacy & Engagement
created: 2025-11-29
requires: HSP-001

Abstract

This proposal establishes a comprehensive Conflict of Interest (COI) policy for the House of Stake, ensuring transparent, impartial, and trustworthy governance. It defines conflict categories, outlines disclosure and recusal requirements, provides practical examples, and sets enforcement and review procedures to uphold integrity, and accountability across all governance activities.

Conflict of Interest Policy
Version: v1.0
Audience: all House of Stake Governance members, such as Delegates (both endorsed and otherwise), community members, and all individuals empowered to participate in or influence decisions arising from the House of Stake.
Archive: House Of Stake Foundation- Conflict of Interest Policy (v1.0 Draft), v0.3 (Public Feedback collected)

Conflict of Interest Policy

Context & Alignment

• [HSP‑001] defines that “The author(s) must state that they’ve read and agree with the House of Stake Conflict of Interest policy, and must state any conflicts of interest, if relevant.”
• This proposal codifies a clear, practical Conflict of Interest (COI) policy. It does not modify existing budgets or operational structures but strengthens governance norms by introducing consistent disclosure, recusal, and documentation practices. By situating this policy within existing governance structures, the proposal ensures that all Delegates, contributors, and participants in HoS decision-making operate under shared expectations that reinforce the integrity of the entire ecosystem.

Situation

- What problem are we solving?

As the House of Stake (HoS) assumes broader governance responsibilities, Delegates or other governance members increasingly face decisions that may intersect with personal or professional interests. Without a standardized Conflict of Interest (COI) framework, disclosures and recusals are inconsistent, creating uncertainty and exposing HoS to risks of perceived or actual bias.

- What happens if we don’t address it?

Failure to act could undermine decision legitimacy, weaken community trust, and increase the likelihood of disputes or accusations of favoritism. Establishing a clear COI policy now ensures consistent expectations, protects governance integrity, and maintains confidence in HoS decision-making as its scope expands.

Mission

The mission of this proposal is to establish a clear, consistent Conflict of Interest framework that protects the integrity of House of Stake (HoS) governance. It aims to ensure governance members can identify, disclose, and manage conflicts effectively; safeguard decision-making from undue influence; and maintain community trust through transparent and impartial processes.

Approach

This proposal introduces a standardized Conflict of Interest framework using a clear 2×2 matrix to classify actual and perceived conflicts. It establishes consistent requirements for disclosure, recusal, and documentation across all HoS governance activities. The Security Council/Screening Committee will review cases, provide guidance, and enforce compliance. The policy prioritizes transparency, minimal disruption to decision-making, and alignment with established NEAR governance values while acknowledging limitations such as reliance on self-reporting and the need for ongoing updates as governance evolves.

Technical Specification

This proposal formally adopts the House of Stake Conflict of Interest Policy and makes it binding for all HoS governance members.

Core Requirements

Disclosure: Members must promptly disclose any actual, potential, or perceived conflict of interest.

Recusal: Members with a conflict must recuse from related discussions, deliberations, and voting.

Documentation: All disclosures and recusals must be recorded in official HoS records and made publicly accessible.

Review: The Security Council / Screening Committee evaluates disclosures and may require recusal, mitigation, or further action.

Ongoing Updates: Members must update disclosures as circumstances change.

Implementation

The 2×2 COI matrix becomes the standard decision-making guide.

The recusal process outlined in the policy becomes mandatory.

Violations are subject to disciplinary measures, including removal.

Backwards Compatibility

Although no protocol or contract changes and no on‑chain parameters are affected. It is important to note the compatibility with foundational governance assets -such as the Constitution & policy Charters.

Milestones

KPIs

Budget & Resources

Reporting: A review report will be published before 1 December 2026, including any recommended amendments or updates based on newly ratified governance policies.

No funding is requested under this proposal. Should ratification occur, any future operational needs will be addressed through separate follow-up proposals aligned with the Milestones.

Implementation

• The Conflict of Interest (COI) policy will automatically enter into force 7 days after ratification and Security Council approval.
• Publish the Conflict of Interest Policy in the official House of Stake governance repository.
• Notify all Delegates and governance members of the policy’s activation date.
• Require all Delegates to publish an initial COI disclosure within a defined timeframe.
• Integrate COI disclosure and recusal procedures into existing voting and proposal workflows.
• Update meeting templates to include a standing COI disclosure item.
• Enable documentation of disclosures and recusals in public governance records.
• Assign the Security Council / Screening Committee responsibility for reviewing disclosures and advising on recusal cases.
• Incorporate the COI framework into onboarding materials for new Delegates, governance members and community members.
• Begin continuous monitoring and update the policy based on governance feedback and yearly review.

Team & Accountability

• Accountable: House of Stake, Screening Committee, Head of Governance.

Security Considerations

Establishing a clear Conflict of Interest policy strengthens governance security by reducing risks of undue influence, insider advantage, or compromised decision-making. Transparent disclosure and recusal requirements limit opportunities for bad actors to manipulate outcomes or obscure personal benefit. The mandatory documentation and Security Council oversight further ensure issues are detected early, investigated consistently, and resolved before they impact protocol integrity.

Conflict of Interest

The proposal author is @UhthredB and declares no conflicts of interest related to this proposal.

This proposal is published for community feedback by @AK_HoG on behalf of the proposal author @UhthredB, as requested.

Copyright

Copyright and related rights waived via CC0 1.0.

Authorship & Acknowledgements

Authored by: @UhthredB
Review and feedback from: House of Stake community and delegates, @AK_HoG

A standardized, canonical disclosure location or form would prevent fragmentation across verbal comments, proposal threads, Delegate profiles, and meeting notes. This would strengthen consistency, auditability, and long-term governance memory.

Additionally, if a conflict emerges after initial discussion but before the final vote, is the update posted on the proposal thread, the central registry, or both?

This is a very well-thought-out and well-executed piece of work , I really like the proposal! And it comes across as strong and solid. That said, there is one point that may be worth clarifying or refining , not necessarily now, but perhaps in the future.

The instruction: “Document this publicly.”

AK_HoG:

3. Documentation

All disclosures and recusals are to be recorded in the House of Stake’s official records and made available for review by stakeholders.

It’s not entirely clear how exactly this public documentation should take place, where it should be posted, or in what format.

A similar ambiguity appears in the following section:

AK_HoG:

House of Stake Governance members are required to update their disclosures as new conflicts arise or existing circumstances change.

It would be helpful to clarify in which specific records or repositories this information should be located, and what the process should look like in practice.

Thanks @Othman and @haenko, for flagging open points.
I suggest we update the proposal and process instructions with more specific information, I opened a ticket on Github.

I support the ethos of this proposal and particularly the addition of the 2x2 COI matrix, milestones and the KPI’s. However, I do some see some additions that should be considered to make it more specific and strengthen it’s useage:

• The intent is for each participant in the community to disclose, communicate and even if necessary, recuse themselves from the conflict, however, there is no language to address what if a community member (knowingly or not) violates the COI. The proposal states that the Security Council/Screening Committee may require further action, but it’s not specific on the process other than it may include removal, but removal from what, if it’s a delegate, there is no auto-undelegator governance contract that I’m aware of, and only a ban from the forum and TG group could be enforced. And if the offender is removed, is it final (and for what length of time) or does the offender have any recourse (i.e. an Ombudsman)? Unfortunately I’ve seen this attempted without success in another DAO community, and the removed offender just changed wallet addresses and forum profiles.

AK_HoG:

Review: The Security Council / Screening Committee evaluates disclosures and may require recusal, mitigation, or further action.

• I have concerns that this proposal lists both the Security Council/Screening Committee with the responsibility to review COI violation cases, etc. This feels outside of the scope of the Security Council, and should be the sole responsibility of the Screening Committee.

• This proposal should include in the list of examples for Article IV: Examples - that for any member of the Screening Committee who oversees or participates in a COI review or decision of an offending community member, that the SC member must disclose and recuse themselves, if they have a COI Yellow Light or Red Light level relationship with that individual.

Thanks for sharing your comments @coffee-crusher.

I have concerns that this proposal lists both the Security Council/Screening Committee with the responsibility review COI violation cases, etc.

This proposal should include in list of examples for Article IV: Examples

Valid points! Before I comment further, I’ll let Uthread respond, as he has been drafting this COI policy based on extensive community feedback and may have good reasons for structuring it this way.

@UhthredB , please take it from here.

Thanks so much for the response, and I appreciate @UhthredB viewpoint on these points. Tks!

This is solid work, clear structure and practical guidance for participants.

But I want to flag a tension most DAOs face: the people who create the most value often have the deepest ties to the ecosystem. They advise teams, build products, drive partnerships. Under strict COI rules, these ties become conflicts. But these are often the exact people the community wants involved because of their experience and alignment.

Example: Should a large NEAR holder be forced to abstain from Council decisions just because of their stake? Doesn’t that remove influence from those with the most conviction and skin in the game?

The tradeoff:

• Too loose → unchecked conflicts to game for cash grab on expense of the project

• Too strict → you push out your most capable, aligned contributors

The policy is strong. But consider adding:

• Ways to participate at reduced levels instead of full abstention

• Clarity on when “skin in the game” is alignment, not conflict

• Guidance for contributors who wear multiple hats in good faith

We don’t want to accidentally discourage the high-context people who make governance work.

Well said @Zeptimus , this gets to a core DAO tension.

Strong contributors often have deep ecosystem ties, and at a certain level that’s unavoidable. In fact, general incentive alignment is a strength: people with skin in the game, context, and conviction are best positioned to shape our strategy to make NEAR successful.

At the same time, not all decisions are equal. That’s where case-by-case COI handling matters.

• For high-level decisions (strategy, roadmap, budget frameworks), participation from aligned stakeholders is key. Alignment here is not a conflict, it’s a superpower: It protects HoS from capture by short-term or ill-motivated actors.
• For specific decisions (like funding proposals, direct benefits), conflicts need closer scrutiny.

The key to addressing COI in DAOs is distinguishing healthy alignment from situations that require careful handling, rather than treating all interests as conflicts.

haenko:

It’s not entirely clear how exactly this public documentation should take place, where it should be posted, or in what format.

Check the section under “Section A: COI Disclosure Templates”

House Of Stake Foundation- Conflict of Interest Policy (v1.0 Draft)

All disclosures must be public either via the official COI Portal or through the Governance Forum and logged into the Conflict Registry (as per Article 6).

coffee-crusher:

however, there is no language to address what if a community member (knowingly or not) violates the COI

Refer to Article 5 - Enforcement

Screenshot 2025-12-22 at 4.24.36 PM1682×696 66.6 KB

coffee-crusher:

I have concerns that this proposal lists both the Security Council/Screening Committee with the responsibility to review COI violation cases, etc. This feels outside of the scope of the Security Council, and should be the sole responsibility of the Screening Committee.

The primary arbitrator for COI policy infractions is indeed the Screening Committee - the duty is delegated to Security Council when-
a) The Screening Committee members are themselves conflicted out from the review.
b) Appeals (appeals are never to the same decision makers)

Refer the chain of escalations here

House Of Stake Foundation- Conflict of Interest Policy (v1.0 Draft)

On the subject of sanctions, the discretion of tiers falls under the authority of the Screening Committee, the Security Council, or the Third Party Auditor (in case of the first two conflicting with the complaint).

coffee-crusher:

This proposal should include in the list of examples for Article IV: Examples

Refer:

House Of Stake Foundation- Conflict of Interest Policy (v1.0 Draft)

There is a guideline for discovery attached in the Addendum B with more than 21 working examples for voting and working group participation. This was reduced from 40 in the initial draft. Having said that, if the HoS DAO intends to spend resources on focused CoI training based on this Policy, I would be happy to conduct it as a separate effort. This contribution is about policy drafting - it is not fair to commission a mandatory training as part of a policy drafting experience, most often these are two separate functions.

Read the complete feedback loops with the original draft - most of these questions have been posed and answered before..

Zeptimus:

Example: Should a large NEAR holder be forced to abstain from Council decisions just because of their stake?

COI policy mechanisms are all about ‘decisions at hand’ - regardless of stake, if the decision maker has a COI (as defined in the policy) to a specific decision at hand, they should abstain.

Zeptimus:

Clarity on when “skin in the game” is alignment, not conflict

If a proposal at hand is about ‘personal enrichment’, no amount of ‘skin in the game’ means ‘alignment’

Zeptimus:

The policy is strong. But consider adding:

• Ways to participate at reduced levels instead of full abstention
• Clarity on when “skin in the game” is alignment, not conflict
• Guidance for contributors who wear multiple hats in good faith

‘levels of abstention’ should be a function of ‘levels of COI’, refer to “Section B: Guidelines for Interested Persons to Determine COI” for more details.

House Of Stake Foundation- Conflict of Interest Policy (v1.0 Draft)

All disclosures must be public either via the official COI Portal or through the Governance Forum and logged into the Conflict Registry (as per Article 6).

The idea of an official COI Portal looks really interesting, and I’d like to understand it better from your perspective. How do you imagine such an official COI Portal should look, where do you think it should be located, and does it make more sense to integrate it into the main HoS frontend, or to build it as a separate website?

I’d also really appreciate it if you could share a couple of examples of COI portals or similar solutions that you’re familiar with, just for general context. Thank you!

I understand the need of having clear COI policies and overall support this proposal, but I do have some concerns that I would like to point out here.

This type of policy is hard to fiscalize and thus enforce if the violating party wants to deliberately hide conflicting interests.

So, in general, it accompĺishes very little other than being a good-faith guide for honest participants, which is already valuable in itself but limited in preventing malicious actors from acting with conflicting interests.

So, I don’t think it makes sense to establish penalties, other than reputational losses.

While bad-faith participants will still be able to hide COI indicators and participate in decisions they probably shouldn’t (avoiding the penalties), good-faith actors would have recused themselves already even if there are no penalties established. Moreover, good-faith actors are still prone to making honest mistakes and fail to identify or disclose COI, being subject to being removed from the governance.

If this logic applies ad infinitum, we will eventually have a policy that will, in theory, remove good-faith participants who made honest mistakes and keep/attract bad-faith, corrupt actors that are skilled in hiding their COIs.

It has the potential of creating a highly corruptible environment, where skilled corruption is rewarded and honest participants are excluded from the process.

One example, in particular, concerns me the most, which is:

AK_HoG:

Red Light: Actual Conflict + No perception of COI

(…)

1. You own tokens/equity in a project that is the beneficiary of an HoS proposal.

This one establishes no holding size and it may affect most, if not all, of the active, honest participants. I, for example, hold very small shares of tokens from projects with the intention to show support (even if financially negligible) to NEAR ecosystem projects, but I don’t think these would really offer any significant COI while making decisions for these projects and I’m sure I could objectively make a good decision whether favorable or not regarding them.

On the other hand, malicious competitors who would like to weaponize HoS (acting in bad faith) could easily do that anyway.

My proposal is:

1. to remove this quoted item from the example or establish clear thresholds for token/equity holding (% of portfolio, $$ amount, etc)
2. remove any type of penalty for offenders and, instead, understand COI policies as a good-faith guideline to honest participants instead of an enforceable regulation to prevent bad-faith users and deliberate corruption from happening (as I don’t think it would actually work for the latter).

AK_HoG:

@UhthredB , please take it from here.

Apologies for the delay Angela, I wasn’t paying attention to the Forum - please dm next time for a faster TAT

vinibarbosa:

I understand the need of having clear COI policies and overall support this proposal, but I do have some concerns that I would like to point out here.

This type of policy is hard to fiscalize and thus enforce if the violating party wants to deliberately hide conflicting interests.

There is no defense against ‘intentional criminals’ -otherwise there would be no murderers and drug dealers in the world- all society would need to do is institute tough negative incentives.

vinibarbosa:

So, I don’t think it makes sense to establish penalties, other than reputational losses.

Read along with the above - your suggestion is ‘slap on the hand’ - ‘because we might never catch the real bad guys and we end up punishing the good ones’

vinibarbosa:

If this logic applies ad infinitum, we will eventually have a policy that will, in theory, remove good-faith participants who made honest mistakes and keep/attract bad-faith, corrupt actors that are skilled in hiding their COIs.

If this logic applies ad infinitum, it sounds to me like ‘let’s legalise crime, as its punishments might end up causing harm to people who are not criminals/ people not as good at hiding their crimes.’

vinibarbosa:

This one establishes no holding size and it may affect most, if not all, of the active, honest participants. I, for example, hold very small shares of tokens from projects with the intention to show support (even if financially negligible) to NEAR ecosystem projects, but I don’t think these would really offer any significant COI while making decisions for these projects and I’m sure I could objectively make a good decision whether favorable or not regarding them.

This is exactly why we have a unified code - so that we don’t have to assess each human’s subjective capability for ethics. This way, all I have to believe is “he disclosed his violations,” not “he has the ability to selectively measure ethics, and so we should trust him even when he didn’t disclose his COI.”

vinibarbosa:

My proposal is:

1. to remove this quoted item from the example or establish clear thresholds for token/equity holding (% of portfolio, $$ amount, etc)
2. remove any type of penalty for offenders and, instead, understand COI policies as a good-faith guideline to honest participants instead of an enforceable regulation to prevent bad-faith users and deliberate corruption from happening (as I don’t think it would actually work for the latter).

My question is - why have a COI document at all, if you can’t/ won’t enforce?

This policy has been in public circulation since July- if it took a delegate 6 months to comment, maybe we should be focusing a bit more on the ‘code of conduct’ policy and not the COI.

haenko:

I’d also really appreciate it if you could share a couple of examples of COI portals or similar solutions that you’re familiar with, just for general context. Thank you!

The most common practise is to open a thread in the forum titled “Delegate COI thread” and socially enforce the compliace.

UhthredB:

This policy has been in public circulation since July- if it took a delegate 6 months to comment, maybe we should be focusing a bit more on the ‘code of conduct’ policy and not the COI.

I just recently started to actively study, get involved, and contribute to the NEAR ecosystem, as I was far more active in other communities (starting more or less around July).

For that reason, I also wasn’t actively participating in governance discussions before. I’m catching up.

FWIW, I didn`t ask to be a delegate and I don’t have a significant amount staked myself on HoS. Yet, someone (I don’t know who) delegated a significant amount of veNEAR to me, which put me in a relevant position on HoS and made me start to get more involved here – aiming to honor this trust and do the right thing to build a good HoS and protocol. That said, I’m still catching up with all the discussions (there are many of them). These things take time and I’m a busy person. I’m sorry if my delayed participation here causes any harm.

This one caught my attention as it was reactivated with a recent comment, so I took time to read it and share my opinion as I don’t think I can vote favorably on it as is. Can you please better explain what’s wrong about my conduct here that goes against the proposed COC?

On the other hand, I do see problematic behavior on your side, in your response both here and in the Telegram group, implying bad faith as it is “pretty weird for any delegate to say these things,” in your words, and “a pretty self serving thing for a delegate to suggest - and that too publicly.” So, please, let’s keep the civility and mutual respect so we can have a productive environment for good debate. I value my reputation a lot and I don’t think I ever gave any reasons for someone to assume bad faith from me.

UhthredB:

My question is - why have a COI document at all, if you can’t/ won’t enforce?

We can still have a COI document that is an agreed-upon guideline for COI disclosures.

This puts everyone on the same page and is a great reference point to solve conflicts or provide feedback to misbehavior, even if you can’t enforce it via a centralized committee (causing reputation loss, for example, as I said).

I don’t 100% oppose trying to enforce COI or penalizing misbehavior, though.

I just don’t think it would (as is) be effective to accomplish the goal it intends to and opens too many doors for undesired externalities to an yet maturing governance protocol, to honest participants, and to the NEAR ecosystem as a whole.

UhthredB:

This is exactly why we have a unified code - so that we don’t have to assess each human’s subjective capability for ethics.

Exactly why I think this document is valuable (see my point above). I agree with you.

Still, enforcement here could be dependent on subjectivity (from the committee) in a few cases. The “token holder” parameter being one (which is why I proposed making it more objective with clear thresholds on what classifies a conflict of interest from holding a token).

For example, do you really think that a good-reputation delegate with over 200k veNEAR delegated to them should be prevented from voting on proposals related to a ~20 NEAR hold of a token that they received unnoticed from an anonymous address and they don’t even know they have in their wallets?

I do not.

However, this COI, as is, would open this delegate for the committee’s judgment (subjective) and a potential punishment.

It’s subjective, as you pointed out, and this is not good.

UhthredB:

If this logic applies ad infinitum, it sounds to me like ‘let’s legalise crime, as its punishments might end up causing harm to people who are not criminals/ people not as good at hiding their crimes.’

If a crime punishment has the chance to cause more harm to people who are not criminals than to the criminals themselves, I don’t think they are based on well-designed policies, indeed (the case here).

We shouldn’t risk punishing good people just because we don’t know how to prevent bad people from acting. We need, instead, to improve the policies and our technology to be able to properly fiscalize/enforce actions with the lowest possible side effects against innocent/honest people.

It’s not about legalizing crime but being effective (and fair) while fighting it.

UhthredB:

Read along with the above - your suggestion is ‘slap on the hand’ - ‘because we might never catch the real bad guys and we end up punishing the good ones’

Nope. That’s not my suggestion.

I’m only acknowledging the reality here.

This policy can NOT prevent bad faith actors from acting with COIs.
Any bad actor can anonymously get large amounts of veNEAR to vote on proposals that benefit them with undisclosed COI.

This policy also opens doors for bad faith actors to exploit it and neutralize proposals (for example, an anonymous address sending non-requested tokens to delegates before a proposal is made to prevent them from participating, killing quorum).

While it has a good chance of sometimes punishing good-faith actors for many different reasons because of how the NEAR protocol (and blockchains in general) works as a permissionless and pseudonym-based environment. We must be able to acknowledge our reality so we can design solutions that effectively work for this reality and not something else.

vinibarbosa:

For example, do you really think that a good-reputation delegate with over 200k veNEAR delegated to them should be prevented from voting on proposals related to a ~20 NEAR hold of a token that they received unnoticed from an anonymous address and they don’t even know they have in their wallets?

one could simply disclose

vinibarbosa:

It’s not about legalizing crime but being effective (and fair) while fighting it.

it’s an amazing technique - you answer a rhetorical question with a rhetorical question

vinibarbosa:

This policy can NOT prevent bad faith actors from acting with COIs.

by human nature, no law can prevent a criminal from breaking it - what a great excuse for not having any laws - Delegate of the year indeed !

UhthredB:

one could simply disclose

You are not reading.
Two points to that:

1. Yes, one can simply disclose, but the example we are discussing is listed as a “Red Light” COI.
   If you read the policy, you will notice that it means this requires disclosure AND recuse to participate, which is what I was discussing and you are ignoring for some reason. My suggestion is to improve how the example is presented to improve the policy.
   What exactly are you against here?
2. My point is also that, sometimes, people won’t disclose holding a token XYZ not because they don’t want to but because they didn’t even know they were holding such a token. As I explained and you quoted (but ignored, again, for some reason), in crypto anyone can send anyone any token, anonymously, without prior notice. And unless you are a low-frequency user or are checking your wallet daily for dust, these things can go unnoticed, which is extremely hard to prove and can cause unintentional side effects or, even worse, be weaponized against delegates or the proposals, preventing quorum from being reached. I don’t think this is desirable, which is why I’m proposing a fix.
   What exactly do you disagree with here? Be specific.

UhthredB:

it’s an amazing technique - you answer a rhetorical question with a rhetorical question

I’m not exactly sure what you are trying to imply here. Can you be more specific?

Looks like another attempt to flee from the debate with some sort of logical fallacy. So, please let me know if I’m wrong and why.

You derived my argument as a “let’s legalise crime.” I said, as you quoted: “It’s not about legalizing crime but being effective (and fair) while fighting it.”

My argument stands.

UhthredB:

by human nature, no law can prevent a criminal from breaking it - what a great excuse for not having any laws - Delegate of the year indeed !

This is, again, a nonsensical derivation.

I never said we shouldn’t have any laws (or a policy).

I only said we should have good laws (or policies) that are effective in what they intend to do.

It also seems that you are intentionally misunderstanding my arguments and cherry-picking quotes out of their context to launch (again) personal attacks against me in some sort of a sick obsession and ad hominem: “delegate of the year indeed,” also considering your messages in the HoS Telegram group.

I’m all in for seriously discussing the proposal to improve the COI Policy before it goes for voting.

I’m certainly not here for childish personal drama.

So, please, behave. Here is not the place for that.

This is not a personal matter to me (although it seems personal to you for some undisclosed reason).

Thank you so much @UhthredB for your response and the reference to Article 5 and the Addendum, I really appreciate you help. I have reviewed the current draft again in light of your comments, and I believe we have an opportunity to move this proposal from a social policy to a more operational standard that will withstand any potential future violations.

I want to echo the technical concerns raised by other delegates regarding the “Red Light” category and the overall operational viability. My intention as others, is to ensure that this proposal is the strongest possible version for the HoS, as I suggest we consider incorporating the following specific improvements:

1. Mitigation of Technical “Weaponization” (The “Dusting” Issue)- I agree with @vinibarbosa that the current 2x2 matrix is missing a critical technical nuance. In Web3, the mere presence of a token (which can be sent unsolicited to any public wallet) cannot be the sole trigger for a mandatory “Red Light” recusal.

I suggest we add a “Safe Harbor Clause” to Article IV. If a member immediately discloses an unsolicited asset and commits to a “Neutrality Period” (e.g., 30 days), they should remain in good standing. This protects the DAO’s quorum from being manipulated by external “dusting” attacks.

2. Bridging the Enforcement Gap (Article V & VI) - While Article 5 describes “who” evaluates conflicts, it remains silent on the “how.” As noted previously, we lack an auto-undelegator contract. Without a technical enforcement layer, the policy relies on social pressure which can be inconsistent.

We should include and explicitly define the mechanics of removal. If technical enforcement isn’t possible today, the policy should mandate a “Formal Notice of Non-Compliance” and a public “Undelegation Recommendation” to the community. This provides the functional teeth that the current social-only language lacks.

3. Strengthening the Appeals Path - To ensure the community perceives the process as impartial and to avoid committees policing themselves, we should formalize the Third Party Auditor mentioned in recent comments.

A way to do this is to codify a path for a Cross-DAO Ombudsman (a neutral small group of delegates + HoG) to audit enforcement decisions (with R&R’s & process) specifically when the Screening Committee and Security Council are both cited as having a potential conflict.

The goal here is “Secure by Design.” A policy that relies purely on self-reporting without addressing technical resilience may struggle when faced with real-world pressure. By addressing these now, we protect the legitimacy of the HoS and ensure our governance infrastructure is as strong as possible. Looking forward to help get this proposal ready for an on-chain vote. Thanks!

coffee-crusher:

I want to echo the technical concerns raised by other delegates regarding the “Red Light” category and the overall operational viability. My intention as others, is to ensure that this proposal is the strongest possible version for the HoS, as I suggest we consider incorporating the following specific improvements:

1. Mitigation of Technical “Weaponization” (The “Dusting” Issue)- I agree with @vinibarbosa that the current 2x2 matrix is missing a critical technical nuance. In Web3, the mere presence of a token (which can be sent unsolicited to any public wallet) cannot be the sole trigger for a mandatory “Red Light” recusal.

I suggest we add a “Safe Harbor Clause” to Article IV. If a member immediately discloses an unsolicited asset and commits to a “Neutrality Period” (e.g., 30 days), they should remain in good standing. This protects the DAO’s quorum from being manipulated by external “dusting” attacks.

2. Bridging the Enforcement Gap (Article V & VI) - While Article 5 describes “who” evaluates conflicts, it remains silent on the “how.” As noted previously, we lack an auto-undelegator contract. Without a technical enforcement layer, the policy relies on social pressure which can be inconsistent.

We should include and explicitly define the mechanics of removal. If technical enforcement isn’t possible today, the policy should mandate a “Formal Notice of Non-Compliance” and a public “Undelegation Recommendation” to the community. This provides the functional teeth that the current social-only language lacks.

3. Strengthening the Appeals Path - To ensure the community perceives the process as impartial and to avoid committees policing themselves, we should formalize the Third Party Auditor mentioned in recent comments.

A way to do this is to codify a path for a Cross-DAO Ombudsman (a neutral small group of delegates + HoG) to audit enforcement decisions (with R&R’s & process) specifically when the Screening Committee and Security Council are both cited as having a potential conflict.

The goal here is “Secure by Design.” A policy that relies purely on self-reporting without addressing technical resilience may struggle when faced with real-world pressure. By addressing these now, we protect the legitimacy of the HoS and ensure our governance infrastructure is as strong as possible. Looking forward to help get this proposal ready for an on-chain vote. Thanks!

Thank you very much for the follow-up comment and proposed solutions.

I agree with them and I would be ready to vote in favor of this proposal if these suggestions were applied.

*sorry, the previous comment was deleted because I replied to it without quoting the comment I was replying to, which could bring confusion. I’m still getting used to the forum structure and mechanisms.

Thanks for your response and the support on these suggestions, @vinibarbosa . I’m looking forward to more community members to add their thoughts, and that we get the strongest version of this proposal for on-chain vote. Tks!

Hi everyone,

I wanted to share that, as Head of Governance, I’ll be taking over the finalization of this proposal and getting it ready for ratification.

A big thank you to @UhthredB for the important groundwork that’s already been done, it’s been essential in getting us to this point.

The final steps, supported by @HackHumanity , will focus on:

• working through the points that have been discussed here recently, and
• aligning the document with the other constitutional documents, reporting channels, and related materials.

I’ll keep you posted as we move toward a ratification-ready version.

coffee-crusher:

1. Mitigation of Technical “Weaponization” (The “Dusting” Issue)- I agree with @vinibarbosa that the current 2x2 matrix is missing a critical technical nuance. In Web3, the mere presence of a token (which can be sent unsolicited to any public wallet) cannot be the sole trigger for a mandatory “Red Light” recusal.

First of all, “the mere presence of a token” IS NOT the “sole trigger for a mandatory ‘Red Light’ recusal.”
The conditions for the trigger are 1) ownership of tokens + 2) such project /tokens become the beneficiary of an HoS proposal

AK_HoG:

• You own tokens/equity in a project that is the beneficiary of an HoS proposal.

with this clarity of understanding

1. Let us embrace this threat vector

You are correct - I didn’t design the policy to prevent dusting attacks themselves. I designed it assuming that, once something like that happened, the enforcement authority (Screening Council- in this case) would be smart enough to see that a dusting attack is not the same as a real COI violation and treat them accordingly.

But let us model for argument’s sake that a delegate was indeed a victim of a “dusting attack” - there are two possible scenarios here

In both these cases, “dusting attack” does nothing effectively. For this “attack” to succeed (i.e harm delegates with good intentions through exposure to sanctions) - somebody still needs to file a COI complaint against the delagate to the interim screening committee consisting of @lane , @Bowen Bianca @Gauntlet and (yet to be named).

And this discretion of the Screening Council is the backstop that this policy offers for such edge cases.

If the delegate’s fear is such that -

1. somebody dusts my wallet
2. somebody files a complaint
3. The screening council apply sanctions

then the delegate is signalling a notion that the Screening Council members would somehow not be able to differentiate between a “dusting attack” and a genuine COI situation.

AK_HoG:

When a conflict is disclosed, the Security Council/ Screening Committee will gather all relevant information and, if necessary, question the involved parties. If a conflict exists, the Committee may prohibit the Delegate from voting or participating in related matters, and if necessary, recommend further disciplinary action, including removal from the Delegate position

If delegates DO NOT beleive in the objective capability/ will of the interim Screening Council to make such a relatively low effort enquiry and create a genuine outcome - the house of stake has bigger trust issues to address.

coffee-crusher:

2. Bridging the Enforcement Gap (Article V & VI) - While Article 5 describes “who” evaluates conflicts, it remains silent on the “how.” As noted previously, we lack an auto-undelegator contract. Without a technical enforcement layer, the policy relies on social pressure which can be inconsistent.

We should include and explicitly define the mechanics of removal. If technical enforcement isn’t possible today, the policy should mandate a “Formal Notice of Non-Compliance” and a public “Undelegation Recommendation” to the community. This provides the functional teeth that the current social-only language lacks.

Isn’t this limitation applicable to other governance documents as well ? How would the punitive action for a Code of Conduct policy infraction be enforced at the moment?

When the COI policy was designed, there were no other policy guidelines to lean on for scoping enforcement - that is why it rendered discretion to the structures and actors who occupy positions in such structures to come up with their own options/methods to enforce.

I agree with you in principle - as it stands, there is no smart contract enforcement option of regulatory will when it comes to COI violations. But as far as I am aware - that is the case for Code Of Conduct Policy enforcement as well ? So perhaps technical enforcement of policy actions is a different proposal altogether (and arguably more under the scope of Code of Conduct Policy) ?

The policy states ‘who’, ‘when’, ‘what’, and ‘why’ - IMO the question of ‘how’ is an altogether different, technical proposal, and arguably outside the ‘exclusive’ scope of this COI policy.

coffee-crusher:

3. Strengthening the Appeals Path - To ensure the community perceives the process as impartial and to avoid committees policing themselves, we should formalize the Third Party Auditor mentioned in recent comments.

A way to do this is to codify a path for a Cross-DAO Ombudsman (a neutral small group of delegates + HoG) to audit enforcement decisions (with R&R’s & process) specifically when the Screening Committee and Security Council are both cited as having a potential conflict.

The logical reasoning for the current escalation pathway (screening committee<security council < third party audits) has been discussed before - please see

House Of Stake Foundation- Conflict of Interest Policy (v1.0 Draft)

The 40% threshold was designed with a numerical limit of 5 people each in both the bodies. The logic being that at 40% a complaint or review could still be judged by the remaining 3 people that would have otherwise been necessary for a majority decision. Also please note that with the Screening Committee being elected and the Security Council selected- the chances of both conflicting out reduces radically.

If the intention is “to ensure the community perceives the process as impartial and to avoid committees policing themselves,” creating another committee of delegates seems hardly the answer.

I am sorry but a “Cross-DAO Ombudsman (a neutral small group of delegates + HoG) to audit enforcement decisions” CAN NOT replace the neutrality offered by an “independent, third-party auditor.”
What I would suggest instead is creating budgetary provisions in HoS Budget for community members to access an independent audit pathway faster - an ombudsman of the nature you described might be the way there.

In either case, I believe this is a follow on proposal - not a limiting factor to put this V1 COI policy document to vote at this moment.

AK_HoG:

A big thank you to @UhthredB for the important groundwork that’s already been done, it’s been essential in getting us to this point.

The final steps, supported by @HackHumanity , will focus on:

• working through the points that have been discussed here recently, and

Dear @AK_HoG - I believe I have addressed all the pain points raised in this thread, it is my opinion that the policy is ready to be voted on.

Hi @vinibarbosa @coffee-crusher @UthreadB @Zeptimus @haenko and everyone, thanks for the thoughtful engagement on the House of Stake Conflict of Interest Policy.
The discussion itself is valuable: COI is one of the most critical, and most complex challenges to address in a permissionless, pseudonymous, token-based system.

Our next GM HoS Community Call on February 12 will be dedicated entirely to this topic.

We’ll walk through the new COI policy, explain its foundations, and dive into the HoS approach in detail. Bring your questions, comments, and perspectives. We’re looking forward to the discussion!

Join us on February 12 at 7 PM UTC
Link: Join on Google Meet

This Proposal is deprecated and will continue at: HSP-XXX: NEAR House of Stake Conflict of Interest Policy