Project Custard: Confidential Payments Are Live on X1, and the Transfer Amount Is Nowhere in the Transaction

At 4:26 AM on August 19, 2026, Jack Levin — posting as Cyphereus Prime in Jack's Office, his own topic inside the X1 World Telegram group — announced that confidential payments are real on X1. It arrived the way most things from him do: four consecutive one-line messages, no preamble.

Project custard

Confidential transfers

It's a demo or a Token 2022 cUSDc

Which hides transfer amounts

Jack Levin (Cyphereus Prime) — Jack's Office, X1 World Telegram, Aug 19, 2026, 4:26 AM

Project Custard — the name is a pun on the ticker, cUSDC — is a working demonstration of the Token-2022 ConfidentialTransfer extension running on X1 mainnet. Alongside the messages Levin dropped the full report behind them, and it is not a summary: thirteen signed transactions walk a purpose-built token from a public mint, into an encrypted compartment, through a private transfer, and back out the other side. Every step carries a signature. Every signature is on mainnet.

X1 Report pulled those signatures from rpc.mainnet.x1.xyz and decoded the flow byte by byte, because the interesting part of a confidential transfer is what is missing from it. The report is dated August 18; the transactions confirmed just after midnight UTC on the 19th. Everything below is what the chain itself returns.

What actually happened

Project Custard used a purpose-made token — mint 9E4UKVfn9HvqnGKsazKc7TQqfYYe5dusPc4Q3u3MMMph, six decimals, named "Confidential USDC" — issued under X1's SPL Token-2022 program at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb. Two wallets played sender and recipient. The account approve policy was set to auto and no auditor key was attached, meaning nobody outside the two holders can decrypt anything.

The full run took just over two minutes of wall clock. The first transaction landed at 01:19:27 UTC and the last at 01:21:30 UTC, spanning slots 72,619,645 to 72,619,981.

Note the shape of it. Money enters the private compartment in public and leaves it in public. What happens inside — the balances, and any number of transfers between confidential accounts — is opaque. That is the design of Token-2022 confidential transfers, and it is worth understanding before anyone calls it a privacy coin.

The evidence: two instructions, one missing number

The cleanest proof in the report is also the simplest. Take two instructions issued to the same token program in the same demo and compare their raw bytes.

The public mint of 100 cUSDC is ten bytes long:

0e 00 e1 f5 05 00 00 00 00 06

Byte 0 is the opcode. Bytes 1–8 are the amount as a little-endian u64: 0x05f5e100 = 100,000,000 = 100.000000 cUSDC. Byte 9 is the decimals check. Nothing is encrypted, and nothing needs to be — the value is simply written down in the clear, which is how every SPL token transfer has always worked.

The confidential transfer of 25 cUSDC is 169 bytes — roughly seventeen times larger — and begins:

1b 07 34 df 97 3c 2b 82 65 1d 01 05 9b e6 39 3c 50 76 de 58 94 7b 08 7e 70 17 2a b0 4e a5 52 0f …

We decoded the instruction data ourselves and searched all 169 bytes for the little-endian encoding of 25,000,000 — 40 78 7d 01 00 00 00 00. It is not there. What is there instead is 167 bytes of ElGamal ciphertext and proof context references. The number the sender chose exists nowhere in the transaction that moved it.

What we checked ourselves

Every signature in the report is public, so we ran the checks ourselves. Here is what a direct query of X1 mainnet returned:

• The transfer confirmed. Signature 23RyYidPRngRtD4XqbUZPbZMngG4GQPxetJejZ7zWobxJMRcnyDAWwZVeettzmRXbBTajkytVMxK8Rocs3XYwUev, slot 72,619,946, error null.
• The program log names the instruction. Program log: ConfidentialTransferInstruction::Transfer — this is not a wrapped or simulated call.
• The instruction data is 169 bytes and contains no plaintext amount, confirmed by byte search.
• The ZK proof program exists and is executable. ZkE1Gama1Proof11111111111111111111111111111 is present on X1 mainnet, owned by the native loader. Without it, none of this verifies.
• The mint is real. Supply 100 cUSDC, six decimals, live now.
• The end state matches. The sender's public balance is 0; the recipient's is 25, exactly as a withdraw-after-private-receive would leave it.

What stays public, and what does not

