Skip to content

PACTCLANKER: design docs + PartyClanker PRD (Model B rev 2)#1

Draft
zherring wants to merge 35 commits into
mainfrom
pactclanker
Draft

PACTCLANKER: design docs + PartyClanker PRD (Model B rev 2)#1
zherring wants to merge 35 commits into
mainfrom
pactclanker

Conversation

@zherring

Copy link
Copy Markdown
Collaborator

What this is

Design-docs-only branch for PACTCLANKER — a fork direction that strips PACT down and re-aims it at crowd-launching a vanilla Clanker coin. No code changes yet; this PR exists to collab on the mechanism design before anything gets built.

Contents

  • docs/pactclanker-prd.md — the main document. Two models:
    • Model A: stripped-down PACT (kept for contrast)
    • Model B rev 2 (working name: PartyClanker) — the favored direction: crowd pools USDC all-or-nothing → one settlement tx does a completely vanilla Clanker v4 launch (DevBuy funded by the pool, Vault as the early-backer bonus, trading fees → a Liquid Split forever). Nobody is paid; the settlement contract is the creator-of-record and provably can't keep anything.
  • docs/pact-equity.md / docs/pact-note.md — earlier PACT design notes (v1 fixes, waterfall/cap variant), kept as reference; not appropriate for main as-is.

Decided (see Design decisions in the PRD)

  • DD-2: 0% founder anything at v0 — creator's edge is the time-weighting's natural advantage
  • DD-3: linear dollar-seconds accumulator (MetaDAO-style, verified against their docs), no fill boost; composes with the vault (vault = why commit before TGE, accumulator = why commit early in the window)
  • DD-5: raise in USDC, pool pairs WETH, one USDC→ETH swap in finalize (DevBuy is ETH-denominated regardless; USDC isn't a supported Clanker quote token)

Open — input wanted (@abramdawson)

  • DD-1: withdrawal policy — lock vs withdraw-any-time-with-pro-rata-weight-wipe (leaning withdrawable; both are exploit-free, writeup has pros/cons)
  • DD-4 params: max-raise cap sizing, min-deposit floor, dust-refund threshold
  • ClankerUniv4EthDevBuy output routing (first thing to verify in their contracts)
  • "50+ day-one holders" vs everything-streams tension, vault multiple/stream ratio, unit transferability, platform fee share

🤖 Generated with Claude Code

zherring and others added 10 commits July 15, 2026 17:53
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… a product choice

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… + complexity budget

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…pose, DD-2/3/5 decided, DD-4 dust/min/max

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…-model.html)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…6 readouts

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…yping preview, model modal, floating mock-state card

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread docs/pact-equity.md

## Design changes

### 1. `sweepDistributions()`

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm i need to think about this. seems potentially tricky and confusing. i think if the clanker token is spitting off fees, conceptually that should drive up the share price of the offering, since that's essentially saying "this thing is more valuable now". idk the right mechanism/how to capture this, but conceptually i think that's how it should work (open to feedback/pushback).

which, if the treasury were to use that proceeds to buy tokens from the offering, that would push up the price…

…onfetti yolo, armed Yolo button

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread docs/pact-equity.md

### 2. Escrowed unit delivery until `minMet`

Recommended fix for the refund exploit: hold purchased units in the Offering

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't love separating buy from claim. buying something and not getting it right away feels anti what this tech should enable.

Comment thread docs/pact-equity.md

Alternatives considered:

- Clawback on refund via ERC-1155 operator approval granted at buy time —

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strongly against this, since it means "these aren't your tokens" if the project creator can take them from you.

…treatment, steady armed Yolo

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread docs/pact-equity.md

## Pricing

Because a unit is a claim on an observable revenue stream, the curve can be

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this true? the early revenue stream is from,, snipers? ig me not understanding this is probably indicative of a lack of deeper understanding…

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this is true, and in that case it's really not a pact at all, since this is not a placeholder - you are buying a portion of the revenue stream.

Comment thread docs/pact-equity.md

- Should `sweepDistributions()` run automatically inside `buy()` /
`closeAndWithdraw()` to keep balances clean, or stay a separate call?
- Escrowed delivery changes the buyer receipt UX ("you hold a claim until the

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something needs to show up in their wallet.

…fees fixed; math box states the rule

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread docs/pact-note.md
read that first. Assumes the revenue-first posture (revenue routed before
launch) and the v1 fixes (distribution sweeping, escrowed unit delivery).

## Thesis: seniority and a cap

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something something this is like "a financing in a box" - you bring the business (economically productive asset), the software offers the guardrails/interface/etc for everything else.

zherring and others added 11 commits July 16, 2026 14:19
…ade fee

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… copy, Back button, ETH input suffix

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… to max

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…-bump state

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ling

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
zherring and others added 11 commits July 16, 2026 17:06
The Party list kept replaying its entrance/flash animations while idle.
Root cause was not the FLIP (correctly rank-gated) nor preview-drift, but
that `Row` was defined *inside* `Partiers`. Every ambient-drift render
(~12.5x/sec while phase==='funding') gave `Row` a new function identity, so
React treated it as a different component type and tore down + rebuilt every
row's DOM. Each rebuild re-mounted the you-row, replaying the `.enter`
pop-in (measured: 125 firings in 10s of pure idle) and re-firing the
`.just-bumped` flash on every tick. WAAPI FLIP stayed at 0 the whole time,
which is why prior static/reflow-only checks missed it.

Fix: hoist `Row` to module scope so its identity is stable across renders.
React now preserves row nodes across ambient re-renders — pop-in fires once
on real entry, bump-flash once per real active->dust fall, and FLIP still
springs on genuine rank changes. `justBumped` is now passed in as a `bumped`
prop since the closure no longer lives beside the JSX.

Verified via Playwright (animationstart + Element.animate instrumentation):
idle and typed-preview scenarios now log ZERO list animations over 10s
(down from 125 pop-ins); real entry/overtake/dust-fall still fire exactly
the expected one-shot animations. npm test 17/17, build clean.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…indings

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ly share

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ec, invariants, references; vendor v0 build prompt + crowd model into docs

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…les to launcher wallet

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…her never vanishes

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ErhEzWHTduozGt7LQKfqaX
…the Party contract

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… no launcher special-casing

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants