Exit & Separation Protocol

Download this template

Generated 2026-07-07 · Download all templates

  • Layer: 1 — Membership System
  • Status: Template — adapt for your community
  • RCOS reference: §3.6, §3.7, §3.8

Voluntary Exit

RCOS clauses: 3.6.1, 3.6.2, 3.6.4

Why make leaving frictionless?

A community that is hard to leave is not a community — it is a trap. Voluntary exit must be available at all times, without interrogation, notice periods, or punishment, because the right to withdraw consent is what makes every other act of consent real. Retaining contribution history separately ensures that leaving does not erase the work the person did.

How to fill this in

Describe the channel for submitting exit, time-to-revocation of access, what records are retained, and the resulting state transition.

  • <How a member submits a voluntary exit; reasons optional.>
  • <Notice period or handover expectation, if any.>
  • <Time-to-revocation of access (e.g. within 24 hours of confirmation).>
  • <What is retained — contribution history, recognition records — and what is removed.>
  • <Resulting state transition (e.g. to Exited Member).>
  • <Where and how the exit is recorded with timestamp.>

Forced Exit

RCOS clauses: 3.6.3, 3.6.4

Why gate removal behind Layer 4?

Removal is the sharpest power the community holds over a person. If it can be exercised by anyone with enough social pull, membership is worthless. Requiring a concluded Layer 4 accountability decision — with written reasons, a notification, and a minimum re-application window — turns removal from an act of power into an act of governance that can be reviewed and contested.

How to fill this in

State that forced exit can only follow a concluded Layer 4 accountability process. Define notification, access revocation, retained records, re-application block, and decision-record privacy.

  • <Forced exit may only result from a concluded Layer 4 accountability process with a documented decision.>
  • <Affected member must be notified in writing with reason and decision-record reference before access is revoked.>
  • <Time-to-revocation of access (e.g. within 24 hours of decision).>
  • <What is retained, what is removed.>
  • <Re-application block (minimum duration, set by accountability decision; reference Layer 4).>
  • <Privacy of the decision record (reference Conflict Resolution Ladder privacy rules).>

Suspension

RCOS clauses: 3.7.1, 3.7.2, 3.7.3

Why design suspension carefully or not at all?

A poorly-designed suspension state is worse than none — it becomes a soft exit with no due process, or an indefinite limbo used to punish without the accountability of a full removal. If the community cannot commit to explicit conditions, time bounds, and review mechanisms, it is safer to have no formal suspension than a loose one.

How to fill this in

Either define suspension explicitly (entry conditions, time limits, rights during suspension, review mechanism, exit) or state that no formal suspension exists. Do not leave this section ambiguous.

<Either: define suspension state with entry conditions, maximum duration, rights during suspension, mandatory review mechanism, and exit; or: state that formal suspension is not currently defined.>

Asset, Role, and Responsibility Separation

RCOS clauses: 3.6.5

Why enumerate separation steps?

When someone leaves, every unclosed thread — a role nobody vacated, a wallet key still active, a task still assigned — becomes a live attack surface or an operational gap. A checklist forces these threads to be closed deliberately, not discovered months later when something breaks or someone abuses access they no longer should have.

How to fill this in

Provide a checklist applied to both voluntary and forced exits. Include role vacation, task release, financial-instrument access removal, platform admin revocation, and resolution of outstanding obligations.

The following separation steps apply to both voluntary and forced exits:

  • <Roles held must be vacated and documented in the Role Registry.>
  • <Ongoing tasks must be released or handed over.>
  • <Treasury / wallet / signing access must be removed.>
  • <All administrative access to platforms must be revoked.>
  • <Outstanding obligations resolved or transferred before exit is finalised where possible.>

Ratification Record

  • Adopted: <YYYY-MM-DD>
  • Decision type: Strategic
  • Version: <version>
  • Decision record: <link to decision record>

RCOS Standard by EcoHubs

A modular operating system that defines how intentional communities organize — from governance and roles to resource sharing and conflict resolution — in support of resilience, fairness, and regeneration.

Connect

© 2026 EcoHubs Platform. All rights reserved.