Skip to main content

Identity, Membership, and Invites

OmegaX needs identity that is useful for coverage/rewards while preserving privacy and permissionless access.

Identity Principles​

  1. Wallet-first identity on-chain.
  2. Optional off-chain subject identity commitments for enterprise workflows.
  3. No raw email, phone, or health telemetry on-chain.
  4. Membership is policy-bound per pool.

Identity Objects​

  1. wallet_pubkey (required): settlement identity.
  2. subject_commitment (optional): hashed opaque identifier for org-level linkage.
  3. organization_ref (optional): off-chain tenant id associated with pool or member.
  4. membership_record: protocol truth for covered/enrolled status.

Membership Policy Modes​

  1. open
  • Any wallet can enroll.
  1. token_gate
  • Wallet must hold configured SPL token balance.
  • Example OmegaX consumer pool: minimum $OMEGAX threshold.
  1. invite_permit
  • Wallet submits signed enrollment permit from trusted issuer.
  • Issuer can be employer, insurer, provider, or community operator.
  1. composed
  • all_of or any_of combinations.
  • Example: all_of(token_gate($OMEGAX), invite_permit(orgX)).

Invite Model (Off-Chain + On-Chain Bridge)​

Invites are issued off-chain by an issuer service (for example, an employer/insurer backend or an integration partner). It should produce:

  1. Human invite code / link for onboarding UX.
  2. Canonical permit payload bound to:
  • pool_id
  • wallet_pubkey
  • invite_id
  • subject_commitment (optional)
  • issued_at
  • expires_at
  • nonce
  1. Ed25519 signature by trusted issuer key.

On-chain enroll_member verifies permit signature and policy constraints, then creates MembershipRecord.

Enrollment Permit Canonical Payload​

Suggested canonical payload fields:

  • version
  • domain (for replay isolation)
  • pool_id
  • organization_ref
  • invite_id
  • wallet_pubkey
  • subject_commitment
  • issued_at_iso
  • expires_at_iso
  • nonce

Signature verification must use deterministic serialization and domain separation.

Replay and Abuse Prevention​

  1. Nonce uniqueness per pool_id + issuer + wallet.
  2. Permit expiry enforced on-chain.
  3. Optional one-time invite semantics enforced by issuer backend.
  4. Optional max-uses and issuance quotas in issuer systems.

$OMEGAX Holder Pool Pattern​

For open consumer pool with token-holder access:

  1. Pool membership policy includes token_gate with $OMEGAX mint and threshold.
  2. Off-chain invites may still be used for campaign routing.
  3. On-chain membership truth is token gate + optional permit policy.

This keeps participation open while allowing curated growth channels.

Employer / Insurer Pool Pattern​

For enterprise pools:

  1. Pool created by organization authority.
  2. Membership policy typically invite_permit or all_of(invite_permit, token_gate(optional)).
  3. Org backend controls invite issuance and eligibility.
  4. On-chain program controls final coverage eligibility and payout enforcement.

Data Minimization​

Recommended:

  • Keep subject_commitment as irreversible hash.
  • Keep PII and health evidence in controlled off-chain systems.
  • Put only commitments, signatures, and references on-chain.

Revocation​

Revocation paths:

  1. Pool authority can revoke membership.
  2. Expired permit cannot be reused.
  3. Governance can disable malicious issuer keys via oracle/issuer registry policy.

Why This Works​

This model supports all required pool types without rewriting protocol logic:

  • Open community pools.
  • $OMEGAX holder pools.
  • Employer/insurer invite pools.
  • Hybrid pools with composable constraints.
Download PDF