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:
I’ll keep you posted as we move toward a ratification-ready version.
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
with this clarity of understanding
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
This is a real possibility as most wallets hide “dust” from UI. In this scenario - the delegate has nothing to worry, as he/she is a) not aware of any potential COI b)has no credible incentive to vote “yes/no” c) and hence no compliance/ disclosure burdens (as derived using common logic).
If a potential attacker wants to “weaponise” this “attack”, he will still have to file a COI complaint against the delegate in question with the Screening Committee. The burden of proof is on the plaintiff and not the defendant. The delegate was truly not aware of any exposure and has nothing to worry about when it comes to their governance actions.
Regardless of whether the delegate becomes aware of such an “attack” before OR after they have cast their votes, the expected course of discourse is to use any of the templates provided in the Addendum to the policy and disclam this discovery (even simple rationale comments like “hey i noticed these tokens in my wallet - i do not know how they got there / i did not solicit these tokens - i voted my conscience”)
Once again, the delegate has no exposure to any real threat vectors/ actors here. For COI triggers or exposures, the “dusting attacker” once again will have to file a COI complaint against the delegate with the Screening Committee.
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 -
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.
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.
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.
The logical reasoning for the current escalation pathway (screening committee<security council < third party audits) has been discussed before - please see
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.
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