Pith. sign in

REVIEW 3 major objections 4 minor 28 references

Interactive coin offerings

T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that a token crowdsale can let everyone successfully participate if each buyer specifies a desired purchase quantity at every possible valuation, and it specifies a smart-contract protocol that enforces this.

desk verdict Clever mechanism, but the central 'everyone participates' claim has a concrete counterexample involving permanent bids; still worth a serious look. read the letter →

arxiv 1908.04295 v1 pith:2G6W7W7H submitted 2019-08-12 econ.TH cs.CRcs.GT

Jason Teutsch , Vitalik Buterin , Christopher Brown This is my paper · ORCID
classification econ.THcs.CRcs.GT
keywords tokencrowdsalevaluationtableuniversalparticipationsmartcontractautomaticwithdrawalsmonotoneinvariantpersonalcapEthereum
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Token crowdsales that fix a price per token face a dilemma: a fixed valuation cannot simultaneously guarantee buyers a fixed fraction of the supply and guarantee that everyone gets in. This paper argues that the dilemma disappears once each buyer submits a valuation table—a desired purchase amount for each possible total sale valuation—instead of a single bid. The protocol it describes automatically refunds buyers whose personal valuation cap is exceeded, so the final sale valuation and everyone's purchases satisfy every submitted table. The contribution is a market-clearing mechanism for token sales: participation is universal by construction, and final quantities agree with contingent demand.

What carries the argument

The load-bearing object is the buyer's valuation table, a step function from total sale amount to contribution amount. The protocol operationalizes it through personal caps and a sorted linked list of cap buckets maintained by a valuation pointer. After the withdrawal lock, the smart contract runs a loop that finds the active bids with the smallest personal cap, refunds them in full or in part until the remaining active caps all exceed the current valuation, and thereby enforces the monotone valuation invariant. The linked-list bucket design keeps each operation verifiable in constant time, with outside parties paid to supply insertion advice, so the contract can run the loop within per-block gas limits.

What would settle it

In a test deployment, create a block in which new bids push the valuation past many personal-cap buckets at once and make the required refunds exceed the block's gas limit; if the valuation pointer falls behind and a fresh bid can enter with a personal cap equal to the stale valuation, the monotone invariant and the universal-participation guarantee fail.

Watch

Extended reading notes

Core claim

The central claim is that a token crowdsale can satisfy every buyer's valuation table, not merely the buyers who arrive first or bid highest. For each buyer, a valuation table maps the sale's total valuation to the amount that buyer wants to contribute; the final outcome counts as satisfying the table when the buyer's actual contribution equals the table value at the final valuation, or falls between the table's left and right limits at a discontinuity. The protocol achieves this by letting bids enter freely before a withdrawal lock, then—after the lock—repeatedly refunding the active bids with the smallest personal caps until every remaining cap exceeds the current valuation. The result is that the final valuation and purchase amounts satisfy every table, and the sale valuation only moves upward after the lock, which blocks whales from pushing the valuation down. Thus the protocol is a constructive bypass of the Proposition that fixed-valuation crowdsales cannot combine a guaranteed fraction with universal participation.

Load-bearing premise

The whole guarantee depends on each block being able to process every refund the contract needs to make in that block, and on outside helpers always telling the contract where the current valuation sits; if either fails, the contract may not enforce the invariant that protects buyers.

Editorial extensions

