PACTCLANKER: design docs + PartyClanker PRD (Model B rev 2)#1
PACTCLANKER: design docs + PartyClanker PRD (Model B rev 2)#1zherring wants to merge 35 commits into
Conversation
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>
|
|
||
| ## Design changes | ||
|
|
||
| ### 1. `sweepDistributions()` |
There was a problem hiding this comment.
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>
|
|
||
| ### 2. Escrowed unit delivery until `minMet` | ||
|
|
||
| Recommended fix for the refund exploit: hold purchased units in the Offering |
There was a problem hiding this comment.
i don't love separating buy from claim. buying something and not getting it right away feels anti what this tech should enable.
|
|
||
| Alternatives considered: | ||
|
|
||
| - Clawback on refund via ERC-1155 operator approval granted at buy time — |
There was a problem hiding this comment.
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>
|
|
||
| ## Pricing | ||
|
|
||
| Because a unit is a claim on an observable revenue stream, the curve can be |
There was a problem hiding this comment.
is this true? the early revenue stream is from,, snipers? ig me not understanding this is probably indicative of a lack of deeper understanding…
There was a problem hiding this comment.
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.
|
|
||
| - 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 |
There was a problem hiding this comment.
something needs to show up in their wallet.
…fees fixed; math box states the rule Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| 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 |
There was a problem hiding this comment.
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.
…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>
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
…d, launcher never vanishes" This reverts commit af8f028.
…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>
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
Decided (see Design decisions in the PRD)
Open — input wanted (@abramdawson)
ClankerUniv4EthDevBuyoutput routing (first thing to verify in their contracts)🤖 Generated with Claude Code