Recherche vérifiée par sources: OKX / Kraken / Binance

Decision Matrix

Source Map

• OKX: Proof of Reserves (okx-por)
• Kraken: Proof of Reserves (kraken-por)
• Binance: Proof of Reserves (binance-por)
• Financial Stability Board: Crypto-assets and Global Stablecoins (fsb-crypto-assets)

Control Notes

1. Asset list

Asset list is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means which tokens are covered. The useful action is to score covered assets separately. The unresolved edge is unsupported balances, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, asset list should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material. The record can stay simple: the official source URL, the date checked, the product or network under review, and a non-secret note describing why the next step is acceptable. Screenshots should avoid balances, identity documents, API keys, recovery phrases, private keys, passphrases, verification codes and support-ticket private data.

2. Wallet evidence

Wallet evidence is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether reserve wallets are disclosed or proven. The useful action is to score wallet proof freshness. The unresolved edge is future wallet rotation, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, wallet evidence should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

3. Liability inclusion

Liability inclusion is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether user liabilities are measured. The useful action is to score liability method separately. The unresolved edge is off-platform obligations, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, liability inclusion should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

4. User proof

User proof is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether a user can verify inclusion. The useful action is to score self-verification availability. The unresolved edge is private account ineligibility, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, user proof should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

5. Method notes

Method notes is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means Merkle, auditor or cryptographic method explanation. The useful action is to score method clarity. The unresolved edge is implementation details, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, method notes should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

6. Timing

Timing is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means snapshot or update cadence. The useful action is to score recency visibly. The unresolved edge is post-snapshot events, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, timing should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

7. Limitations

Limitations is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means stated exclusions and caveats. The useful action is to score caveat transparency. The unresolved edge is implicit omissions, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, limitations should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

8. Action relevance

Action relevance is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether the proof informs the user's intended action. The useful action is to combine with live withdrawal and product status. The unresolved edge is future stress event, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, action relevance should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

9. Evidence packet

Evidence packet is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means official URLs and checked date. The useful action is to store source evidence without balances. The unresolved edge is privacy retention, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

10. Stop rule

Stop rule is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means when radar should remain unknown. The useful action is to mark unknown if asset, method or limitation is missing. The unresolved edge is future methodology updates, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

Known Unknowns

• unsupported balances
• future wallet rotation
• off-platform obligations
• private account ineligibility
• implementation details
• post-snapshot events
• implicit omissions
• future stress event
• privacy retention
• future methodology updates

Practical Takeaway

The safest version of this article is the one that stays boring and exact. NexuAlpha Radar treats reserve proof as a disclosure system with several separate layers: asset list, wallet evidence, liability inclusion, user inclusion verification, method notes, timing and limitations. OKX, Kraken and Binance all publish proof-of-reserves pages, but a useful radar score should not collapse them into one yes-or-no label. The reader needs to know whether their asset is covered, whether a personal inclusion proof is available, whether wallet evidence is current, whether liabilities are in scope, and what the publication explicitly excludes. This radar therefore scores disclosure completeness, not solvency, future withdrawals, regulatory approval or investment safety. The user outcome is a clearer next inspection step, not a promise that a platform, API, transfer route or tokenized asset will work under every future condition.