If this is right

  • A buyer who submits a complete valuation table is guaranteed that the final sale outcome matches her table, up to the standard tie convention, so universal participation becomes possible even though no fixed-valuation sale can offer it.
  • The impossibility Proposition is bypassed by making the valuation endogenous: the contract refunds low-cap bids until the remaining active caps exceed the current valuation, so each buyer's final quantity agrees with her contingent demand.
  • After the withdrawal lock, the sale valuation is monotonically increasing, so a whale cannot push the valuation down below earlier bidders' caps.
  • The linked-list bucket implementation makes each contract operation verifiable in constant time, with third parties paid to supply insertion advice, so the loop can in principle run within per-block gas limits.
  • The voluntary-withdrawal penalty derived from the inflation ramp makes the blackout attack unprofitable for a rational adversary whenever the penalty fraction exceeds the relative bonus gap.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An immediate corollary the paper leaves implicit is that the protocol is a market-clearing mechanism: the final valuation is the price at which each buyer's contingent demand is exactly met, so the sale replaces price-setting with automated contingent refunds.
  • If the gas-limit and pointer-advice assumptions hold, the same design could be applied outside token sales to any allocation problem where participants submit contingent demand schedules and an on-chain contract can execute refunds, such as capped multi-unit auctions.
  • A testable extension would measure, under realistic bid distributions, how granular the personal-cap buckets must be to keep the valuation pointer moving within one block's gas limit; the paper's 300,000-moves estimate is a ceiling, not a guarantee.
  • The guarantees concern satisfying pre-stated valuation tables, not price discovery; whether social interaction actually drives buyers to reveal true valuations remains an empirical question the paper does not settle.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper studies token crowdsales on Ethereum. It first states an impossibility: any fixed-valuation crowdsale that guarantees a fixed fraction of tokens for a given currency amount cannot guarantee universal participation. It then proposes an "interactive coin offering" in which each buyer submits a valuation table, i.e., a desired contribution amount as a step function of the total sale valuation. Before a withdrawal lock, buyers may voluntarily withdraw part of their bids, with a penalty and a permanently committed remainder; after the lock, the contract automatically withdraws active bids whose personal caps are exceeded, processing minimal-cap bids first and issuing partial refunds when the cap boundary is crossed. The paper claims that the final valuation and purchase amounts satisfy every buyer's valuation table, that the valuation is monotone increasing after the lock, that whale and blackout attacks are deterred, and that the required heap maintenance can be implemented on-chain via an incentivized sorted linked list of cap buckets. An epilogue describes a TrueBit implementation and later modifications.

Significance. If fully established, the protocol would be a notable market-clearing mechanism for token sales: it replaces fixed-price rationing with a valuation-table mechanism and offers an on-chain complexity workaround via incentivized pointer advice. The paper deserves credit for identifying a real problem and for a concrete, inventive protocol design, including the impossibility proposition of Section 1, the two-phase lock structure, and the bucket/pointer implementation sketch of Section 6. However, the headline guarantee is materially weakened by the fact that "satisfaction" at personal-cap values is defined as an interval condition rather than exact quantity matching, and, more importantly, by the exclusion of permanent bids from the satisfaction proof. The central theorem is therefore not established as written, and the paper would need a protocol-level revision to repair this. The security analysis of Section 5.3 is heuristic rather than a formal equilibrium argument. With a corrected treatment of permanent bids and explicit gas-limit assumptions, this could become a solid contribution.

