On-Chain Verification on MC Markets: A Practical Guide to Proof of Reserves

Introduction

For most of crypto's history, "your funds are safe" meant trusting the platform's word. After 2022, that stopped being good enough. A series of high-profile collapses made it painfully clear that off-chain accounting and on-chain reality could diverge dramatically — and that the only durable answer to "is my money really there?" was math any user could verify themselves.

Proof of Reserves (PoR) is that math. Done correctly, it lets any user check — with cryptographic certainty — that the platform actually holds the assets it claims to.

MC Markets is built around this principle. The platform describes itself as "on-chain verifiable," with all asset reserves stored on Arbitrum and a public audit trail any user can walk independently. This guide explains how the system works — Merkle trees, Arbitrum, Chainlink, Pyth, separated reserve addresses — and gives you a concrete step-by-step procedure for verifying the platform's reserves and your own balance.

1. What Proof of Reserves Actually Means

In the broadest industry sense, Proof of Reserves is a cryptographic mechanism that proves a custodian holds at least as much of an asset as it owes its users — without requiring users to trust the custodian's internal accounting.

Two things have to be true for a PoR system to be meaningful:

1. Total Reserves ≥ Total User Liabilities. The platform must hold at least 1:1 backing for what users have on deposit.
2. Both numbers must be independently verifiable. Users can confirm their balance is included in the user-liability total, and can confirm the reserve total is real on-chain.

Without (2), "we have 1:1 reserves" is just a claim. With (2), it becomes a provable fact any user can check at any time.

MC Markets' implementation: Merkle-tree-based PoR, deployed on Arbitrum. The platform explicitly commits to 1:1 backing for user funds, with reserves maintained at 100% or above and snapshots updated periodically.

2. Why a Merkle Tree?

The Merkle tree is the standard data structure used across the industry — by Kraken, Binance, OKX, Bitget, and most reputable exchanges that have implemented PoR — because it solves a specific privacy-versus-transparency problem.

Imagine a platform with millions of users. To prove "user A has X tokens," the platform could publish every user's balance — but that exposes private financial information. A Merkle tree fixes this elegantly:

• Every user's balance is hashed into a leaf of the tree.
• Pairs of hashes are combined and re-hashed up the tree, level by level.
• The single value at the top — the Merkle root — is published on-chain.

To verify your balance is correctly included, the platform gives you only a small Merkle proof — a path from your leaf up to the root. You can verify this path mathematically without seeing anyone else's data. And the platform cannot lie about your balance without changing the published root, which would invalidate every other user's proof simultaneously.

In short: Merkle trees let everyone independently verify their own inclusion without exposing anyone else's information. Privacy and verifiability at the same time.

3. Why Arbitrum

MC Markets' PoR system lives on Arbitrum — an Ethereum Layer 2 network built using optimistic rollup technology. Two reasons this matters in practice:

• Auditability. Arbitrum inherits Ethereum's security model and uses Ethereum as its data-availability layer. Every transaction, every contract state, every reserve update is permanently recorded and publicly accessible via standard Ethereum-compatible tools — most notably Arbiscan, the network's block explorer.
• Cost and throughput. Layer 2 makes regular snapshot updates economically practical. On Ethereum mainnet, frequent reserve attestations would be cost-prohibitive; on Arbitrum, they're affordable enough to run on a real schedule.

The result is a system where any user, anywhere in the world, can pull up Arbiscan and see the contracts and balances for themselves — no privileged access required, no platform credentials needed.

4. The Wider Audit Stack: Arbitrum, Chainlink, Pyth

MC Markets isn't built on proprietary, opaque internals. Three independently audited public protocols form its on-chain backbone:

• Arbitrum — the L2 network where reserves and contracts live.
• Chainlink — the industry-standard decentralized price oracle network, providing reliable market data without single-source manipulation risk.
• Pyth — a high-frequency price feed network optimized for derivatives applications.

The significance of building on these three is structural: the most consequential pieces of the platform — where reserves are held, how prices are sourced for liquidations, how derivatives are settled — are not opaque internal systems. They're public protocols that have been audited by independent security firms, used by hundreds of other applications, and stress-tested under real market conditions.

This is what lets MC Markets describe itself as "Web3-native" with credibility: the trust assumptions are spelled out and verifiable, not hidden inside a black box.

5. Two Wallets, One Platform: Why User Funds Are Held Separately

A subtle but important architectural commitment: user assets and operational funds are stored at separate on-chain addresses.

Additionally, the platform operates a cold-hot wallet separation architecture: the majority of user assets are held in offline cold wallets, with only the funds needed for day-to-day operations kept in hot wallets. Cold wallets use a multi-signature mechanism — every fund movement requires authorization from multiple parties — providing an additional layer of protection that prevents any single point of failure from compromising user funds.

