CRITERIA BEFORE INCLUSION

Lists change.
Criteria stay
visible.

A versioned registry for Solana pools.
Know why a record qualifies.
See what changed when it doesn't.

Explore the registry ↗Read the criteria

01—05 public criteria. inspectable decisions.

RECORD / 001ILLUSTRATIVE

01/06

POOL REFERENCE

sample_001

passes

criteria version: 0.1
reserve fixture: 120 sol
checks satisfied: 5 / 5

ORG ✓DEP ✓FRS ✓AUT ✓LNK ✓

Sample data. No live pool or safety endorsement.

01 / public criteria02 / versioned decisions03 / traceable changes

01 / THE REGISTRY

Every entry.
A reason to be here.

Inspect six illustrative records. Change the criteria version and see which decisions change. Every result is calculated from the sample inputs below.

DEMONSTRATORFictional records · fixed snapshots · no live chain connection

Find a sample record

Decision

Criteria version

Record / pool fixture	SOL reserve	Snapshot age	Decision	Inspect record

A passing record meets this example's rules. It is not a rating of investment quality or contract safety.

02 / THE PUBLIC CRITERIA

Inclusion is a rule.
Not a placement.

Five checks in this demonstrator. A failed check explains an exclusion. Missing evidence produces an incomplete record. Payment never changes the decision.

05/ checks

Each rule has a name,
a condition, and a version.

download the example criteria ↓

EXAMPLE PARAMETERS
25 / 50 SOL minimum reserve
90 seconds maximum snapshot age

These are demonstration thresholds, not finalized listing requirements.

01 / ORGRecognized origin +

Does the pool's origin match the permitted source? The sample uses a true/false fixture. A production index would need a documented on-chain origin check.

02 / DEPMinimum reserve +

Does the SOL reserve meet the selected threshold? Version 0.1 requires at least 25 SOL; version 0.2 requires at least 50 SOL. This measures the fixture reserve, not executable depth or guaranteed liquidity.

03 / FRSSnapshot freshness +

Was the snapshot recent enough at the time of evaluation? The example maximum is 90 seconds. Ages are fixed fixture values, not a live countdown.

04 / AUTAuthority disclosed +

Is the required authority information present? Missing information means incomplete. Disclosure alone does not imply that a contract is safe or that its authority is revoked.

05 / LNKAccount linkage +

Do the pool and account references belong together? The demonstrator stores the result as a fixture. A live system must publish the matching method and supporting accounts.

03 / THE MECHANISM

Three steps.
A traceable decision.

The proposed registry separates an input from a verdict. Every decision belongs to a particular set of criteria and a particular snapshot.

Submit.

Identify a pool and the evidence needed to evaluate it. A submission is a request for review, not a place in the index.

submit(reference);

Verify.

Apply the published conditions. Record each outcome, including failed checks and missing information.

evaluate(snapshot, rules);

Record.

Attach the criteria version and evidence. A later evaluation creates a new revision instead of silently replacing the old one.

append(decision);

METHOD / ILLUSTRATIVE PSEUDOCODE

Inputs first.
Claims second.

A sketch of the intended interface. No SDK or installable package is being claimed.

// proposed interface — not a published SDK
snapshot = read_pool(pool_address);
criteria = load_rules(version);

decision = evaluate(snapshot, criteria);

append_record({
  snapshot,
  criteria_version: version,
  decision,
  evidence
});

04 / THE REVISION TRAIL

The record stays.
The decision can change.

Changing a rule should leave a visible difference. In this example, sample_002 has 34 SOL in its reserve. Raising the threshold changes its result.

CRITERIA v0.1

25 SOL minimum

sample_002 reserve: 34 SOL
result: passes

CRITERIA v0.2

50 SOL minimum

sample_002 reserve: 34 SOL
result: fails

Illustrative change / same fixture, different threshold.

05 / THE SERVICE ECONOMY

Pay for the work.
Never for inclusion.

The proposed token utility is service credits: scheduled rechecks, longer history and structured exports. Eligibility must remain independent of the customer's balance.

Service credits in YRDEX

Work and price quoted before commitment.

Metered indexing work

Data reads, rechecks and agreed retention.

Operating costs + service revenue

A published accounting policy before launch.

payment ≠ eligibility

PROPOSED / NOT ENABLED

One boundary.
No exceptions for balance.

Public criteria and basic record inspection are intended to remain open. Paid services would fund work around those records.

No fee schedule, allocation, buyback or burn mechanism is announced. The product must have a working service and a cost model before charging for it.

token$YRDEX

intended networkSolana

contractnot published

official X accountnot supplied

06 / WHAT WE CAN'T DO

Authority has limits.
Ours must be explicit.

Design commitments for the intended protocol. They are not claims of enforcement by a deployed smart contract.

Sell a passing decision.

Purchasing credits must not change the criteria or bypass a failed check.

Rewrite a rule in silence.

Material changes require a new version and a visible explanation.

III

Erase an inconvenient revision.

New evaluations should append to the history. A previous decision retains its original context.

Call missing evidence verified.

An unavailable input must remain missing. Incomplete is a useful result.

Hide the power to change the program.

Upgrade authority and administrative permissions must be disclosed before a program is presented as operational.

07 / THE ACTUAL STATUS

Available means available.
The rest stays labeled.

This is a working front-end demonstrator and a proposed product architecture. It does not read real pools, accept payments or submit on-chain records.

AVAILABLE NOW01

Local exploration of six illustrative records
Five explicit checks and two criteria versions
Search, decision filters and record inspection
JSON export of sample decisions and inputs
Downloadable criteria and brand assets

open the demonstrator ↑

COMING SOON / PROPOSED02

Live pool data and documented origin checks
Continuous indexing and revision history
Public API and agent integrations
Token contract, credits and service pricing
On-chain registry and security review

No delivery dates or deployment claims are implied.

08 / OPERATOR NOTES

Read the criteria.
Ask the next question.

What does a passing record mean?+

It meets the selected example criteria with the supplied inputs. This does not establish investment quality, future liquidity, or complete contract security.

Is the index reading live Solana data?+

No. The six records are fictional fixtures. Their reserves, ages and origin flags are fixed values so you can reproduce each decision.

Can a project pay to be included?+

The proposed policy forbids paid inclusion. Service credits would pay for data processing and retention, never a favorable decision. Payments are not enabled in this demonstrator.

What changes between v0.1 and v0.2?+

Only the example reserve threshold: 25 SOL becomes 50 SOL. Sample_002 moves from passing to failing because its fixture reserve is 34 SOL. Other checks are unchanged.

What happens to missing information?+

If no check fails but a required input is missing, the result is incomplete. If any check fails, the result is fail, even if another input is missing. The inspector lists every individual check.

Can I connect a wallet or buy YRDEX here?+

No. No verified token contract or official purchase link has been supplied. The demonstrator does not need a wallet.

Does the site store my searches?+

Search and filter state are held in the current page. They are not submitted to a registry backend. Exported JSON is generated in your browser.

09 / THE IDENTITY FILES