Back to the $499 review

KERNE / ILLUSTRATIVE REPORT SAMPLE

Example Yield Token: disclosure review

1. Scope and conclusion

Specimen engagement TEST-SAMPLE-20261016. One fictional ERC-4626 yield token, one chain, five disclosure pages, three contract references and one 30-day yield window. The agreed questions are: does the headline distinguish projected and historical yield; do published contract references agree; and can a reader establish the origin and freshness of the attestation?

The illustrative outcome is mixed: a projected yield is not clearly labeled, one document names a retired vault, and the sample attestation lacks the information needed to verify freshness. These are disclosure findings. No conclusion is made about solvency, contract safety, credit quality or regulatory status.

2. Evidence register

In a paid report, every row contains the real URL, capture timestamp, chain ID, block number/hash and raw response. The E-labels here identify synthetic fixtures only; they are not live evidence.

Evidence Specimen source and observation Limit
E1 Fictional homepage: headline reads “5% APY”. No visible forecast/historical label in the fixture.
E2 Fictional rate API: projectedApy = 0.05. A projection; no promise of future return.
E3 Synthetic convertToAssets(1e18): 1.000000 underlying at start, 1.002000 after exactly 30 days. Numbers are synthetic, with no chain or block behind them.
E4 Fictional docs: OLD_VAULT. Fictional registry and dashboard: CURRENT_VAULT. No actual deployment identity is asserted.
E5 Fictional status page: a payload and signature, with no published authorized signer or signed timestamp. Authorship and freshness cannot be established.

3. Advertised versus realized yield

Finding D-01 / Medium disclosure impact. The synthetic homepage headline is 5% APY; E2 identifies that figure as a projection. E3 records 0.2% share-price growth over exactly 30 days. Compounding that observed change over 365 days gives approximately 2.46% annualized historical growth: ((1.002 / 1.000) ** (365 / 30) - 1) * 100. This annualization describes the chosen past window; it is not an expected return.

The two figures measure different things, so their difference alone does not show a false statement. The disclosure problem is the missing basis beside the headline. Suggested correction: label the 5% figure as a current projection, date its source, and show the historical window separately. Verify the revised copy in the clarification round.

Reproduction format for a real engagement: chain and archive-RPC identity; vault address; start/end block hashes and timestamps; decimals; function and argument; exact raw results; calculation. No aggregate service is substituted for a first-party advertised claim.

FORMAT ONLY - placeholders are not executable evidence:
cast call <vault> "convertToAssets(uint256)(uint256)" <one-share-units>
  --rpc-url <archive-rpc> --block <start-block>
Repeat at <end-block>; preserve both raw responses and block timestamps.

4. Document and address consistency

Finding D-02 / Medium disclosure impact. E4 contains a disagreement: the setup guide points to OLD_VAULT while the registry and dashboard identify CURRENT_VAULT. A buyer cannot confidently tell which contract is in scope. The report records the exact source locations and the registry read that establishes the intended reference.

Suggested correction: update the guide, label the retired deployment, and link a single maintained address registry. This does not prove the current vault is secure or remove any obligations at an old address. Any source that cannot be reconciled is listed as unresolved rather than silently picked.

5. Oracle and attestation posture

Finding D-03 / Evidence insufficient. E5 supplies bytes described as an attestation, but the fixture does not publish an authorized signer or a signed timestamp. Recovering some address would establish which key signed those bytes; it would not establish that the issuer authorized that key, that the data is fresh, or that the reported reserves exist.

Suggested correction: document the payload format, authorized key, timestamp/freshness policy, source block and verification procedure. Scope excludes exploit testing, oracle manipulation testing and private infrastructure access. Until evidence is supplied, the conclusion remains “unable to establish from public material.”

6. Delivery and signed-summary format

A real delivery includes the report, evidence appendix, an identified signing address, canonical message bytes, payload hash, EIP-191 signature and verification instructions. The agreed signing address is confirmed in the written scope. The specimen below is deliberately unsigned; null is not a valid signature and must never be represented as one.

{
  "specimen": true,
  "engagementId": "TEST-SAMPLE-20261016",
  "serviceId": "disclosure-audit",
  "reportSha256": null,
  "evidenceBasis": "synthetic fixtures, no live data",
  "findings": ["D-01", "D-02", "D-03"],
  "signerAddress": null,
  "signature": null,
  "signatureStatus": "UNSIGNED ILLUSTRATION"
}

For an actual summary, recover the address from the exact message bytes and signature, compare it to the signer agreed in scope, rehash the report file and compare its digest, then reproduce the source reads at their stated blocks. A valid signature proves authorship and integrity of a statement, not the security or solvency of the subject.

7. Boundaries and clarification

The work reviews the agreed public sources at a stated time. Off-chain assets, unaudited assumptions, unavailable archive reads and documents outside scope are recorded as limits. One written clarification round within seven days can correct errors in the delivered review; changes to the target or evidence window require a new scope. Payment does not alter conclusions.

Check current availability and request scope. This specimen creates no engagement, payment obligation or delivery promise.