Skip to main content

Identity & Membership

Start here if

Use this page when you need to understand wallet identity, plan membership, proof modes, and why raw identity material stays offchain.

OmegaX uses a wallet-first identity model, but identity and membership are not the same thing.

That distinction matters because the protocol is trying to anchor enforceable participation without becoming a storage layer for private enrollment systems or compliance paperwork.

Identity principles​

  1. Wallet is the onchain settlement identity.
  2. Membership is plan-specific eligibility truth.
  3. Sensitive identity and compliance material should stay offchain.
  4. Regulated participation should be expressed through bounded effects, not raw document storage.

Live identity and membership objects​

The current public surface uses these core objects:

  1. wallet_pubkey: settlement identity.
  2. subject_commitment: an opaque linkage to offchain member or issuer systems.
  3. HealthPlan: the plan root that defines membership policy and any related gate configuration.
  4. MemberPosition: the durable onchain participation record for a plan and optional policy series.

For token-gated plans, the protocol can also use MembershipAnchorSeat as a technical anchor-seat record behind the membership flow. That object supports anchor-based gating, but the main participation object builders integrate against is still MemberPosition.

Membership modes versus proof modes​

The current public protocol surface separates the plan's membership rule from the proof a member uses to satisfy it.

ConceptMeaning
Membership modeThe plan-level rule for who can join.
Enrollment proofThe proof path a member used to satisfy the rule.
Gate kindThe specific token or anchor mechanism behind token-gated access.
Subject commitmentOpaque offchain linkage, not raw identity storage.

Membership modes on the plan​

These are the current plan-level membership modes:

  1. open
  2. token_gate
  3. invite_only

These modes define who can join the plan.

Enrollment proof on the member position​

The proof path records how a member actually satisfied the plan rule.

For example:

  • an open plan uses open enrollment proof
  • an invite-only plan uses the invite_permit proof path
  • a token-gated plan uses token-gate proof and records the observed gate state on the MemberPosition

That distinction keeps the protocol precise. invite_permit is a currently supported proof path, not a separate plan mode.

Token-gated participation​

Token-gated plans can currently use these gate kinds:

  1. fungible_snapshot
  2. nft_anchor
  3. stake_anchor

They all still land in the same token_gate plan mode, but they differ in how the qualifying asset or anchor is checked and recorded.

For builders, the important point is that token-gated enrollment is not one monolithic path. The plan chooses the gate kind, while the resulting MemberPosition stores the enrollment proof mode, gate kind, anchor reference, and observed gate amount snapshot.

Invite model​

Invites are issued offchain by an employer, insurer, provider, operator, or partner.

The protocol should only receive the bounded result:

  • which plan the permit applies to
  • which wallet it is bound to
  • whether it is still valid
  • whether it has already been used

That keeps private enrollment workflow offchain while making eligibility enforceable onchain.

Current member record​

Membership does not only matter at join time.

Today, the durable onchain participation object is MemberPosition. It carries bounded state such as:

  • wallet settlement identity
  • optional series scope
  • subject commitment
  • eligibility status
  • delegated rights
  • enrollment proof mode
  • membership gate kind
  • anchor or snapshot references when applicable
  • enrollment and update timestamps

That object is the current protocol truth used across enrollment, rewards, coverage, and claim-related flows.

Membership is ongoing, not one-time​

The current member record can still affect:

  • policy activation
  • premium continuation
  • claims eligibility
  • delegated actions
  • regulated access constraints

Compliance and credential controls​

Some plans need more than simple open, token-gated, or invite-only access.

In the current public surface, OmegaX handles that through plan policy and bounded controls around specific actions rather than through a separate public membership mode.

Examples include bounded controls such as:

  • sponsor-approved employee status
  • wrapper-approved holder status
  • provider-network eligibility
  • region or jurisdiction gating

OmegaX should consume those effects without becoming the storage layer for raw identity or compliance documents.

Data minimization​

OmegaX should keep:

  • wallet settlement identity
  • subject commitments
  • bounded membership truth

OmegaX should avoid storing:

  • raw KYC payloads
  • raw medical identity material
  • raw communications or invite CRM data

Why this works​

This model supports:

  • open community plans
  • token-gated plans
  • sponsor-led cohorts
  • compliance-bound participation

without rewriting the protocol each time.

Next read​

Download PDF