major comments (3)
  1. [Section 4 (Steps 2 and 3) and Section 5.1] The proof of universal satisfaction omits permanent addresses. Step 2 of Section 4 turns a voluntarily withdrawn active address into "permanent" and leaves a positive balance b(A), while Step 3's automatic-withdrawal loop and Section 5.1's single-step table A(V) operate only on active addresses. For a permanent address with c(A)=50 and a positive remaining bid, the table A(V) defined in Section 5.1 gives A(V)=0 whenever V>50, but the Final Stage pays b(A)>0 regardless of V. Concretely, with flat pricing, a bid of v(A)=100 at a=0 with c(A)=50, voluntarily withdrawn at s=t/2, leaves b(A)=50 tokens; if the remaining active bids push V to 120, the buyer receives 50 tokens even though her valuation table demanded 0 at V=120. The "two cases" paragraph in Section 5.1 sums only over active addresses, so this is not a minor gap but a counterexample to the paper's central claim. The protocol must either subject permanent bids to their personal caps in Step 3 or explicitly restrict the satisfaction claim to active bids, in which case it no longer covers all buyers.
  2. [Section 4, Step 3.1] The minimum in Step 3.1 is computed over "active or permanent" addresses, but the loop then selects B_1,...,B_k among active addresses with that minimum. If the global minimum cap belongs only to permanent addresses, no active address attains the minimum, so S is undefined and Steps 3.2 and 3.3 cannot be executed. Example: a permanent address has cap 50, an active address has cap 100, and V=120. The loop condition is satisfied because the active cap 100 is exceeded, but Step 3.1 returns min=50 with k=0. This is a protocol specification bug independent of gas limits; either the minimum should be taken over active addresses only, or the protocol must define how permanent minima are processed.
  3. [Section 6, gas-limit paragraph] Section 6 explicitly admits that "insufficient gas could result in an incorrect valuation pointer at the next time step." The correctness of the Section 5 invariants depends on Step 3 executing all required automatic withdrawals in the block in which new bids arrive, and the 300,000 pointer moves per block is an estimate, not a proof that a block's automatic-withdrawal work is bounded. Please state the gas assumption as an explicit hypothesis of the Section 5 claims, or add a mechanism that allows the while loop to be spread over multiple blocks without breaking the monotone-valuation invariant. As written, the abstract's unconditional claim that "everyone can successfully participate" is stronger than what the implementation section establishes.
minor comments (4)
  1. [Section 5.2] The proof of the monotone valuation invariant contains a false sentence: "the valuation at the end of Step 3 is no less than the personal cap of every active address." When Step 3.2 fully removes the minimal-cap bucket, remaining active caps can be strictly larger than the end-of-step valuation. The intended invariant (end-of-step valuation is at least the minimum personal cap among active addresses at the beginning of Step 3) is repairable, but the proof should be rewritten.
  2. [Section 5.1, satisfaction definition] The satisfaction definition (a)-(b) is an interval condition at cap points: at a valuation equal to a personal cap, any purchase amount between the left and right limits counts as satisfying. The abstract and introduction should be qualified accordingly, since "satisfy every buyer's valuation table" does not mean exact quantity matching at those discontinuity points.
  3. [Section 4, Step 2 and Step 3] The paper does not specify how V is updated when an address becomes permanent in Step 2. The initialization formula defines V as a sum over active addresses only, yet permanent addresses still hold capital in the sale and receive tokens at the Final Stage. Please state explicitly whether and how permanent balances enter the valuation V, since this affects the interpretation of every invariant in Section 5.
  4. [Section 5.3] The blackout-attack analysis is heuristic. In particular, the relation between the claimed "withdrawal penalty ap/3" and the formula for b(A) in Step 2.2 should be spelled out, and the recursive rationality argument should be presented as a heuristic rather than a formal equilibrium result.

Circularity Check

1 steps flagged · score 6.0 of 10

The 'satisfies every buyer's valuation table' guarantee is largely built into the definition of satisfaction and the single-step table, making the headline participation claim partly circular; the monotone invariant and blackout analysis are independent content.

  1. self definitional [Section 5.1 'Personal cap invariant'; Section 4 Step 3 'Automatic withdrawals']
    "A(V ) = { v(A) if V < c(A); some value in [0, v(A)] if V = c(A); 0 if V > c(A). ... We say that a valuation V and purchase amount a satisfy a buyer's valuation table T if the following holds: (a) a = T (V ) if V is an interior point of some valuation table step; (b) otherwise a lies somewhere between the left and right limit points: lim_{x→V+} T(x) ≤ a ≤ lim_{x→V−} T(x)."

    The single-step table A(V) is defined to be exactly the protocol's own refund behavior in Step 3: full bid below cap, partial bid at cap, zero above cap. The 'satisfy' predicate then declares any amount in the cap interval to be satisfying. Section 5.1's proof only checks that each active address's final balance matches this definition, so the headline claim that the crowdsale 'satisfies every buyer's valuation table' is true by construction of the table and of the satisfaction predicate, not by an independent market-clearing argument. The loop termination and monotone valuation invariant are real content, but the cap-satisfaction part itself is definitionally baked in.

