Quellengeprüfte Recherche: Proof OF Reserves Liability

Verified Facts

• Binance publishes a public Proof of Reserves page. [sources: binance-por]
• OKX publishes a public Proof of Reserves page. [sources: okx-por]
• Kraken publishes a public Proof of Reserves page. [sources: kraken-por]
• FSB maintains policy work on crypto-assets and global stablecoins that keeps governance and risk controls in scope. [sources: fsb-crypto-stablecoins]
• A POR page alone does not prove a specific user account state, future withdrawals, legal entity coverage or future solvency. [sources: binance-por, okx-por, kraken-por, fsb-crypto-stablecoins]
• The practical comparison should ask about covered assets, liabilities, method, update frequency, verification path and exclusions. [sources: binance-por, okx-por, kraken-por]

Source Map

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

Decision Table

How to Read the Evidence

Covered assets

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: POR scope differs by venue and asset list. That boundary matters because a public source can prove that a venue, regulator or infrastructure provider published a control, method or policy surface, but it cannot prove the condition of a private account, the future behavior of a risk engine, or the availability of support in a live incident. For this reason, the operator action is concrete: record exactly which assets appear in the current disclosure.

A NexuAlpha reader should record the source URL, access time, product surface, jurisdiction, account type and affected asset before acting. The unresolved unknown is assets outside the public page. That unknown should stay visible in the checklist rather than being softened into a marketing claim. In practice, this means using Binance, OKX, Kraken, Financial Stability Board as evidence for public documentation only, then requiring account-local logs, transaction IDs, venue notices or official support responses before moving balances, granting permissions, changing custody, or trusting automation.

Liability side

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: reserves are incomplete without liability context. For this reason, the operator action is concrete: check whether and how customer liabilities are represented.

The unresolved unknown is private liability records.

User verification

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: Merkle or user-verification tooling changes the evidence value. For this reason, the operator action is concrete: test verification only without exposing balances or identifiers.

The unresolved unknown is account inclusion for all products.

Snapshot timing

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: old snapshots cannot prove current reserves. For this reason, the operator action is concrete: record access time and update cadence.

The unresolved unknown is intraday reserve movement.

Entity scope

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: global brands can include multiple legal entities or products. For this reason, the operator action is concrete: identify which entity and product the page covers.

The unresolved unknown is jurisdiction-specific exclusions.

Withdrawal readiness

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: POR does not replace operational withdrawal controls. For this reason, the operator action is concrete: combine POR review with address, network and support-state checks.

The unresolved unknown is future withdrawal pauses.

Stop rule

The verified boundary for crypto exchange proof of reserves liability attestation disclosure radar is narrow: stop when scope, liability or verification path is unclear. For this reason, the operator action is concrete: do not convert disclosure into a guarantee.

The unresolved unknown is audit methodology changes.

Known Unknowns

• assets outside the public page
• private liability records
• account inclusion for all products
• intraday reserve movement
• jurisdiction-specific exclusions
• future withdrawal pauses
• audit methodology changes

Bottom Line

Proof-of-reserves pages should be read as disclosure evidence, not as a blanket solvency guarantee. Binance, OKX and Kraken each publish public proof-of-reserves material, but the decision value comes from the details: which assets are covered, whether liabilities are represented, whether users can verify inclusion, how frequently snapshots update, what auditor or method is named, and what entities or products are outside scope. The radar outcome is to treat POR as one control in a broader custody, liability, governance and withdrawal-readiness checklist. The conservative choice is to use the public evidence as a map, not as permission. The next step is always a narrower verification task: prove the route, prove the scope, prove the account-local state, and leave every unsupported claim outside the decision.