Tokenized Deposits vs Stablecoins: Legal Claim, Economics and What JPMD and USDC Look Like Onchain

JPMorgan's deposit token has lived on Base, a public chain, since 20 June 2025. Anyone can read it. As of 4 November 2026 it has 2 holders, 1,001,000 tokens in supply, and 23 holder-to-holder transfers in 502 days (48 Transfer events including mints and burns). USDC on the same chain processed about 2,000 transfers per minute in the sample we took on the same day.

The gap says less about demand than about design. The two instruments are built for different jobs, and the difference is written into their contracts: a stablecoin lets any address hold it by default, while a tokenized deposit refuses every address the bank has not approved.

This guide covers what each instrument is legally and economically, then reads both contracts using data we pulled through Dwellir's Base archive endpoint. If you are building a wallet, an indexer, a treasury tool or a payments product that will touch either one, the contract-level section is the part to read.

Tokenized Deposits and Stablecoins Defined

A tokenized deposit is an ordinary commercial bank deposit recorded as a token on a blockchain or shared ledger. The bank owes the holder the money exactly as it does with a normal account balance. Only the recordkeeping and the transfer mechanism change. The money stays on the bank's balance sheet, where the bank can lend against it.

A fiat-backed stablecoin is a token issued by a separate entity, which holds reserve assets (mostly cash, Treasury bills and repo) equal to the tokens outstanding. The holder's claim is on the issuer, not on any bank. Reserves sit outside the lending system, and redemption at par is usually only available directly to onboarded institutional customers. Everyone else exits through an exchange or a payment app.

Two regulatory facts in the table drive most of the economics. In April 2026, the FDIC proposed that deposits recorded on distributed ledgers remain deposits for insurance purposes, regardless of the recordkeeping technology, while payment stablecoins do not get pass-through coverage. The GENIUS Act prohibits stablecoin issuers from paying interest to holders. Together, the Act and the proposal would let a tokenized deposit do two things a regulated US stablecoin cannot: pay yield and sit inside the insured deposit base.

Where the Money Comes From

The business models are close to opposites.

A stablecoin issuer earns the yield on its reserves and passes little or none of it to holders. Take $1 billion in circulation backed by T-bills at 4%: that is roughly $40 million a year in gross reserve income. Custody, compliance, banking partners and distribution deals (Circle shares a large part of its USDC income with Coinbase, for example) come out of that. Holders get a dollar that moves 24/7 and can be used in DeFi. The issuer keeps the float.

A bank already earns a spread on deposits by lending them out or investing them. Tokenizing them creates no new yield. It keeps the deposits at the bank. Every dollar a corporate treasurer moves into USDC to get weekend settlement is a dollar that left a bank's balance sheet. A tokenized deposit offers programmable, around-the-clock transfers while keeping the deposit, and the lending capacity it supports, inside the bank.

For banks, this is defensive spending. The costs are real: token infrastructure, key management, compliance controls, and reconciliation between the token ledger and the core banking system. The return is deposit retention plus a cheaper way to settle intraday moves between a client's own accounts.

Stablecoin Supply and Bank Pilots in 2026

Total stablecoin supply was $295.0 billion on 4 November 2026 according to DefiLlama, down from $304.2 billion a year earlier and below the roughly $322 billion peak in May 2026. Supply grew steadily from 2023 to that May peak and has since fallen about 8%.

Tokenized deposits are much smaller and mostly invisible from outside the banks:

For anyone who works with blockchain data, the last column matters most. Bank-reported volumes for private-ledger tokenized deposits cannot be checked independently. JPMD on Base is the one large-bank deposit token you can query yourself, so the rest of this post uses it as the example.

JPMD vs USDC on Base: The Contracts

We read both contracts on 4 November 2026 using eth_call, eth_getStorageAt, eth_getCode and eth_getLogs against Dwellir's Base archive endpoint. JPMD's proxy is at 0x7e0aedc93d9f898be835a44bfca3842e52416b82. Its implementation (0x6202...5ae2, found in the EIP-1967 implementation slot) is a 16.6 KB UUPS-upgradeable ERC-20. USDC on Base is at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.

Three of those differences change how you integrate.

The allowlist inverts the default. USDC lets any address receive tokens and lets Circle block bad actors after the fact. JPMD rejects every address until the bank adds it. Simulating a transfer from a current JPMD holder to an address the bank has not approved returns execution reverted with error data 0x1a59ff33..., which decodes to ERC20Disallowed(address). Your wallet or payment flow has to catch that error before it submits the transaction.

2 decimals is a deliberate choice. JPMD amounts are cents, matching how the bank books the deposit. If your code assumes 6 or 18 decimals for "a dollar token", it will be off by a factor of 10,000 or more. Always read decimals().

Admin powers are wider, and slower. forcedTransfer lets the bank move a client's tokens without their key. That fits a deposit, where the bank can already reverse or redirect ledger entries under its account terms.

The trade-off is speed: adding a wallet to the allowlist goes through a timelock. Roles are split across six distinct keys: admin, issuer, burner, pauser, allowlist manager and upgrader, all assigned at deployment.

What 502 Days of JPMD Events Show

The full event history is 117 logs. The endpoint limits eth_getLogs to a 10,000-block range and 10,000 results per request, so we pulled it as 2,169 range requests from the deployment block (31,811,274) to the chain head and ran them in parallel. Four patterns repeat across that history.

Onboarding is timelocked. Every AccountAllowed event follows a TimeLockStarted event for the allowAccount selector (0x1acc948c). On 1 February 2026 the lock period went from 60 seconds to 7,200 seconds, and the execution window from 300 seconds to 24 hours. Since then, approving a new client wallet takes at least two hours from scheduling to execution. The February 2026 onboarding took about four hours end to end.