full rationale

The central participation result is partially circular. Section 5.1 defines a bid's 'single-step valuation table' as the protocol's automatic-withdrawal rule (full below cap, partial at cap, zero above cap) and defines 'satisfy' so that any amount in the cap interval qualifies. The proof then reads off final balances and compares them to this definition; no fixed-point or equilibrium theorem is needed for the cap part. This is a self-definitional reduction: the claimed guarantee is enforced by the refund rule and legitimized by the satisfaction predicate. The Section 5.2 monotone valuation invariant and Section 5.3 blackout-penalty arithmetic are genuinely independent and non-circular. The Section 1 impossibility Proposition is proved in-text and is not load-bearing for the construction. Separately, I flag a correctness gap, not a circularity: Section 5.1's proof sums only active addresses, while permanent addresses created by voluntary withdrawals also receive final tokens and are omitted from the satisfaction argument; this may falsify the universal-satisfaction claim, but it is not a circular-step finding.

Assumptions & free parameters 3 free parameters · 6 assumptions · 0 invented entities

All load-bearing premises are behavioral or implementation assumptions, not new physical entities. The protocol parameters (1/3 penalty, inflation schedule, time thresholds) are designer choices, and the underlying theory requires no new postulates beyond standard incentives and Ethereum execution assumptions.

free parameters (3)
  • withdrawal penalty coefficient = 1/3
    Section 4 Step 2.2 permanently commits one third of the bonus pricing on voluntary withdrawal. Section 5.3 argues this amount deters the blackout attack because the attacker's maximum gain is bounded by (a-b)/3; the value is a protocol design choice, not a measured constant.
  • inflation ramp bonus schedule = 20% to 10% to 0 (example)
    Section 2 gives example maximum bonus of 20%, declining to 10% at the withdrawal lock and 0 at the end. The security analysis in Section 5.3 treats the early bonus a and late bonus b as variables, so the exact numbers are illustrative, but a decreasing schedule is load-bearing for the attack analysis.
  • withdrawal lock time t and sale end time u = not specified
    Section 4 fixes time thresholds 0 <= t < u, with t the withdrawal lock. The protocol's phases depend on these thresholds, but the analysis does not require specific values.
assumptions (6)
  • domain assumption Each buyer's valuation table is monotonically decreasing: demand is inverse to supply (Section 3.1, property 1).
    The personal cap invariant and the convergence argument assume buyers purchase at least as many tokens at lower valuations as at higher ones. Section 7 partially relaxes this for personal minimums, but the core Section 4 protocol relies on it.
  • domain assumption Buyers prefer liquid markets and rely on social influences, and each buyer eventually converges to a final valuation table well before the sale ends (Section 3.1, properties 2 and 3).
    The interactive equilibrium story depends on buyers reacting to market signals and settling on final bids before the withdrawal lock.
  • domain assumption The adversary cannot sustain significant congestion or censorship for a long time and restricts actions to the Ethereum network (Section 3.2).
    If an adversary could censor bids for a large fraction of the crowdsale, the universal participation guarantee and monotone valuation invariant would not hold.
  • domain assumption The smart contract always processes bids correctly, and in the implementation the incentivized third parties supply correct insertion advice (Sections 3.2 and 6).
    The protocol analysis assumes correct execution; the implementation replaces in-contract heap with third-party advice, which requires an unproven incentive compatibility argument.
  • domain assumption Tokens created but not sold represent a fixed fraction of the total tokens generated, so valuation in native currency tracks fraction of total tokens (Section 4).
    The equivalence between total sale valuation and token fractions is needed for the fairness and participation statements.
  • domain assumption The inflation ramp is a positive-valued, linearly decreasing function p(s) (Section 4).
    The blackout attack penalty analysis in Section 5.3 uses the linearity of p(s) to compute bonuses at intermediate times.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Interactive coin offerings." pith.science (2026). https://pith.science/paper/2G6W7W7H

