zJPYC on-chain: about 1.21 million JPYC sits in a privacy pool — the link is severed, but entry and exit are public

What zJPYC is

zERC20 is a privacy transfer protocol based on zero-knowledge "proof-of-burn" (in the EIP-7503 family). It has been publicly stated that it was developed by core developers of INTMAX. In plain terms, it works like this:

1. A user deposits an ERC-20 token into the pool and receives the same amount of a zAsset (zJPYC, in JPYC's case).
2. The zAsset is sent to a one-time address for which no private key exists. Nothing can ever move out of that address, so the transfer is effectively a burn.
3. The recipient proves, with a zero-knowledge proof, that such a transfer happened, and claims a freshly minted zAsset to their own address.

The proof in step 3 is verified without revealing which transfer it corresponds to, so the link from sender to recipient is never written on-chain. Recipients can claim on a different chain from the one the transfer happened on, and the protocol also supports batch claims (several transfers at once) and partial claims.

zJPYC is the JPYC version. According to zERC20's announcement it launched on Polygon on June 11, 2026, and it is also live on Kaia. The contracts share the same addresses on both chains.

zERC20's page states that JPYC Inc. is not involved in providing, co-developing, reviewing or endorsing zJPYC. zJPYC is not a JPYC Inc. product; it is an unofficial third-party wrapper.

What is visible on-chain, and what is not

Using zJPYC breaks down into four steps on the public ledgers.

The only thing that is not visible is which send in step 2 corresponds to which claim in step 3. The link is severed, but both the moment funds enter the pool and the moment they leave it are on record.

zJPYC in numbers (June 8 – September 18, 2026)

Transfer counts run through September 18; balances are as of September 25. *Kaia deposits and payouts are derived from zJPYC mint and burn events; their difference matches the held balance.

On Polygon, deposits minus payouts equal the held balance of 1,211,935 JPYC exactly. Across both chains there were 12,010 private sends, from 261 sending addresses to 9,850 one-time addresses. Only 49 of those one-time addresses ever sent anything afterwards.

Counting any role — deposit, send, claim or redemption — 296 distinct addresses took part. By role, 112 addresses deposited, 94 redeemed and 245 received claims.

Private sends by month:

The median private send is 3,000 JPYC. The most frequent amount is 10,000 JPYC (3,540 times), followed by 100,000 JPYC (1,372 times), and 56% of private sends are round amounts of 1,000 JPYC or more. The largest single send was 5,000,000 JPYC. A distribution in which the same round amounts recur this often looks more consistent with campaign- or airdrop-style distribution than with individual payments. That is an observation about the distribution only; the actual purposes were not confirmed.

There is also a cross-chain pattern. Kaia saw only 18 deposits (wraps), yet 4,217 claim transactions. Value mostly enters on Polygon and leaves on Kaia — the ability to claim on a different chain is being used in practice.

Note that total private-send volume runs to hundreds of millions of JPYC, far above the roughly 11.7 million JPYC ever deposited. The same zJPYC can be claimed and re-sent any number of times, so volume totals should be read as sums over events, not as the amount of value that actually entered the pool.

Where this sits for AML

Privacy protocols are legal tools with legitimate uses — for example, businesses or individuals who do not want counterparties or salaries exposed on a public ledger. Using one is not in itself a sign of wrongdoing.

For AML (anti-money laundering) practice, though, the realistic stance is to treat the pool boundary the way you would treat a mixer boundary: rather than trying to rebuild the link, know when funds entered the pool and when they left it, and apply due diligence proportionate to the amount. Attribution across the pool cannot and should not be asserted.

JPYC's own controls live in the JPYC token contract and do not reach inside the wrapper. Inside the pool the value circulates as zJPYC; it becomes JPYC again only at redemption.

How ChainAnalyzer handles it

• ChainAnalyzer registers the zERC20 contracts (zJPYC and the zETH, zUSDC and zBNB pools) as privacy-protocol entities. If a screened address has deposited into or withdrawn from a pool, the scan shows a "privacy protocol" finding with the number of interactions and the total amount.
• The JPYC issuer dashboard shows the JPYC balance held by the pool on each chain.
• It does not re-link senders and recipients, and by design it cannot.

Method and limitations

• Data comes from the public ledgers of Polygon and Kaia.
• Events are classified as deposits, sends, claims or redemptions by the type of interaction with the contracts listed above.
• Counts and amounts are event totals; when the same value is sent and claimed repeatedly, each occurrence is counted.
• The pool is in continuous use, so the figures change daily.
• "Addresses" are not people, and this article makes no attribution of any address to any person or entity.

Anyone who wants to check whether a counterparty's address has passed through a privacy protocol can try a free scan at chain-analyzer.com. For business use or bulk screening, please get in touch via our contact page.

This article is an analysis based on public information and is not a recommendation to use, buy or sell any crypto asset or service.