145 lines
5.9 KiB
Markdown
145 lines
5.9 KiB
Markdown
# EDUT Membership Platform Roadmap (Step-Based)
|
|
|
|
This roadmap is intentionally step-based and dependency-ordered. No timeline commitments are embedded.
|
|
|
|
## Step 1: Lock Core Model
|
|
|
|
1. Membership token is required to purchase marketplace offers.
|
|
2. Membership token is not a product license.
|
|
3. Product/module licenses are separate entitlements.
|
|
4. One wallet anchors the identity chain across membership, offers, and activation.
|
|
|
|
## Step 2: Freeze Token Taxonomy
|
|
|
|
1. `MembershipToken` (non-transferable, one per wallet policy configurable).
|
|
2. `OfferEntitlement` (offer-specific rights and policy flags).
|
|
3. `RuntimeActivation` (off-chain activation state driven by entitlement checks).
|
|
|
|
## Step 3: Finalize Membership Contract Interface
|
|
|
|
1. `mintMembership()` payable.
|
|
2. `hasMembership(address)` gating view.
|
|
3. `setMintPrice(...)` admin update with emitted events.
|
|
4. Optional tier ladder based on minted supply.
|
|
5. Immutable checks for non-transferability at contract level.
|
|
|
|
## Step 4: Lock Signature + Intent Protocol
|
|
|
|
1. `POST /secret/wallet/intent` returns nonce-bound typed-data payload.
|
|
2. EIP-712 signature proves wallet possession.
|
|
3. Server verify endpoint enforces replay protection and origin checks.
|
|
4. Intent payload includes price/currency/deadline for explicit consent.
|
|
5. Verify response issues wallet session token with deterministic expiry.
|
|
6. Session lifecycle includes rotate (`/secret/wallet/session/refresh`) and revoke (`/secret/wallet/session/revoke`) controls.
|
|
|
|
## Step 5: Add Membership Mint Transaction Stage
|
|
|
|
1. After signature verification, UI requests membership quote payload.
|
|
2. Wallet sends on-chain mint transaction to membership contract.
|
|
3. Backend confirms inclusion and marks membership active.
|
|
4. UI transitions to `acknowledged` only when activation evidence is complete.
|
|
|
|
## Step 6: Implement Membership Gate in Checkout
|
|
|
|
1. All offer purchases call `hasMembership(wallet)` before checkout.
|
|
2. No entitlement mint is allowed without active membership.
|
|
3. Gate behavior is deterministic and audit-logged.
|
|
|
|
## Step 7: Ship Offer Registry
|
|
|
|
1. Canonical offer schema (`offer_id`, issuer, price, currency, policies).
|
|
2. Offer lifecycle states (`draft`, `active`, `paused`, `retired`).
|
|
3. Policy flags (`member_only`, `workspace_bound`, `transferable`, etc.).
|
|
|
|
## Step 8: Ship Entitlement Purchase Pipeline
|
|
|
|
1. Wallet connect and chain check.
|
|
2. Membership gate check.
|
|
3. Signed quote check.
|
|
4. On-chain entitlement mint/record.
|
|
5. Evidence receipt persisted with tx hash and policy snapshot.
|
|
|
|
## Step 9: Bind Entitlements to Runtime
|
|
|
|
1. Activation checks must pass before module activation.
|
|
2. Workspace binding is explicit and evidence-backed.
|
|
3. Revocation/suspension propagates deterministically to runtime gates.
|
|
|
|
## Step 10: Add Publisher Layer
|
|
|
|
1. Issuer namespace per company.
|
|
2. Issuer signing keys and role boundaries.
|
|
3. Revenue split policy per offer.
|
|
4. Marketplace quality gates before public listing.
|
|
|
|
## Step 11: Harden Compliance and Policy Surfaces
|
|
|
|
1. Terms clearly separate membership rights from license rights.
|
|
2. Privacy describes wallet/signature processing and app-native member communication.
|
|
3. Public copy avoids investment framing and speculative claims.
|
|
|
|
## Step 12: Operational Hardening
|
|
|
|
1. Conformance vectors for membership gating and entitlement gating.
|
|
2. Replay/fraud/rate-limit controls validated in automated tests.
|
|
3. Chain outage/reorg fail-closed behavior documented and tested.
|
|
4. Deterministic audit export for enterprise and legal review.
|
|
|
|
## Step 13: Continuous Optimization
|
|
|
|
1. Measure funnel transitions:
|
|
- visit -> signature -> membership mint -> first entitlement purchase.
|
|
2. Tune copy, wallet guidance, and pricing policy using deterministic metrics.
|
|
3. Expand issuer ecosystem only after quality and support controls are stable.
|
|
|
|
## Step 14: Lock Member App Channel
|
|
|
|
1. Register device channels with wallet-authenticated session.
|
|
2. Deliver deterministic event inbox (polling canonical, push optional).
|
|
3. Gate event visibility by active membership status.
|
|
4. Track ack receipts with immutable event ids and dedupe keys.
|
|
|
|
## Step 15: Ship Free Launcher Control Plane
|
|
|
|
1. Release free launcher with local wallet setup and readiness checks.
|
|
2. Keep launcher useful without paid runtime activation.
|
|
3. Expose membership and governance state clearly in-app.
|
|
4. Ensure setup is resumable across sessions.
|
|
|
|
## Step 16: Lock Governance Paid Install Path
|
|
|
|
1. Governance is first paid license after membership activation.
|
|
2. Install requires signed package metadata and hash verification.
|
|
3. Activation requires active governance entitlement and matching policy hash.
|
|
4. Runtime blocks execution when membership/entitlement status is suspended, revoked, or unknown.
|
|
|
|
## Step 17: Enforce Launcher-Only Commerce Surface
|
|
|
|
1. Public website remains identity/legal/trust surface.
|
|
2. Production catalog and checkout require app-session auth.
|
|
3. Public preview routes are disabled by default and noindexed.
|
|
4. Release gate blocks deploys that expose anonymous production catalog access.
|
|
|
|
## Step 18: Lock Boundary + Availability Class Model
|
|
|
|
1. Suite entitlement binds to one `org_root_id` economic boundary.
|
|
2. Unlimited internal workspaces allowed inside same boundary.
|
|
3. Cross-boundary paid execution fails closed without target boundary entitlement.
|
|
4. Access classes freeze to two values only:
|
|
- `connected` (heartbeat-based)
|
|
- `sovereign` (long-lived local capsule)
|
|
5. Availability state machine is deterministic:
|
|
- `ACTIVE -> GRACE -> CONTINUITY -> PARKED`
|
|
6. `CONTINUITY` blocks growth actions while preserving existing execution.
|
|
7. `PARKED` preserves read/search/export while pausing paid execution.
|
|
|
|
## Step 19: Lock Owner-Gated Admin Plane
|
|
|
|
1. Principal roles freeze to:
|
|
- `org_root_owner`
|
|
- `workspace_member`
|
|
2. Admin controls (health, updates, config) are owner-only.
|
|
3. Support channel is owner-only for org-boundary issues.
|
|
4. Member admin attempts return deterministic guidance (`contact_your_org_admin`).
|
|
5. Admin event classes are never delivered to non-owner streams.
|