@misc{pith2026190804295,
  author       = {Pith},
  title        = {Pith review of: Interactive coin offerings},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2G6W7W7H}},
  note         = {Machine review of arXiv:1908.04295}
}
read the original abstract

Ethereum has emerged as a dynamic platform for exchanging cryptocurrency tokens. While token crowdsales cannot simultaneously guarantee buyers both certainty of valuation and certainty of participation, we show that if each token buyer specifies a desired purchase quantity at each valuation then everyone can successfully participate. Our implementation introduces smart contract techniques which recruit outside participants in order to circumvent computational complexity barriers.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    On several occasions, single crow dsales have consumed the network’s entire bandwidth for consecutive ho urs

    Most tokens originate on the Ethereum network, and, at times, the network has strug gled to keep up with purchase demands. On several occasions, single crow dsales have consumed the network’s entire bandwidth for consecutive ho urs. ∗ This version, updated in 2019, includes an Epilogue (Sectio n A). 1https://coinmarketcap.com/charts/ 1 Token distributions...

    work page 2019

  2. [2]

    buyers can withdraw their contributions after committing them to the sale (within certain limits), and

    work page

  3. [3]

    the protocol exploits sophisticated bookkeeping capabi lities of smart contracts. The corresponding crowdsale is interactive in the sense tha t potential buyers may enter and exit the crowdsale based on behaviors of other b uyers and in doing so tend the valuation towards a market equilibrium. The protocol also allows sufficient time for informal, social in...

    work page

  4. [4]

    Demand is inverse to supply. The total sale amount affects individuals’ inclinations to contribute, and in a liquid market, buyers w ill purchase at least as many tokens at lower valuations as they will at hig her ones. In Section 7, we shall relax the latter part of this assumption and modify the core procotol of Section 4 accordingly. We explicitly do no...

    work page

  5. [5]

    Buyers have intrinsic inertia against entering a new crowdsale

    Preference for liquid markets. Buyers have intrinsic inertia against entering a new crowdsale. Tokens held by few owners may be diffi cult to exchange and therefore have uncertain value. Given the ri sks of purchasing first, and barring other incentives, most buyers prefer to wait for others to purchase before they do. Waiting times may vary from buyer to bu...

    work page

  6. [6]

    Buyers depend on social influences to make purchase decisions

    Reliance on social influences. Buyers depend on social influences to make purchase decisions. Since the immediate value of new to kens depends largely on others’ beliefs, buyers necessarily int eract, either directly or indirectly, with other buyers. At the beginning of a crowd- sale, Buyers lack reliable information with which to valuat e the new token. So...

    work page

  7. [7]

    Complex procedures for purchasing tokens decreases participation

    Preference for simplicity. Complex procedures for purchasing tokens decreases participation. The tolerable threshold varies f rom buyer to buyer, and particular sets of rules or steps may encourage or discourage certain types of buyers

    work page

  8. [8]

    Buyers need not disambiguate their identities in or- der to participate in the crowdsale

    Pseudonymity. Buyers need not disambiguate their identities in or- der to participate in the crowdsale. In fact, we expect each b uyer to compose her valuation table with bids from multiple pseudon ymous addresses. 3.2 Adversaries We define an adversary to be any entity which performs network actions, in- cluding purchases and withdrawals, in order to decr...

    work page