It is worth being precise about the scope: Token-2022 hides how much, not who. An observer still sees that two specific accounts transacted. What they cannot see is the size of it, which is the difference between a public ledger of every salary payment and a public ledger that merely shows an employer paid an employee.

How the amount stays hidden

Four mechanisms carry the weight, and none of them require the token program to be trusted with plaintext.

Twisted ElGamal encryption. Every confidential balance is stored as ciphertext under the holder's own 32-byte ElGamal public key. Sixty-four-byte ciphertexts, split high and low to cover 64-bit values. The chain stores encrypted numbers and does arithmetic on them without ever decrypting.

Zero-knowledge range proofs. The sender proves that 0 ≤ amount < 2⁶⁴ and that their remaining balance is still non-negative after the transfer — without revealing either figure. This is what stops someone from transferring a negative amount and minting value out of nothing.

Equality proofs. The sender proves that the amount subtracted from their ciphertext is exactly the amount added to the recipient's, so the two sides balance even though neither is legible.

Client-side generation, on-chain verification. The proofs are built by the sender's own machine and checked by the native ZkE1Gama1Proof program. The token program itself never sees a plaintext amount at any point in the flow.

There is one convenience layer on top. Alongside the ElGamal ciphertext, each account stores an AES-encrypted "decryptable" copy of its balance, readable only by the holder. ElGamal decryption for arbitrary 64-bit values is slow; this lets a wallet display your balance instantly without grinding through a discrete log.

What privacy costs on X1

Cryptography is not free, and the compute numbers make the premium concrete. The public mint of 100 cUSDC consumed 1,959 compute units for a fee of 21,090 lamports. The confidential transfer of 25 cUSDC consumed 30,966 compute units for a fee of 312,660 lamports.

That is roughly a 16× compute premium for hiding the number — and at current XNT prices it works out to about $0.00016, or under two hundredths of a cent. On a chain with X1's fee structure, the cost of confidentiality is real in compute terms and irrelevant in dollar terms. That ratio is the whole argument for doing this on an SVM chain rather than a rollup.

Three caveats worth stating plainly

The report is unusually candid about its own limits, and they matter.

Mint and burn amounts are still public. The ConfidentialMintBurn extension is not enabled here — neither the spl-token CLI nor the JavaScript SPL library currently ships client helpers for it. Issuance and destruction remain visible; only account balances and transfer amounts are encrypted.

Addresses are not hidden. This is worth repeating because it is the most common misreading. Confidential transfers conceal value, not participants. Sender/recipient unlinkability needs a separate layer — stealth addresses, or a mixer, neither of which is what this is.

No auditor is configured. In this demo, nobody can decrypt these balances, including regulators. Token-2022 supports an optional auditor ElGamal key that can read amounts; the demo deliberately left it off. Any real-world deployment — a compliant stablecoin, a regulated payment rail — would likely turn it on. That decision belongs to the issuer, and the extension supports either answer.

Why this matters for X1

Confidential transfers are not new to Solana's Token-2022 program in the abstract. What the report demonstrates is that the entire stack — the extension, the ZK proof program, the client tooling, the fee economics — is functional on X1 mainnet today, unpatched and end-to-end. A chain can advertise a Solana-compatible runtime and still be missing the native ZK program that makes any of it verify. X1 is not missing it.

The practical target is obvious enough. X1 already carries bridged USDC.X, and the argument against putting payroll, treasury operations, vendor payments or OTC settlement on a public ledger has always been the same one: you do not want your counterparties reading your balance sheet in real time. A stablecoin with confidential transfers switched on removes that objection without asking anyone to trust a new chain, a new bridge, or a new cryptographic assumption — the extension is upstream SPL code, audited and deployed.

The demo can be checked by anyone. One command against the public RPC returns the transaction, and the raw instruction data speaks for itself:

solana confirm -v 23RyYidPRngRtD4XqbUZPbZMngG4GQPxetJejZ7zWobxJMRcnyDAWwZVeettzmRXbBTajkytVMxK8Rocs3XYwUev

Levin's announcement was four lines long. What sits underneath it is a signature anyone can pull from a public endpoint, decode, and search for a number that is not there — the rare kind of privacy claim that does not require taking anyone's word for it. That is what landed in Jack's Office at 4:26 in the morning.