Entry

Overview

Entry defines the boundary where participation becomes a recorded event. It does not describe marketing actions, clicks, or signups, and it does not redefine protocol guarantees. Entry exists to define when and how participation is recognized and referenced by the system.

Within Foundation, Entry is the intake surface that converts verified participation into an allocation-linked administrative record. It sits between participation intent and the later surfaces of vesting, release scheduling, and live status tracking.

Scope

This page defines the participation intake boundary and how verified participation maps into records.

• what Entry means in Genesis and Founders participation flows
• eligibility and verification boundaries for authoritative intake
• the canonical path from intake evidence to allocation record initialization
• forward-only handling of failures, corrections, and recorded outcomes

Core Model

Entry is the system-defined intake surface that links a participant to an allocation record. It is evaluated using verifiable inputs such as chain events and validation checks, and it is expressed as a forward-only record rather than as a mutable UI state.

• Entry = verified participation intake → allocation record initialization
• Authority comes from finalized chain evidence plus system verification
• Outcome is recorded as auditable events and states
• Meaning stays administrative and does not redefine protocol truth

Operational Behavior

In normal operation, the system observes participation evidence, checks category and policy eligibility, applies finality and integrity checks, and then initializes or links the resulting allocation record. That record may then participate in later surfaces such as vesting schedules and live status.

Under abnormal conditions, such as duplicate submissions, expired windows, unsupported assets, or unresolved finality, the system does not silently coerce the intake into success. Instead, it records the non-success outcome or keeps the event pending until the required conditions are met.

Constraints

• Entry does not define protocol guarantees, ledger finality policy, or token-market behavior by itself
• Entry does not replace Participation Flow, which owns detailed eligibility and evidence policy
• numeric thresholds, expiry windows, and amount rules belong to SSOT and enforcement logic rather than narrative docs text
• UI surfaces, wallet-connect state, and participant intent are informational only until verification conditions are satisfied

Integrity Considerations

Entry only remains trustworthy if it is tied to verifiable evidence and forward-only record creation. A participant, operator, or auditor should be able to explain why an entry was recognized, why it was rejected, or why it remained pending by looking at explicit validation and finality boundaries rather than ambiguous UI behavior.

• authority comes from evidence and finality, not presentation state
• duplicate or replayed participation must not create multiple successful records
• corrections are additive and forward-only rather than retroactive rewrites

Eligibility and Verification Boundary

Entry is recognized only when both eligibility and verification conditions are satisfied. The specific operational rules and constraints are defined in Participation Flow; this page defines the intake boundary and how it maps into records.

Inputs and Outputs

Inputs are the verifiable data used to evaluate entry. The exact set depends on Participation Flow policy boundaries and implementation details, but the semantic categories below remain stable.

Failure Modes

Entry can fail when evidence or policy constraints are not satisfied. Failures are not fixed by rewriting history. They are represented as new events, explicit states, or non-success outcomes, depending on policy.

• Wrong network — unsupported chain or route
• Wrong asset type — asset not recognized by current policy
• Insufficient amount — below threshold
• Duplicate or replay — already recorded or invalid reuse
• Expired entry window — outside validity period
• Not finalized — finality not yet reached
• Partial or fragmented evidence — policy-defined handling required

Source of Truth

Entry is a boundary across documentation, parameters, and enforcement. Each layer has a different job and should not be confused with the others.

• Docs: describe intended behavior and constraints
• SSOT: defines numeric values, thresholds, and tables
• Code: enforces transitions and emits auditable records

Future Expansion

This page may expand over time as PVERSE formalizes richer entry-state explanations, clearer dispute-handling references, additional supported participation routes, and deeper cross-links into allocation, vesting, and live status surfaces. Even as it grows, Entry should remain the canonical intake-boundary page rather than drifting into protocol or infrastructure ownership.

Summary

• Entry is the participation intake surface where verified Genesis or Founders participation becomes a recorded allocation event.
• Authority comes from finalized evidence and system verification, not from UI or participant intent alone.
• Entry follows a forward-only model: failures, disputes, and corrections are recorded additively.
• Docs define meaning, SSOT defines thresholds, and code enforces transitions and records outcomes.