The KYC Was About a Person. The Claim Was About a Wallet.
I think that is the assumption people start with.
If a claim is KYC-gated, then identity is doing the heavy lifting. The person proves who they are, the system records that fact, and the distribution logic uses that proof to decide whether value can move. Clean. Severe, maybe, but clean. Human identity first. Wallet second.
Then Sign gets dropped into the middle of the flow and the shape changes.
In Sign’s own KYC-gated claim example, the claimer completes KYC, binds a wallet address to that KYC status through a Sign attestation, and then TokenTable’s Unlocker contract validates that attestation before allowing the wallet to claim. In the ZetaChain case study, this was paired with Sumsub and used to gate claims for recipients subject to compliance checks.
That design is appealing for obvious reasons.
It turns a soft, messy, off-chain verification event into something a claim contract can actually enforce. No hand-wavy “trust us, this user passed KYC.” No manual review sitting in the payout path. Sign Protocol ports the verification result into a form TokenTable can read, and the wallet that holds the right attestation gets access to claim. For a distribution system, that is elegant in the way elegant things usually are right before they become somebody’s problem.
The paradox only shows up later.
Because the KYC check feels like the identity system, but the wallet binding is what the money actually obeys.
That distinction sits there quietly until the person and the wallet stop feeling like the same object.
Not fraud. Something meaner because it is ordinary. The user passed KYC correctly. Government ID, liveness, all the ugly compliance ritual done. They bound the wallet because that was the wallet they were using at the time. Then life kept moving. Maybe they rotated to a safer address. Maybe custody changed. Maybe the original wallet is still theirs in some technical sense but no longer the one they trust to receive the claim. Maybe recovery happened after the attestation was already in place.
And now the system has a very uncomfortable kind of truth in it.
The person is still eligible.
The wallet is what counts.
That is where Sign stops looking like broad identity infrastructure and starts looking like a narrow machine that forces a harder question: what, exactly, is the operative identity at payout time? The docs say the Unlocker validates the KYC attestation and enables the associated wallet to claim. That means the enforcement point is not simply “this human passed.” It is “this wallet carries the right proof of that human having passed.”
Real-world consequence lands fast there. If the value is meaningful — an airdrop, a regulated distribution, access to capital, whatever version of consequence we are talking about — then changing the wallet is no longer a support preference. It becomes a governance action. Someone has to decide whether updating the wallet preserves identity or rewrites it. Someone has to own the risk of saying yes.
And that is the part that stays open in my head.
If Sign proves the right person satisfied KYC, but TokenTable will only release value to the bound wallet the attestation was built around, then when the two drift apart, who is actually authorized to say the person is still the same claimant in a form the contract should trust?