A purchase event does not always arrive with a known member account. NOVA Membership's inspected pass service records that difference explicitly. When the buyer address is already associated with a member on the relevant chain, the purchase can be confirmed for that member. Otherwise it remains pending association.
This is a useful starting point for an entitlement model because it prevents a receipt from silently deciding who may use a service. The product's current passes represent purchase eligibility and benefit records in a local demonstration. Content access enforcement and transferable NFTs are separate implementation scope.
Preserve the event before deciding its effect
The pass record retains a raw event identifier, chain identifier, purchase number and buyer address. It also records the pass type, associated user when known and processing status. The service returns early if the purchase insertion does not create a new record. A repeated event should therefore be reviewed against the existing purchase instead of being treated as a fresh purchase.
There are separate confirmation entry points for the three source pass types. Their follow-up behavior differs. The Foundation-equivalent path creates an active membership record and triggers related processing; the other two paths refresh applicable eligibility. A project should preserve this distinction when translating technical pass types into customer-facing tier names.
The pending-association path selects purchases by chain and normalized buyer address, then updates only records still in the pending state. That boundary deserves a deliberate review with the account-linking flow. The caller must have established that the intended member controls the relevant address before asking the service to associate its purchases.
| Record | Fact it preserves | Decision it cannot make alone |
|---|---|---|
| Purchase | Source event, buyer and pass type | Which authenticated member may use it |
| Member association | Buyer address linked to a user | Whether every benefit condition is satisfied |
| Active pass definition | Tier conditions under active rules | Whether a specific purchase met past rules |
| Eligibility decision | Applied conditions and result | Whether a separate content service enforces access |
Allow independent tiers to coexist
The product materials describe three independent tiers that can coexist under current rules. A single field named highest membership level would lose information if a person holds more than one pass. Keep the purchase records by type and derive each benefit from the conditions that actually apply to it.
The materials also specify a Foundation permanent-quota condition that combines ownership with the required direct-network registration condition. Ownership alone therefore does not establish that particular eligibility result. The member screen needs a reason that identifies the unsatisfied condition without suggesting that the purchase disappeared.
The inspected configuration query reads active pass definitions with their purchase limit, sale cap and required direct registrations. It calculates a confirmed sold count for the relevant chain. These are separate fields with different purposes. A sale cap constrains overall availability; a per-member purchase limit constrains an individual. Neither field should be reused as a generic permission flag.
Decide where an eligibility result will be used
For a content-service extension, define an authorization check at the point where the protected resource is requested. The check would need an authenticated member, the requested benefit and the applicable entitlement conditions. This is a proposed extension. The current pass demonstration does not implement a content gate merely because its member screen displays benefit information.
A useful decision record would identify the member, benefit code and rule version, then preserve a concise reason for the result. If a condition changes, the project must decide whether to reevaluate current access or preserve a previously granted entitlement. The inspected purchase pipeline does not establish one universal answer for every future service.
The current materials describe one-time pass purchases. Recurring subscription billing, renewal failures and offline redemption therefore need their own designs if requested. Adding those labels to a tier card would not supply the payment or fulfillment processes behind them.
Before implementation, review a purchase with no associated account, a duplicate event and a member holding multiple tiers. Include a member who owns the required pass but lacks the additional condition. Record the actual reason the decision returns, not just whether a badge appears on screen.
The pass eligibility worksheet contains these cases with no execution claim. NOVA Membership shows the current local workflow. Bring the benefit definitions, account-association rules and intended service delivery to determine which existing records can support the project and which enforcement steps must be added.
