Corrections · Public diffs
Every published correction here is shown with old / new / date / reason. Recording the full cycle — missed, found, fixed — is part of what transparency means. Entries #001–#005 below are pre-publication edits caught during editorial review; #006 onwards are corrections we found after publication and have already applied to the articles; reader-submitted corrections start at #100.
Total entries: 5 pre-publish + 4 post-publishLast update: 2026-09-16
Transparency commitment
When errors are found post-publish, we fix the article body as soon as they are confirmed and log the diff here, with anything touching fund safety handled first. Significant changes (conclusions affected) also get a callout at the top of the article. We don't delete old versions — keeping the diff is the point.
📬 Site just launched · waiting on the first reader correction
The site went live on 2026-05-18. Post-publish reader-submitted corrections are still at 0. Stale data, conceptual errors, dead links, sloppy terminology — all of it counts as a valid correction. Submit via [email protected]; accepted submissions enter the list starting at #100 with submission date, anonymized submitter ID, and reason.
old: (the #001 conclusion) official mainstream contracts can be approved unlimited, with a monthly revoke.cash sweep
new: a well-known protocol gets no automatic exception for unlimited approval; approve what this operation needs, and check the allowance and the full spender address separately
Reason: #001 treated "the contract is well known" as a reason to loosen the allowance. The articles now say the opposite: reputation does not replace an address check, and an unlimited allowance enlarges your long-term exposure in that token regardless of the protocol's name. #001 stays in the log below; this entry records that it has been superseded.
old: this page does not use an unsupported aggregate or "half of all losses" claim to rank routes; the five products are not results from testing the same amount on the same route
new: what decides the risk on a route is where the powers to release assets, upgrade contracts and verify source messages sit; work through the five entry points on their current pages, and read what you actually receive from the quote the route shows when you open it
Reason: the old wording spent the paragraph on what we had taken out, which gives a reader nothing to act on. It now states what the page does check and which numbers only the current page can answer. Not using unsourced aggregates or loss shares is unchanged.
old: compare the whole string, or use the explorer's copy button and paste it
new: after taking an address from a source you trust, still compare the full string; an address dug out of transaction history, or one you have not confirmed through another channel, does not become trustworthy because the copy succeeded
Reason: the old wording offered the copy button as an alternative to comparing, which reads as "copying replaces verification". Copying only rules out a typo. Address poisoning works precisely by matching the first and last characters and planting the address in your own transaction history.
old: we fix this one specific thing: press every button, record every number, publish every correction
new: the evidence is labeled by type — official documentation, public pages we can screenshot, offline worked examples, and flows we did run ourselves with an entry point and date you can re-check; where no real transaction was executed we say so
Reason: the swap tutorial already states that its walkthrough is a sequence of checks rather than a transaction we executed, so an About page promising that every button had been pressed contradicted it, and we cannot produce a re-checkable record for every tool. Labeling the evidence lets a reader see which sentences they should verify themselves.
old: OKX Wallet currently supports over 100 chains
new: OKX Wallet currently supports 120+ chains
Reason: cross-checked against OKX Web3 documentation (2026-05-15 version) during final pre-publish review; actual count is 120+, draft cited stale 2025-year-end figure.
old: first-3-months phishing rate for self-custody beginners is ~20%
new: first-6-months phishing rate for self-custody beginners is ~12% (multi-source editorial estimate)
Reason: the "20% in 3 months" figure couldn't be traced to a precise primary source in SlowMist or Chainalysis public reports. Revised to a multi-source editorial estimate "~12% in 6 months" with the source nature explicitly labeled.
Added 2026-09-16: that "~12% in 6 months" estimate has since been removed from the article as well; it no longer gives a probability of being phished.
old: X Layer has ~30+ DeFi protocols and ~$90M TVL (2026-05-01 DefiLlama)
new: X Layer has ~30+ DeFi protocols and ~$100-150M TVL (2026-05-13 DefiLlama)
Reason: draft based on 2026-05-01 data. The article publishes 2026-05-17. TVL changed meaningfully. Aligned to 2026-05-13 snapshot and used a range to reduce daily-fluctuation re-correction frequency.
old: ranked by "2025-2026 growth rate" (Permit #1, SetApprovalForAll #2)
new: ranked by "2024 cumulative losses" (SetApprovalForAll #1, Permit #2)
Reason: second editorial review (2026-05-15) concluded reader-relevant "danger" is better captured by "maximum loss already caused" than by "rate of growth". Cumulative loss reflects scale of damage; growth rate matters less to a beginner audience. Also reduces monthly re-ranking churn.
old: under any circumstance, never approve "unlimited" — strict allowance every swap
new: official mainstream contracts (Uniswap, Curve, 1inch etc.) can approve unlimited but monthly revoke.cash sweep; unknown / new contracts strict allowance always
Reason: first editorial review (2026-05-15). Draft used "strict always" stance — theoretically safest. But: strict adds cognitive load on every swap, leading to fatigue-induced click-throughs. Mainstream official contracts (Uniswap V3 SwapRouter etc.) are well-audited; accepting unlimited there is a reasonable trade. Monthly revoke as "rear defense" is more sustainable than "per-swap defense". Revised to tiered stance for real-world usability.
Submit a correction
Found an error, an out-of-date figure, or something to improve?
- Email
[email protected] with subject "[Correction] article-name · short-issue"
- Tell us: which article, which paragraph, what's wrong, what you think should change, your source (if any)
- We reply within 7 business days; safety-related issues within 24 hours
The editorial team is grateful to every reader who files a correction — you do something we can't do for ourselves.