Skip to main content

Identity & Membership

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.

Identity objects​

  1. wallet_pubkey: settlement identity.
  2. subject_commitment: opaque linkage to offchain member or issuer systems.
  3. organization_ref: optional sponsor or operator grouping reference.
  4. membership_record: protocol truth for plan participation.

Membership policy modes​

OmegaX plans can support:

  1. open
  2. token_gate
  3. invite_permit
  4. composed
  5. credential-aware participation where the product requires bounded eligibility effects

This is how open and more constrained participation can coexist on one shared foundation.

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.

Membership is ongoing, not one-time​

Membership does not only matter at join time.

It can also affect:

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

Credential-aware eligibility​

Some plans will eventually need more than open or invite-based access.

Examples:

  • 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.

Membership states over time​

A serious health-plan system needs more than active versus inactive.

Typical states include:

  • pending
  • active
  • suspended
  • revoked
  • expired

Those distinctions matter for fairness, claims, and regulated participation.

Data minimization​

OmegaX should keep:

  • wallet settlement identity
  • subject commitments
  • bounded plan status

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
  • wrapper-constrained participation

without rewriting the protocol each time.

Download PDF