Show all 28 references
  1. [9]

    Maximize useful market information available to buyers a t the time of purchase. 6

  2. [10]

    inactive

    Provide a fair distribution in line with the conclusion of Section 1. We explicitly do not optimize for maximal valuation. It rema ins an open problem to analyze the extent to which psychological and rat ional forces in the interactive coin offering model impact valuation relat...

  3. [11]

    inactive

    Any “inactive” address A may send to the crowdfund smart contract: – a positive quantity of native tokens v(A) along with – a positive-valued personal cap c(A) > 0. In case s ≥ t, i.e. when the withdrawal lock is in effect, we require the stricter inequality c(A) > V

  4. [12]

    active.” Step 2 : Voluntary withdrawals (execute this step iff s < t ). The following only applies prior to the withdrawal lock at ti me t. Any “active

    The smart contract then – sets the address balance b(A) = v(A) ·p(s), effectively implementing the inflation ramp (Section 2), and – sets A’s status to “active.” Step 2 : Voluntary withdrawals (execute this step iff s < t ). The following only applies prior to the withdrawal loc...

  5. [13]

    refunds v(A) ·(t − s)/t native tokens back to A,

  6. [14]

    sets b(A) = v(A) ·s/t · [ p(a) − p(a) − p(u) 3 ] , where a denotes the time at which address A originally made its bid,

  7. [15]

    permanent

    sets A’s status to “permanent.” The three steps above refund a fraction of A’s capital to the buyer and permanently commit a fraction of A’s capital to the sale while scratching a third of the “bonus” pricing. In Section 5.3, we shall argue that our chosen parameter of one thi...

  8. [16]

    , Bk be the (distinct) active addresses with mini- mal personal cap at the present moment, i.e

    Let B1, . . . , Bk be the (distinct) active addresses with mini- mal personal cap at the present moment, i.e. c(Bi) = min {c(A) : A is active or permanent } for all i ≤ k, and let S = k∑ i=1 v(Bi)

  9. [17]

    , Bk does not suffice to satisfy all personal caps from active addresses, i.e

    If removing the bids of B1, . . . , Bk does not suffice to satisfy all personal caps from active addresses, i.e. V − S ≥ c(B1), (4.1) then the crowdsale smart contract kicks out the entirety of these bids. In more detail, the smart contract: – refunds v(Bi) to Bi for all i ≤ k, ...

  10. [18]

    active” or “permanent

    Otherwise, the reverse inequality of ( 4.1) holds, and only some fraction of each of v(B1), . . . , v(Bk) comes out of the crowdsale. Let 0 < q < 1 be the minimum (positive) fraction of these quantities that must be removed in order to satisfy all remaining personal caps, i.e....

  11. [19]

    Our analysis relies on two, key, quantita- tive invariants which come into effect after the withdrawal lo ck (Section 2), namely that valuation is monotonically increasing over tim e, and that all personal caps remain above the current valuation in each blo ck. 5.1 Personal cap...

  12. [20]

    How does the buyer’s cumulative purchases from various ad dresses formally correspond to a valuations table? 10

  13. [21]

    pushout attacks

    What does it mean for a crowdsale to “satisfy” a valuation t able? Let V denote the final valuation of the crowdsale. Regarding item 1 ., note that the net purchase effect A of a bid from an address A is a single-step valuation table (modulo a single point): A(V ) =      v(...

  14. [22]

    crowdsale smart contracts always process bids correctly

    incentivizes buyers to enter the crowdsale early and form a liquid market. Moreov er, the be- ginning of the crowdsale offers a low-risk trial period in whic h buyers can voluntary withdraw their bids with little penalty. Finally , the crowdsale has a relatively simple user int...

  15. [23]

    the task itself runs within the per block gas limit (and ava ilable net- work bandwidth),

  16. [24]

    the smart contract has sufficient ether, or native currency, to pay for the task execution, and

  17. [25]

    the smart contract remains dormant between the blocks in w hich users interact with it. The ICO protocol’s main loop (Section 4) requires maintenance of a list of addresses with various personal caps, a way of finding the s et of addresses with minimal personal caps, and a mech...

    2017

  18. [26]

    x exceeds all personal minimums of bids in the target set, and

  19. [27]

    poke-out

    the sum of capital contributions from bids in the target se t exceeds x. While the target set here may include all active bids, a nontr ivial target set must include inactive bids as well. The two properties ab ove suffice to justify the activation of all (inactive) bids in the ...

    2017

  20. [28]

    Analyzing token sale models

    Vitalik Buterin. Analyzing token sale models. http://vitalik.ca/ general/2017/06/09/sales.html, June 2017. 21

    2017

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.