AmericanFortress has proposed a way to prove that selected wallet addresses or keys share a hidden origin without revealing the wallet seed, derivation paths or other addresses. The useful distinction in its new preprint is who can recognize that relationship: the holder could show it for one transaction, let a service link proofs within a defined context, or reserve linking for a designated authority. This is a cryptographic design, not a feature already available in a wallet or bridge. The paper was received on September 24, 2026, and approved for the Cryptology ePrint Archive on September 27; The Next Web reported on it on September 24.
A shared origin is the claim the verifier checks
Hierarchical deterministic wallets can derive many public addresses from hidden wallet material. AmericanFortress's earlier ZKPoSP preprint described a proof that an individual public value was derived from a hidden origin. The new work asks a different question: can a verifier check that several such values share an origin, including values used on different chains, without seeing that origin?
The authors' Bitcoin-to-Solana example makes the distinction concrete. A service handling a transfer could ask for proofs tying a Bitcoin source address and a Solana payout address to the same seed, then refuse a payout address that fails the check. The paper's protocol also binds the proofs to the transaction and requires the service to verify the deposit. Under that modeled workflow, a substituted destination address would not pass simply because an attacker supplied it. The authors explicitly say their exchange integration is a design only; no service integration was performed.
This proves a defined cryptographic relationship. It does not by itself establish the holder's real-world identity, the lawful origin of funds, or that a bridge's other controls are sound. Those are separate questions a service would still have to answer.
Linkability determines the privacy tradeoff
A proof that connects addresses is useful precisely because someone can recognize the connection. The paper offers four constructions with different scopes. In one, only the holder can assemble a joint proof; a deferred version lets the holder link selected earlier proofs later. Another places a tag in a defined context, allowing anyone who sees proofs in that context to connect them. A fourth encrypts that tag so only a designated authority can make the link.
That choice changes what a verifier can learn after the first check. A context confined to one transfer can support that transfer without becoming a reusable cross-service identifier. A broader context could expose more of a wallet's activity to whoever receives the proofs. The paper models these boundaries, but their practical privacy would depend on the context a future product chooses and on what transaction metadata it retains.
The implementation evidence has a narrow scope
The authors report Plonky3 benchmark results for individual derivation proofs. They state that they did not measure the extra work added by the full provenance constructions, so those figures are a lower bound rather than a service-level performance result. The security argument is a preprint under stated assumptions, and its post-quantum claim depends on the underlying proof system and other components; it is not an independently demonstrated guarantee for a deployed wallet.
The paper also says the work is subject to pending AmericanFortress patent applications and grants no patent license. A wallet or exchange developer therefore has more to establish than whether the idea is mathematically interesting: full-system performance, external security review, integration behavior and licensing remain open. For a wallet user today, there is no new setting to turn on. The meaningful development is a more precise proposal for when address linkage can be proved and who is allowed to see it.