NEAR House of Stake — Code of Conduct (CoC) draft for community review
Hello NEAR Community,
Here’s the structure of what you’ll find in this post and how to use it. We’re sharing the House of Stake (HoS) Code of Conduct draft (CoC) for rigorous review and improvement by the NEAR community. Please note that the overall Co-Creation Process we are using is described here (key to understand the way we are facilitating a legitimate and community-owned process).
Meanwhile, this document is divided in the following sections. Each has a clear purpose so you can jump to what you need—or read end-to-end for full context.
I) Context — Why HoS needs a CoC now, how it fits NEAR’s governance journey, and the scope it covers (on-chain, off-chain, and events).
II) House of Stake Code of Conduct v0.1.0 — The operative, legal-like numbered clauses that define behaviors, processes, and enforcement.
III) Ratification — How community sentiment translates into on-chain confirmation so the CoC becomes effective.
IV) Operationalizing — The immediate next steps after ratification (council setup, SOPs, guidance materials, transparency cadence).
V) Methodology — A succinct recap of the research, synthesis, and prior drafts that led to this version.
VI) Quick Start — Exactly how to engage right now: where to comment, how to propose edits, and how to participate in the poll.
I) Context: Why a CoC for House of Stake and how Hack Humanity fits in
The House of Stake (HoS) is the next governance layer for NEAR, designed to be simple, evolvable, and accountable. While stake-weighted decision-making provides legitimacy, a clear CoC is essential to complement it. It sets shared norms, provides due process, and ensures transparent enforcement for both on-chain and off-chain activities.
This CoC builds on existing norms and formalizes them into an enforceable process. Hack Humanity’s role in this is to help establish and operationalise safe, professional, and inclusive standards for community events and interfaces, connecting those norms to our ongoing governance conduct.
II) House of Stake Code of Conduct v0.1.0
Version: v0.1.0
Audience: NEAR Community
Purpose: Gather community-wide feedback as part of Co-Creation Cycle 1
1. Our Pledge
1.1 We, as members, contributors, delegates, moderators, stewards, and other participants of the House of Stake (HoS), pledge to create a governance environment where participation is safe, inclusive, and transparent.
1.2 Commitments:
1.2.1 Act with professionalism, integrity, and respect in all spaces.
1.2.2 Align behavior with NEAR’s long-term interests and ecosystem health.
1.2.3 Protect privacy, safety, and data integrity.
1.2.4 Use technology, including AI, in an ethical, transparent, and accountable way.
1.3 Applicability:
This pledge applies to on-chain decisions, off-chain forums, events, and public representation of HoS.
2. Purpose & Scope
2.1 Purpose:
Ensure a healthy culture of productive participation in achieving House of Stake’s Mission.
2.2 Scope of Application:
2.2.1 On-chain: including but not limited to proposal submission, delegate voting, treasury allocation, multisig participation.
2.2.2 Off-chain: including but not limited to governance forums, Discord, Telegram, GitHub, social media, community calls.
2.2.3 Community & Events: including but not limited to workshops, hackathons, AMAs, partnerships, and DAO-to-DAO representation.
2.3 Definitions:
2.3.1 Token-holders: participants with stake or voting rights.
2.3.2 Delegates: participants acting with proxied voting authority.
2.3.3 Moderators: individuals tasked with managing discussion, intake, assessment and enforcement.
2.3.4 Stewards: elected or appointed roles in HoS committees, councils or working groups (including the CoC Appeals Panel).
2.3.5 Contributors: developers, writers, organizers, and others engaged in HoS activities.
2.4 Appointment of Stewards
Stewards are currently appointed by NEAR Foundation, until which time that authority can be granted to House of Stake to appoint these.
3. Values & Standards
3.1 Agreed Behaviors
3.1.1 Act in good faith and perform due diligence before voting or advising.
3.1.2 Make your best effort to resolve disputes or issues privately or with a moderator instead of escalating to public channels.
3.1.3 Disclose conflicts of interest, according to the Conflict of Interest Policy.
3.1.4 Provide clear rationales for governance actions.
3.1.5 Communicate with respect, inclusivity, and professionalism.
3.1.6 Protect the privacy, dignity, and safety of community members.
3.1.7 Collaborate transparently; document decisions; support iterative improvement.
3.2 Prohibited Behaviors
3.2.1 Harassment, bullying, stalking, or identity-based abuse.
3.2.2 Plagiarism, falsification, or misrepresentation of work.
3.2.3 Vote-buying, bribery, or covert influence.
3.2.4 Failure to disclose conflicts of interest.
3.2.5 Doxxing, privacy violations, or unauthorized data exposure.
3.2.6 Spamming, shilling, brigading, disinformation, or sabotage.
3.2.7 Making unsubstantiated public accusations against any HoS participant, contributor, or program — including on external platforms (social media, podcasts, media, or other public forums) — without first seeking clarification or following reporting channels.
3.3 Good Practice Example
A delegate suspects irregularities in a funding decision. They first request clarification privately from the relevant working group, then file a report through the official HoS intake form with supporting evidence.
3.4 Bad Practice Example
A contributor tweets that a House of Stake program is “stealing funds” without evidence, instead of using reporting channels. The claim is later deleted, but reputational harm has already occurred.
4. Confidentiality & Financial Independence
4.1 Agreed Behaviors
4.1.1 Respect confidentiality and uphold privacy in all processes.
4.1.2 Maintain independence in decision-making; proactively disclose financial or personal interests when relevant.
4.2 Prohibited Behaviors
4.2.1 Disclosing personal information without explicit consent. This includes contact details, physical location, financial data, wallet addresses, or any information that could enable identification, coercion, or reputational harm.
4.2.1 Accepting undisclosed compensation or benefits in relation to governance actions.
4.3 Good Practice Example:
Challenging the value for money of a particular piece of work, based on substantiated evidence.
4.4 Bad Practice Example:
A member speculates publicly about another’s earnings to undermine their credibility.
5. Work Quality, Pace, and Feedback
5.1 Agreed Behaviors
5.1.1 Encourage timely contributions while respecting diverse work rhythms.
5.1.2 Provide feedback that is constructive, specific, balanced, and respectful.
5.1.3 Recognize and credit the efforts of others.
5.1.4 Foster a safe, professional, and supportive environment.
5.1.5 Assess ideas, work and deliverables based on the arguments and evidence that support them, not personal attacks targeting the character, identity, or unrelated attributes of a member.
5.1.6 Provide appropriate feedback based on the stage a piece of work is at.
5.1.7 Give people a fair chance, space and time to do the work and do it well.
5.2 Prohibited Behaviors
5.2.1 Dismissing contributions with superficial or derogatory remarks.
5.2.2 Making baseless criticism without representative evidence.
5.2.3 Undue or hostile pressure to conform to arbitrary work pace or rhythms. Constructive encouragement is acceptable.
5.2.4 Generalized criticism without constructive intent.
5.2.5 Any pressure, speculation, or unconstructive criticism that harms collaboration.
5.2.6 Avoid toxic or hostile criticism disguised as urgency.
5.3 Good Practice Example:
A reviewer highlights strengths and specific improvements with constructive feedback and actionable suggestions.
5.4 Bad Practice Example:
A member mocks another as “lazy” or “too slow” without understanding the size, complexity, nature of the work type, it’s dependencies, review processes, etc. that a piece of work may need to go through to be done.
6. Reporting & Intake
6.1 Anyone who experiences or witnesses a potential violation is encouraged to report it as described below.
6.2 Moderators will also pro-actively monitor for violations and process those on behalf of the community.
6.3 Reporting Channels (to be set up)
6.3.1 Confidential Code of Conduct complaint form with option to submit anonymously (official HoS portal).
6.3.2 Email: coc@houseofstake.org (alternative submission if needed)
6.3.3 Direct contact with the current Community & Moderation team at events or in community channels or calls.
6.4 Intake & Triage
6.4.1 Acknowledgement of received complaint by the Community and Moderation team, this includes explaining what action they will take.
6.4.2 Urgency assessment within 48 hours to address immediate risks to safety or governance integrity.
6.4.3 Confidential handling; reporter identities protected where possible.
6.4.4 Detect abuse of process (e.g., repeated malicious or false reports) is a violation.
6.5 Good Practice Example:
A member reports a prohibited behavior with timestamps and supporting evidence.
6.6 Bad Practice Example:
A member files repeated false reports to harass another participant.
7. Moderation Standards
7.1 Impartiality: moderators must have no conflicts of interest.
7.2 Cultural and linguistic competence: include moderators who understand the parties’ context.
7.3 Documentation: maintain secure records, a clear evidence trail, and access controls.
7.4 Timeliness: target resolution within 14 days; document and communicate extensions.
7.5 AI oversight: AI tools may assist with triage or pattern detection; humans make final decisions.
7.6 Evidence standards: use verifiable records (e.g., logs, messages, transactions) and note limitations.
7.7 Good Practice Example:
Assign moderators from outside the immediate dispute to ensure impartiality.
7.8 Bad Practice Example:
Allowing a conflicted delegate to oversee a case involving their own committee.
8. Enforcement & Remedies
8.1 Principles: proportionality, predictability, and restoration where feasible.
8.2 Feedback
8.2.1 Observation: first, minor or potential violation.
8.2.2 Consequence: private or public feedback, at Moderator’s discretion.
8.2.3 Repair: acknowledgement, clarification, improvement in behaviour.
8.3 Warning
8.3.1 Observation: feedback ignored or serious violation
8.3.2 Consequence: private or public written notice with requested changes.
8.3.3 Repair: apology, acknowledgement, or clarification.
8.4 Temporary Restriction
8.4.1 Observation: repeated or significant violation
8.4.2 Consequence: time-bound restriction or suspension from channels or roles.
8.4.3 Repair: reflection, mediation and a plan for corrective steps with conditions for return defined.
8.5 Permanent Ban
8.5.1 Observation: severe violation undermining safety or governance integrity or legitimacy
8.5.2 Consequence: removal from all governance spaces (on-chain and off-chain) to the greatest extent possible.
8.5.3 Repair: not applicable; reserved for irreparable breaches of trust.
8.6 Proportionality Factors
Moderators will exercise judgement on the level of remedies based on intent, impact, prior history, cooperation, and community safety.
9. Appeals Process
9.1 Appeals Panel: at least 3 independent members, rotating annually; no conflicts of interest.
9.2 Criteria: temporary restrictions and permanent bans can be appealed based upon new evidence, a claim of misinterpreted evidence, procedural error or disproportionate sanctions.
9.3 Timeframe: submit within 14 days; decision within 30 days.
9.4 Submission: encrypted form or direct email to the Panel’s published contact.
9.5 Finality: Panel decisions are binding, subject to community ratification in exceptional cases.
9.6 Good Practice Example:
A sanctioned member submits new logs that change the assessment; sanction reduced.
9.7 Bad Practice Example:
Multiple frivolous appeals filed to delay enforcement.
10. Risk Disclosures & Limitations
10.1 Enforcement capacity depends on moderator resources and jurisdictional constraints.
10.2 On-chain actions may be irreversible; remedies cannot fully counteract immutability.
10.3 This CoC complements applicable law; it does not replace legal rights or obligations.
10.4 Jurisdictional differences may require tailored measures while upholding core principles.
11. Transparency & Governance Oversight
11.1 All reports, evidence, decisions and feedback and enforcement actions are logged in an auditable but privacy-preserving way.
11.2 Annual reports summarize cases, categories, timelines, outcomes, and reforms (respecting privacy where required).
11.3 Committees overseeing this CoC maintain a public change log and explain major policy updates.
11.4 Moderation team disclose their affliations, incentives and responsibilies to reduce conflicts of interest.
12. Contact & Amendments
12.1 Contact: info@houseofstake.org.
12.2 Amendments: updates follow a public notice and versioning process with a “Last Updated” date.
12.3 Effective Date: this CoC takes effect upon community ratification and remains in force until amended.
End of the CoC policy text.
Jump now to VI) Quick Start — Exactly how to engage right now: where to comment, how to propose edits, and how to participate in the poll.
Or read on for more about the methodology being applied…
III) Cocreation Process - House of Stake
Legitimacy in decentralized ecosystems is earned through openness, inclusivity, and shared ownership—but we must balance that against limited stakeholder attention. Our approach is an expanding-circles model that starts lean, then adds more representation and methodological rigor only if broad agreement is missing.
Cycle 1:
- Ingest historical materials, transcripts, sticky notes, forum drafts.
- Convene a smallest viable group to produce a first draft.
- Purpose: get a concrete, discussable artifact fast—with minimal cost.
- Share draft in easiest way to get broad feedback.
- Legitimacy test: stakeholder feedback & temperature check. If strong support → ratify/use; if insufficient support → expand.
Cycle 2:
- Iterate on the CoC policy text to address cycle 1 feedback
- Expand the drafting group to include broader representation.
- Apply and showcase a deeper, reproducible methodology.
- Share draft in more structured way i.e. in Github repo.
- Re-share for full community feedback. If strong support → ratify/use; if gaps/divisions persist → expand again.
Cycle 3 (if necessary):
- Structure the drafting body to be legitimately representative of all key stakeholder groups.
- Use defensible and reproducible methods end-to-end.
- Re-share and proceed to ratification once thresholds are met.
The principle:
Only invest more work (and cost) if legitimacy demands it. This balances efficiency (don’t over-invest when consensus is present) with legitimacy (scale participation when it isn’t).
Legitimacy & Ratification — GitHub-Native Process
This section explains how to propose edits to the CoC using GitHub and how it will be ratified. It’s intentionally lightweight at first and scales only if legitimacy tests aren’t met.
Draft process for Cycle 2
1) Canonical Source & Versioning
- Canonical file: The CoC [ADD LINK WHEN POSTED IN GITHUB] lives in this repository as a Markdown file; the repo is the source of truth.
- Branches & tags
- Working draft branch:
coc/v1.1-draft - Release candidates (RC): tags
v1.1-rc.1,v1.1-rc.2, … - Effective release: tag
v1.1and branchcoc/v1.1
- Working draft branch:
- Change log:
CHANGELOG.mdsummarizes every merged change (date, author, section, rationale, links to PR/issue).
2) How to Propose Edits (GitHub)
Use one topic per PR and reference numbered clauses (e.g., 5.2.1 Harassment).
A. Minor/Patch edits (typos, formatting, small clarifications)
- Fork or create a branch from
coc/v1.1-draft. - Make your change(s) directly in the CoC file.
- Open a PR to
coc/v1.1-draftwith title:
CoC: <section-number> <short description> [minor] - Fill the PR checklist (below).
B. Major edits (scope, sanctions ladder, appeals, COI definitions)
- Open an Issue first describing the problem and proposed solution.
- After community discussion, submit a PR linked to that Issue with title:
CoC: <section-number> <short description> [major] - Expect focused review (see triage & SLAs).
PR Checklist (copy-paste into your PR description)
- Clause(s) touched (e.g.,
5.2.1,7.3) - Change type: Minor / Major
- Proposed text (exact redline or replacement)
- Rationale (1–3 sentences; risks if not adopted)
- Evidence (links to precedent, policy, or data)
- Conflicts of interest to disclose (if any)
- I agree to keep discussion constructive and in-scope
Style guardrails
- Keep legal-like numbering intact (1, 1.1, 1.1.1).
- Prefer concrete, enforceable language over vague adjectives.
3) Triage, Review & Release Candidates
- Acknowledgment SLA: within 76 hours on Issues/PRs.
- Labeling:
major-change,minor-edit,clarification,policy-risk,needs-discussion,ready-to-merge. - Weekly merge window: maintainers batch-merge accepted minor edits; major edits require at least 2 reviewer approvals (one delegate + one maintainer).
- Release candidates: Once a meaningful set of changes is accepted, maintainers cut a tag
v1.1-rc.Xand post a short summary. If there are no blocking objections after the discussion window, the RC moves forward to ratification.
4) Legitimacy Tests (before ratification)
Advance to ratification when ALL are true:
- Sentiment: clear support in the forum thread (using a poll).
- Representation floor: 5 comments from at least two stakeholder groups (e.g., delegates, moderators/builders/community).
- No unresolved material objection without a written maintainer response and next step.
If these are not met, expand outreach, run a focused workshop, or iterate another RC (rc.+1) before re-testing.
5) Ratification Mechanics — Community sentiment → On-chain action
Community sentiment (off-chain poll)
- Hosted in the forum post.
- Participation floor: N ≥ 5 unique forum accounts or prior-defined active contributors.
- Pass threshold: ≥ 60% “Yes”.
On-chain confirmation (or signed delegate statement)
- HoS-based governance
Effectivity
- Upon onchain confirmation, the CoC becomes v1.1 (Effective). The effective text is tagged
v1.1and its commit hash is recorded in the forum thread.
6) Transparency & Records
-
Keep all Issues/PRs public by default.
-
Publish the Decision Record in the forum: what changed since the previous draft, how material objections were handled, poll results, and the commit hash of
v1.1.
IV) Operationalizing the CoC
Following ratification, we will finalize the operational specifics over the next few days. In the meantime, the structure below sets out exactly what we will stand up and document so the Code of Conduct can function from day one.
Draft process post-Ratification
1) CoC Council — Structure to be finalized
We will publish concise definitions and templates covering:
- Size & composition: number of seats, diversity goals, and stakeholder coverage.
- Nomination format: how to nominate (fields required), where to submit, and the review window.
- Eligibility & conflicts: baseline qualifications, disclosure requirements, and recusal rules.
- Selection: decision method, participation thresholds, and tie-break procedures.
- Term & renewal: term length, renewals, mid-term vacancy fills, and removal for cause.
- Operating rules: quorum, decision-making method, emergency actions, record-keeping.
- Roles: chair/convener, case manager(s), clerk/records, alternates for recusals.
2) Education & User Guidance — “How to Report / How to Appeal”
We will publish a short, plain-language guide (posted in the forum and linked from the repo) that includes:
- Where to report: reporting channels and when to use each.
- What to expect: acknowledgment timelines, privacy/confidentiality, and typical resolution windows.
- Appeal steps: who reviews appeals, grounds for appeal, timelines, and re-entry conditions.
- Templates: copy-paste forms for reports and appeals.
3) Timeline
-
Week 1: Once ratification has happened, open nominations for the CoC Council.
-
Weeks 2–4: Nominate & confirm Council; run orientation for Council, moderators, and delegates.
-
Weeks 5–6: Begin handling initial cases under SLAs; publish the first monthly transparency note.
-
Week 8: Post a brief “lessons learned” update and propose any minor policy patches via PR.
