Methodology | ZCHF Observer

01 / METHODOLOGY

Source priority

Official sources come first within their domain. Direct contract state is the primary input for values readable at a block; official indexed APIs are preferred for event aggregates. Each future observation must identify its source, quality and timestamp.

02 / METHODOLOGY

On-chain verification

Contract identities, decimals, getter semantics and chain representations require verification. A source is not verified merely because it is named in a planning document. Bridge accounting must be established before chain supplies are combined.

03 / METHODOLOGY

Secondary sources

Venue APIs and secondary providers may provide market context or cross-checks. Their source class remains visible. Secondary-market observations are not promoted to protocol facts.

04 / METHODOLOGY

Protocol reference and market price

FCS reference ask and bid are protocol reference values, not size-specific execution quotes. A third-party market price has a separate source and a physically separate card. It is never substituted for a missing protocol reference.

05 / METHODOLOGY

FCS and FPS

FCS means Frankencoin Shares; FPS means Frankencoin Pool Share. Supply, assets held and reference values keep their token units. The interface does not infer detailed token mechanics or redemption eligibility before verification.

06 / METHODOLOGY

APR, APY and annual simple rate

APR is non-compounded as published. APY includes a compounding basis as published. Annual simple rate remains a distinct non-compounded label for Savings. Reward APR is separate. Derived APY requires an explicit formula and approved assumptions. This frontend performs no rate conversions, summation or mixed-basis ranking.

07 / METHODOLOGY

Missing values remain missing

Amounts, prices and percentages use exact decimal strings. Null displays Unavailable or Not reported, with a reason where available. Unknown booleans remain unknown; an absent isBinding observation never means false. A real source-reported zero would be rendered as zero.

08 / METHODOLOGY

Stale and rejected observations

A stale observation retains its timestamp and a visible Stale label. Rejected numeric values are withheld. Warming up means sufficient accepted observations are still pending; no history is estimated. Freshness thresholds and validation are backend responsibilities.

09 / METHODOLOGY

Development fixtures

Development mode defaults to visibly labelled local fixtures. All financial values in fixtures are null. Opportunity and source slots are layout placeholders, not verified listings. Production never selects fixtures, including when the fixture flag is true. Without backend integration, production explicitly shows unavailable data.

10 / METHODOLOGY

Derived metrics and history

Future derived values require valid, fresh inputs and a documented formula. ROE requires a defined income window. Chain distributions require verified bridge accounting. No peg line, distribution curve, recovery state or historical series is invented in this shell.

11 / METHODOLOGY

Read-only boundary

The frontend does not call protocol APIs, RPCs or market providers. It has no wallet connectors, signers, transaction submission, analytics, cookies or user-data persistence. The future site API is the only integration boundary.

12 / METHODOLOGY

Informational use & independence

ZCHF Observer is an independent information interface. It does not claim protocol affiliation, guarantee source accuracy, returns, liquidity or availability, and does not provide investment advice. Review source evidence and venue terms before making decisions.

13 / METHODOLOGY

Referral disclosure

No referral links or referral tracking are implemented in this shell. If referral links are introduced later, they must be labelled and disclosed alongside the relevant action.