Why isn't a per-wallet sell limit enough?

A per-wallet cap is trivially evaded by splitting a position across many wallets before selling -- each wallet stays under its own limit while the combined dump proceeds at a multiple of the intended rate. The cap has to follow the beneficial owner, not the address.

How does ProofGuard know which wallets belong to the same owner?

Every wallet participating in a ProofGuard-protected pool resolves to a beneficial-owner-group identifier produced by an upstream KYC/KYB-bound identity-clustering process. The sell-throttle check reads that resolved group identifier, not the raw wallet address, when computing how much of the group's allowance remains.

What is the default sell limit?

By default, a beneficial-owner group may sell up to 10% of its aggregate unlocked balance within a rolling 72-hour window. Both figures are policy-configurable per launch without a code change.

What else does the sell-check pipeline verify before a sell is approved?

Before the owner-aggregated limit is even evaluated, the pipeline checks that the holder is KYC/KYB-approved, that neither the wallet nor the beneficial owner is frozen, that the owner's jurisdiction isn't prohibited, and that the pool itself isn't frozen or paused. Only a request that clears every prior check is measured against the rolling-window limit.

Beneficial-Owner-Aggregated Sell Throttle Over a Clustered Identity Graph

Executive Summary

Coordinated dumping is rarely executed from a single wallet. A holder who anticipates a sell-rate cap simply pre-funds a set of additional wallets from the same source of capital before the cap ever applies, then sells the same fraction from each wallet in parallel. Any limiter keyed on the selling address alone is defeated the moment a second wallet enters the picture.

ProofGuard's sell-throttle module resolves every selling wallet to a beneficial-owner-group identifier before evaluating any limit. That identifier is the output of an upstream KYC/KYB-bound identity-clustering process — it is not self-declared by the holder. The rolling-window sell-rate cap, and the unlocked-balance figure it is computed against, are then evaluated against the sum of every wallet sharing that group identifier, not against the requesting wallet in isolation.

Core Innovation: The cap follows the beneficial owner, not the address. Splitting a position across additional wallets does not create additional sell allowance, because every wallet the clustering process attributes to the same owner draws against one shared, continuously-updated allowance.

Problem Statement

Anti-whale and anti-dump mechanisms embedded directly in ERC-20-style token contracts almost universally key their limits on the transacting address. That design assumes one economic actor equals one wallet — an assumption coordinated actors routinely violate by distributing a position across a set of wallets ahead of a launch, then executing parallel sells that each individually clear the per-wallet threshold.

10%

Max share of a beneficial owner's unlocked balance sellable per rolling window (default policy)

72h

Rolling window over which owner-aggregated sell volume is measured (default policy)

1

Identity graph to defeat under JIL's model, versus one cap per wallet an actor can simply multiply under a per-wallet model

Why Per-Wallet Limits Are Insufficient

ERC-20 anti-whale contracts: Enforce a fixed percentage-of-supply cap per transacting address with no concept of common ownership across addresses.
Onboarding-only KYC: Many platforms verify identity once, at account creation, but never reuse that identity as a persistent key for later transaction-level enforcement.
Static whitelists: Manually curated "known whale" lists degrade immediately as new wallets are generated and go unrecognized until manually added.

Technical Architecture

Wallet-to-Owner Resolution

Every sell check begins by resolving the requesting wallet to its beneficial-owner-group record, which carries the group's KYC/KYB status, jurisdiction status, and freeze state alongside the group identifier itself. A wallet with no resolved group, or a group whose KYC/KYB status is not approved, is rejected before any balance or limit math runs.

Group-Scoped Balance and Window Computation

Locked balance, unlocked balance, and already-sold volume within the rolling window are each computed as a sum across every locked-lot or sell-event record sharing the resolved beneficial-owner-group identifier — falling back to the individual wallet identifier only when no group has been resolved. The sell ceiling itself is computed as a fixed percentage of the group's aggregate unlocked balance, and a pending sell is rejected if the group's already-recorded window volume plus the pending amount would exceed that ceiling.

Check Order	Condition	Basis
1	Holder KYC/KYB approved	Beneficial-owner group
2	Wallet and owner not frozen	Wallet + group
3	Jurisdiction not prohibited	Beneficial-owner group
4	Pool not frozen or paused	Pool state
5	Requested amount within unlocked balance	Group-aggregated locked lots
6	Rolling-window sell volume + request within owner limit	Group-aggregated sell events
7	No active hard circuit breaker	Pool market state
8	Stress-mode size cap (oversize routes off-curve)	Pool stress mode

Persistent, Group-Keyed Recording

Every approved, rejected, or rerouted sell is recorded with the resolved beneficial-owner-group identifier attached, so the next request against any wallet in that group reads a window sum that already reflects every prior sell by every wallet in the cluster — the aggregation compounds correctly across an unlimited number of wallets without requiring a fixed enumeration of which wallets belong to the group at query time.

Prior Art Differentiation

Approach	Limit Basis	Defeated by Wallet-Splitting?	Identity Source
ERC-20 anti-whale contract	Per transacting address	Yes	None
Static whale whitelist	Manually curated address list	Yes (new address)	Manual
Onboarding-only KYC	Verified once, not reused	Yes	One-time
JIL ProofGuard	Beneficial-owner cluster	No	Persistent identity-clustering process

Patent Claim

Independent Claim 68: A computer-implemented method for throttling token sell volume comprising: resolving a selling wallet address to a beneficial-owner-group identifier derived from a KYC/KYB-bound identity-clustering process; computing, over a rolling time window, the aggregate sell volume already attributed to every wallet sharing that beneficial-owner-group identifier; computing a sell-rate ceiling as a fixed percentage of the beneficial-owner-group's aggregate unlocked token balance; and rejecting a pending sell request when the sum of the group's already-recorded window volume and the pending amount would exceed the ceiling, irrespective of how much of that ceiling has been consumed by the requesting wallet individually versus other wallets sharing the same beneficial-owner-group identifier.