Non-Custodial Proof-of-Holdings via Challenge-Response

Executive Summary

pJIL is a non-custodial proof-of-holdings primitive: a user proves control of a self-custody blockchain address by signing a single-use challenge message, without JIL ever touching a private key, initiating a transaction, or gaining any access to the address's assets. Once control is verified, the system reads public on-chain state for that address, runs it through address-forensics screening, and mints a court-chain-sealed proof artifact asserting a specific predicate - in the current release, "controls: true" - that a third party such as a lender, bank, or court can verify independently at a public, unauthenticated endpoint.

The proof deliberately withholds the underlying balance and the address itself from the public verification response - a relying party learns that the asserted predicate is true and sealed, not the number behind it - matching a "public asset, private linkage" design principle: the fact of provable holdings is what's shared, not the holdings themselves or the identity behind them, unless the proof's own issuer chooses to attach an identity reference.

Because pJIL only ever requires a signature over a server-issued, single-use nonce, it works for any address the user already controls in any wallet software, and never puts JIL in a position to move, freeze, or even see the address's private key material - a materially different trust model than a Merkle-tree custodial proof-of-reserves, which requires trusting the entity that already holds the funds to publish an honest snapshot of its own liabilities.

Core Innovation: A court-chain-sealed, publicly-verifiable holdings predicate minted from nothing but a signature over a single-use challenge - no transaction, no custody, no private-key exposure at any point.

Problem Statement

Proof-of-reserves as commonly implemented - an exchange-published Merkle proof - proves something about a custodian's balance sheet, not about an individual's self-custody holdings, and it requires trusting the custodian's own snapshot process. Self-custody wallet users who need to demonstrate holdings to a third party - a lender underwriting a loan, a landlord, a court in an asset-disclosure proceeding - have had no non-custodial equivalent: either they hand over read access indefinitely through an open-ended "connect wallet" grant with no lifecycle or sealing, or they export and manually notarize a screenshot, which is trivially falsifiable and carries no cryptographic integrity.

Technical Architecture

End-to-End Flow

Step	Operation	What Happens
1. Challenge	Request a signature challenge for an address	The server generates a 32-byte random nonce, builds a message ("Prove control of this address for a pJIL proof. Nonce: <nonce>"), and persists it with a 5-minute expiry in a durable store, surviving restarts and multi-instance deployment - replacing an earlier in-memory nonce store used by a prior claim flow
2. Sign	Client-side, in the user's own wallet	The user signs the exact challenge message with the address's private key; no transaction is ever broadcast
3. Verify control	Internal, on mint	The server recovers the signer address from the signature via public-key recovery and checks it matches the claimed address, that the challenge is unexpired, belongs to the requesting user, and has not already been consumed; the challenge is marked consumed on success - single-use, never replayable
4. Screen	Internal	The address is run through address-forensics screening; a blocking outcome (sanctions/high-risk) aborts minting before any proof is created - fail-closed
5. Mint	Mint the proof	Public on-chain balance state is read; a canonical payload (user, chain, address, proof type, predicate, block number, screening outcome, issued/expiry timestamps) is hashed with SHA-256, sealed, and persisted; a full before/after event row is appended to an append-only event log
6. Verify	Public, unauthenticated	Returns authenticity, integrity, freshness, and status - explicitly excluding the balance snapshot and the address itself

Sealing Mechanism

The proof is sealed with a real multi-signer Ed25519 seal - independently-keyed primary and co-validator signers each sign the same canonical preimage, which binds the proof's scope, source address, payload hash, and anchoring block height. This is documented in the implementation itself as the bootstrap path for an eventual larger validator-quorum seal - today's implementation is a smaller, real multi-signer construction, with a larger validator-quorum seal as the roadmap target, not a claim about current operating scale.

Lifecycle

Proofs are point-in-time and expire after a fixed retention window (90 days in the current release). Revocation is a status change only, under an immutable-record rule - a revoked proof is never deleted, so the public verify endpoint continues to reflect a proof's full history rather than making it disappear.

Prior Art Differentiation

Model	Trusts the Asset Holder's Own Snapshot?	Requires Handing Over Wallet Access?	Reveals Balance to the Relying Party?
Exchange-published Merkle proof-of-reserves	Yes - custodian publishes its own liabilities snapshot	N/A - custodial	Sometimes (aggregate only)
"Connect wallet" / Sign-In-With-Ethereum	No	Yes - typically an open-ended read/interaction grant	N/A - proves control only, no predicate or seal
Manual notarized screenshot or letter	Yes - trivially falsifiable	No	Yes, and unverifiable
JIL pJIL	No - self-custody, single-use signature challenge only	No - never requests a transaction or ongoing access	No - predicate only, balance withheld by design

Patent Claim

Independent Claim 5: A computer-implemented method for issuing a non-custodial proof of holdings comprising: generating a single-use, time-bounded challenge message bound to a requesting user and a claimed blockchain address, and persisting the challenge in a durable store; receiving a cryptographic signature over the exact challenge message and verifying, via public-key recovery, that the signature was produced by the claimed address's private key, while consuming the challenge so it cannot be reused; upon successful verification, screening the claimed address against a sanctions/risk classification service and aborting proof issuance on a blocking classification; reading public on-chain state for the claimed address and computing a cryptographic hash over a canonical payload comprising the asserted predicate, the on-chain block reference, and the screening outcome, without transmitting the underlying balance into the hashed payload's public-facing counterpart; sealing the resulting proof with a multi-signer cryptographic seal bound to the payload hash and an anchoring block height; and exposing an unauthenticated verification endpoint that returns the proof's authenticity, integrity, and freshness status while withholding the underlying balance and address from the response.