Hi everyone,
I’d like to propose a new ERC: Token Launch Abuse Detection and Remediation: attested detection of rug pulls and other deployer abuse, with escrowed proceeds enabling pro-rata refunds and bonded restitution.
The premise is that most token buyers are not harmed by an anonymous trading cohort. They are harmed by the person who created the token. So the subject of detection is the deployer, the enforcement point is the venue, and the remedy has to act while the money is still reachable.
Three composable parts:
Detection. A taxonomy of ten deployer abuse patterns (hard and soft rug pulls, undisclosed insider allocation, sniper coordination, honeypots, mint dilution, retained control, wash launch, unlock exit, serial deployer), each with a reference weight profile, scored from a fixed twelve-signal vector into an abuseScore of 0-100. Reports are published by bonded detectors and commit to chain-anchored evidence leaves, so a third party can recompute the vector from public state and prove a report false. That is what makes the bond enforceable rather than decorative.
Escrow. The launch venue records every purchase and releases proceeds to the deployer on a linear schedule (capped at 90 days) instead of forwarding them immediately. Because the venue already knows every buyer and amount, refunds need no individual claim and no enumeration of victims.
Remediation. A deployer bond posted before launch, bonded claims with a 72-hour contest window and a mandatory bilateral settlement path, and pro-rata refunds pulled by buyers from escrow with any shortfall drawn from bond. Refund is unreachable by automated containment; it requires an upheld claim with a right to contest.
The load-bearing design decision is conduct, never outcome. Price decline, drawdown, market capitalization and holder losses are forbidden as scored signals. Every signal describes an action the deployer took: what they retained, what they locked, what they sold, what they withdrew, what powers they kept. Most launches fail honestly, and a standard that scores price decline flags every failed project as a rug. A buyer’s loss establishes standing to bring a claim. It never establishes that abuse occurred.
Two conformance levels are defined, because the escrow is the expensive part to adopt. Detection conformance (directory, registry, guard) lets a venue publish and consult scores with no escrow and therefore no remedy. Full conformance adds escrow and remediation and is the only level at which a buyer can be refunded. A detection-conformant deployment must not describe itself as offering refunds.
The design depends on: ERC-20, ERC-165, EIP-214.
A self-contained Foundry reference implementation accompanies the draft: every interface, all ten scoring profiles, 178 tests, and four fuzzed invariants covering fund conservation and escrow solvency at 128,000 calls each.
Early feedback I’d like to hear:
Is the twelve-signal vector the right set? Four of them (insider allocation, sniper concentration, wash trade ratio, cross-chain prior claims) cannot be verified on-chain and depend on funding-graph clustering. Is that split acceptable, and is anything obviously missing?
Detection quality is the open problem, not the on-chain machinery. The draft forbids automated containment above Flag on a detector whose accuracy has not been measured. Is there appetite for a shared, public corpus of labeled historical launches (known rugs and known honest failures) so precision and recall can be compared across detectors?
Bond sizing currently says requiredBond MUST scale with the raise and SHOULD NOT be less than 25 percent of it. Venues competing on volume will be tempted to set this low. Should the floor be a MUST, and is 25 percent the right number?
Adjudication is the most concentrated trust in the design. The draft requires the adjudicator address to be immutable and its reasoning published, recommends n-of-m or optimistic schemes, and ships a committee implementation. Is that enough, or should a specific model be mandated?
Does the detection-only conformance tier help with adoption, given that most rugs today happen on venues with no escrow at all?
Anything immediate on the escrow accounting, the pull-refund model, or the freeze-with-expiry behavior?
I’ll open a PR to the ethereum/ERCs repo. Feedback and questions are all welcome, particularly from anyone running a launch venue who can say whether holding proceeds on a schedule is realistic in practice.
Thanks for reading!
Leigh
@cybercentry
cybercentry.base.eth