Redemption is a send-then-burn. The holder transfers JPMD to the address holding BURNER_ROLE (0xc853...7448), which burns it a few minutes later. An indexer sees an ordinary transfer followed by a burn, with no single redeem call to watch for.

Most activity is onboarding cycles. Four times since launch, the bank has allowlisted a pair of new addresses, minted JPMD to one of them (500,000 in June 2025, 100 in each later cycle), moved it between the pair, redeemed it, and then removed both addresses from the allowlist 11 to 26 days later. That fits client onboarding or integration testing, with real deposits staying elsewhere.

Supply is parked. The 1,001,000 JPMD outstanding sits in two allowlisted externally owned accounts: 1,000,000.00 in one, minted on 25 September 2025, and 1,000.00 in the other, minted on 11 November 2025. Neither balance has changed since 19 November 2025.

The supply cap rose in steps, from 10,000 at deployment to 1,000,000 two days later and 10,000,000 in November 2025. On 19 October 2026, the same day JPMorgan launched JPMD on Ethereum mainnet, the cap on Base was lowered to 5,000,000.

None of this tells you how much JPMorgan settles through JPM Coin overall. The bank's Kinexys platform runs most of its volume on its own ledger. What it does show is that the public-chain deployment is, so far, a controlled environment with a handful of approved wallets rather than a circulating dollar.

Building Against Tokenized Deposits

If you are integrating JPMD today, or the Clearing House network in 2027, you need to handle four things that a USDC integration does not.

1. Pre-flight every transfer. Check allowed(recipient) and simulate the transfer with eth_call before asking anyone to sign. A failed transaction still costs gas and shows up onchain.
2. Index the allowlist, not just balances. AccountAllowed and AccountDisallowed events change who can receive funds. A counterparty that could receive yesterday may not be able to today.
3. Read decimals and caps from the contract. Don't hardcode them. JPMD's cap has changed three times since deployment.
4. Treat redemption as two events. Reconcile the transfer to the burner address and the burn as one operation.

Here is the pre-flight check in plain Python with no third-party dependencies. It works against any EVM endpoint, and we ran it against Dwellir's Base archive endpoint:

import json, os, urllib.request

RPC = f"https://api-base-mainnet-archive.n.dwellir.com/{os.environ['DWELLIR_API_KEY']}"
JPMD = "0x7e0aedc93d9f898be835a44bfca3842e52416b82"

def rpc(method, params):
    req = urllib.request.Request(
        RPC,
        json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode(),
        {"content-type": "application/json"},
    )
    return json.load(urllib.request.urlopen(req))

def word(addr):
    return addr[2:].lower().rjust(64, "0")

def preflight(sender, recipient, amount_cents):
    # 1. Is the recipient on the bank's allowlist? allowed(address) = 0xd63a8e11
    res = rpc("eth_call", [{"to": JPMD, "data": "0xd63a8e11" + word(recipient)}, "latest"])
    if int(res["result"], 16) == 0:
        return "recipient not allowlisted"
    # 2. Simulate transfer(address,uint256) = 0xa9059cbb from the sender
    data = "0xa9059cbb" + word(recipient) + hex(amount_cents)[2:].rjust(64, "0")
    sim = rpc("eth_call", [{"from": sender, "to": JPMD, "data": data}, "latest"])
    if "error" in sim:
        # 0x1a59ff33 = ERC20Disallowed(address)
        return f"transfer would revert: {sim['error'].get('data')}"
    return "ok"

holder = "0xb306a959f03b79c33463437d33e92e7abe68bcf7"
print(preflight(holder, "0x1234123412341234123412341234123412341234", 100))  # 1.00 JPMD
print(preflight(holder, "0xaf66bdc2909446cc44e4c7b1eb31c77039f6c8e6", 100))

Output on 4 November 2026:

recipient not allowlisted
ok

The infrastructure needs are ordinary for an EVM chain. Answering "who was allowed to hold this token on the day of a payment" requires historical state, so compliance and audit tooling needs an archive node rather than a pruned full node.

USDC puts a different load on your endpoint. At about 2,000 transfers a minute on Base alone, about five minutes of USDC Transfer logs hit the 10,000-result limit. When we asked for one hour, the endpoint rejected the query and suggested a 131-block range instead. A USDC indexer needs narrow block ranges or a WebSocket subscription. See WebSockets for Blockchain Developers for the subscription pattern.

Which One Fits the Payment

The choice depends on who receives the money and where it has to go next.

On a public chain you can tell which one you are holding from a single contract check: whether a new address can receive it by default.

Next Steps

If you are building payment or treasury tooling for either instrument, start from an endpoint that can answer historical-state questions. Dwellir's Base and Ethereum archive endpoints serve every query in this post, billed at one request per response with no compute-unit multipliers. The Base docs list the supported methods. For stablecoin-native chains such as Arc, Tempo, Plasma and Stable, see the stablecoin L1 RPC guide. For the wider enterprise picture, see Enterprise Stablecoin Adoption in 2026.

To size archive and log-indexing capacity for a payments workload, talk to the Dwellir team or create an account and run the pre-flight script above against your own key.

Sources

• JPMD and USDC contract state and event logs: read from Base mainnet via Dwellir RPC, block 31,811,274 to 53,491,846, 4 November 2026
• JPMorgan: JPM Coin (JPMD) USD deposit token available for institutional clients
• FDIC: Statement of Chairman Travis Hill on the proposal to implement the GENIUS Act
• The Clearing House: support for the FDIC's technology-neutral approach to tokenized deposits
• The Block: JPMorgan, Citi-backed consortium plans tokenized deposit network in early 2027
• HSBC: Tokenised Deposit Service launches in the UAE
• DefiLlama stablecoin dashboard
• Function and event signatures: OpenChain signature database