User assets are the deposits you and other users have placed on the platform. Operational funds are what the platform itself uses to run — fees collected, treasury holdings, working capital. By segregating these into distinct addresses on Arbitrum, MC Markets makes a clean structural promise: the reserves backing user deposits cannot be commingled with operational expenses, even by mistake.

Both addresses are independently verifiable through the Proof of Reserves page. You can confirm not only that user reserves match user liabilities, but that those reserves sit at addresses that aren't being used for general platform operations.

6. How to Verify the Reserves Yourself: Step-by-Step

This is the part where industry "PoR" stops being an abstract claim and becomes something you actually do. The whole walk-through takes about five minutes.

Step 1 — Find your wallet address

If you connected an external wallet (MetaMask, etc.) when you deposited, that address is your reference. If instead you registered with email or Google, the platform assigns you a deposit address — which is shown on the Deposit page. Locate and copy that address.

Step 2 — Open the Proof of Reserves page

Navigate to the Proof of Reserves link in the top navigation bar. The page displays two key numbers:

• Total Reserves — the assets the platform holds on-chain.
• User Assets — the total assets owed to users.

Confirm visually that Total Reserves ≥ User Assets — the reserve ratio should sit at 100% or above. If a snapshot timestamp is shown, note it — that's the moment the figures were generated.

Step 3 — Verify your own balance

Enter your wallet address into the balance-lookup field on the PoR page. The system returns what it has on record for that address. Cross-check this against your platform balance. If they match, your funds are accounted for in the user-liability total.

Step 4 — Verify the reserve contracts directly on-chain

The PoR page publishes the core contract addresses for the reserves. Copy each address and paste it into Arbiscan — the public block explorer for Arbitrum.

On Arbiscan, you can see:

• The current on-chain balance of the contract address (in USDC or other supported assets).
• The transaction history, including reserve updates, deposits, and withdrawals.
• The contract source code, if it's been verified — meaning you can read exactly what the contract is allowed to do.

If the on-chain balance matches what the PoR page reports, you've independently confirmed the reserves are real. No "trust me" required — just publicly verifiable data.

Step 5 — Repeat periodically

PoR is a snapshot, not a live feed. The reserve numbers are accurate as of the last snapshot time. Verifying once is good; verifying occasionally — especially after periods of high market volatility — is better.

7. What "Good" Looks Like in PoR Data

Once you know how to verify, here's what to actually look for — these are the markers of a healthy PoR implementation, on this platform or any other:

• Reserve ratio sits at 100% or above, consistently. A platform whose ratio dips below 100% — even briefly — isn't honoring 1:1 backing at that moment.
• User-side and operational-side addresses are separated. Mixed addresses are a red flag for any custodial platform.
• Snapshots update on a regular cadence. Long gaps — months without updates — suggest the system isn't being actively maintained.
• Contract source code is verified on Arbiscan. This means anyone can read exactly what the contract code does. Unverified contracts are opaque, and opacity is the opposite of what PoR is for.

8. The Bigger Picture: Why "Trust, Then Verify" Matters

The post-2022 lesson for the entire industry is that trust without verification doesn't survive a stress event. Every major exchange now publishes some form of reserve attestation; the depth, frequency, and verifiability vary significantly across them.

MC Markets' position — Merkle-tree PoR on Arbitrum, plus separated reserve addresses, plus public audited infrastructure (Chainlink, Pyth) — sits squarely on the "high-transparency" end of that spectrum. The platform's commitment to being "on-chain verifiable" isn't a marketing slogan — it's a falsifiable statement you can test in five minutes with the procedure above.

The general principle worth carrying with you, on any platform you use: don't ask "do they say my funds are safe?" — ask "can I verify it?" The first is a claim. The second is a fact.

9. Quick Recap

The five ideas worth keeping:

• Proof of Reserves is a cryptographic mechanism that proves a platform holds at least as much as it owes — without requiring users to trust internal accounting.
• MC Markets' implementation: Merkle-tree-based PoR, deployed on Arbitrum, with reserves at 100% or above and periodic snapshot updates.
• Three audited public protocols form the on-chain backbone: Arbitrum (reserves and contracts), Chainlink (price oracles), Pyth (derivatives price feeds).
• User assets and operational funds are stored at separate on-chain addresses — both independently verifiable through the Proof of Reserves page.
• Verification takes about five minutes: find your wallet address (or platform-assigned address from the Deposit page) → open the Reserves Report page → check your balance and the reserve ratio → copy the core contract addresses to Arbiscan → confirm on-chain.

Risk Disclosure

The mechanics, contract addresses, and verification procedures described here reflect MC Markets' current implementation and may be updated; always consult the official Proof of Reserves page for the most current information. While Proof of Reserves verifies that user assets are backed 1:1 on-chain, it does not eliminate market risk or operational risk. Trading on the platform involves substantial risk and can result in losses. Trade based on your own analysis and risk tolerance, with capital you can afford to lose.