Create pirc_allocation_design2.js#2
Merged
Tsukimarf merged 3 commits intoTsukimarf-patch-1from Apr 17, 2026
Merged
Conversation
Reviewer's GuideAdds a self-contained JavaScript model and demo harness for PiRC Allocation Design Option 2, including a static data specification and a calculator class to compute pool parameters, swap pricing, participant-level allocations, and effective price curves for engagement-based LP swaps. Sequence diagram for runDemo allocation calculation flowsequenceDiagram
actor Developer
participant NodeProcess
participant PiRCAllocationCalculator
participant Console
participant PIRC_ALLOCATION_DB
Developer->>NodeProcess: execute script
NodeProcess->>NodeProcess: runDemo()
NodeProcess->>PiRCAllocationCalculator: new PiRCAllocationCalculator(1000000, 400000)
PiRCAllocationCalculator-->>NodeProcess: instance
NodeProcess->>PiRCAllocationCalculator: poolSummary()
PiRCAllocationCalculator-->>NodeProcess: summaryObject
NodeProcess->>Console: table(summaryObject)
NodeProcess->>PiRCAllocationCalculator: effectivePriceCurve(11)
PiRCAllocationCalculator-->>NodeProcess: curveData[]
NodeProcess->>Console: table(curveData[])
NodeProcess->>PiRCAllocationCalculator: participantSummary(1000, 0)
PiRCAllocationCalculator-->>NodeProcess: mostEngagedSummary
NodeProcess->>Console: table(mostEngagedSummary)
NodeProcess->>PiRCAllocationCalculator: participantSummary(1000, 200000)
PiRCAllocationCalculator-->>NodeProcess: leastEngagedSummary
NodeProcess->>Console: table(leastEngagedSummary)
NodeProcess->>PIRC_ALLOCATION_DB: access steps[0]
PIRC_ALLOCATION_DB-->>NodeProcess: firstStepConfig
NodeProcess->>Console: log(firstStepConfig)
Class diagram for PiRCAllocationCalculator and static allocation modelclassDiagram
class PIRC_ALLOCATION_DB {
<<object>>
document
notation
tokenSplit
piSplit
steps
effectivePriceData
}
class PiRCAllocationCalculator {
- number T
- number C
- number p_list
- number k
- number x0
- number y0
- number p_init
+ PiRCAllocationCalculator(number T, number C)
+ xAtS(number s) number
+ yAtS(number s) number
+ pSwap(number s) number
+ pSwapNorm(number s) number
+ pEff(number s) number
+ discountPercent(number s) number
+ participantSummary(number piCommitted, number s) object
+ effectivePriceCurve(number n) object[]
+ poolSummary() object
}
class RunDemoModule {
<<module>>
+ runDemo() void
}
RunDemoModule ..> PiRCAllocationCalculator : creates
RunDemoModule ..> PIRC_ALLOCATION_DB : reads
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 4 issues, and left some high level feedback:
- Consider removing or guarding the top-level
runDemo()call so that importing this module in other code (or tests) does not trigger console output and side effects by default. participantSummaryanddiscountPercentaccept anysvalue without bounds checking; adding validation (e.g.,0 <= s <= C/2) would prevent nonsensical or out-of-range usage.- The constructor only checks that
TandCare positive; adding type checks (e.g., ensuring they are finite numbers) would make the API more robust against invalid inputs.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider removing or guarding the top-level `runDemo()` call so that importing this module in other code (or tests) does not trigger console output and side effects by default.
- `participantSummary` and `discountPercent` accept any `s` value without bounds checking; adding validation (e.g., `0 <= s <= C/2`) would prevent nonsensical or out-of-range usage.
- The constructor only checks that `T` and `C` are positive; adding type checks (e.g., ensuring they are finite numbers) would make the API more robust against invalid inputs.
## Individual Comments
### Comment 1
<location path="PiRC1/4-allocation/pirc_allocation_design2.js" line_range="105-108" />
<code_context>
+ * @param {number} T - Total token launch allocation
+ * @param {number} C - Total Pi committed by all participants
+ */
+ constructor(T, C) {
+ if (T <= 0 || C <= 0) throw new Error("T and C must be positive numbers.");
+ this.T = T;
+ this.C = C;
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider validating that T and C are finite numbers, not just positive values.
Non-finite or non-numeric values (e.g. strings, `NaN`, `Infinity`) currently pass this check and can later produce `NaN` or infinite pricing/pool parameters. Using `Number.isFinite(T)` / `Number.isFinite(C)` (or explicitly coercing then validating) would fail fast and keep downstream calculations well-defined.
```suggestion
constructor(T, C) {
if (!Number.isFinite(T) || !Number.isFinite(C) || T <= 0 || C <= 0) {
throw new Error("T and C must be finite positive numbers.");
}
this.T = T;
this.C = C;
```
</issue_to_address>
### Comment 2
<location path="PiRC1/4-allocation/pirc_allocation_design2.js" line_range="155-156" />
<code_context>
+ * @param {number} s - Cumulative Pi swapped into LP at this participant's rank
+ * @returns {object}
+ */
+ participantSummary(piCommitted, s) {
+ const halfPi = piCommitted / 2;
+
+ // Bucket A: fixed-price tokens
</code_context>
<issue_to_address>
**issue:** Add guardrails for `piCommitted` and `s` to avoid invalid or out-of-range inputs.
If `piCommitted` is non‑positive or `s` falls outside the intended `[0, C/2]` range, this can yield invalid allocations (e.g., negative discounts or unbounded prices) without any error. Please validate `piCommitted > 0` and either clamp or reject `s` outside the supported range so downstream consumers can trust the summary values.
</issue_to_address>
### Comment 3
<location path="PiRC1/4-allocation/pirc_allocation_design2.js" line_range="184-198" />
<code_context>
+ const halfC = this.C / 2;
+ return Array.from({ length: n }, (_, i) => {
+ const s = (i / (n - 1)) * halfC;
+ return {
+ s,
+ sFraction: s / halfC,
+ pSwap: this.pSwap(s),
+ pSwapNorm: this.pSwapNorm(s),
+ pEff: this.pEff(s),
+ pEffNorm: this.pEff(s) / this.p_list,
+ discount: this.discountPercent(s),
</code_context>
<issue_to_address>
**suggestion:** Avoid recomputing `pEff(s)` to keep the curve output self-consistent and slightly more efficient.
In `effectivePriceCurve`, you call `this.pEff(s)` twice (for `pEff` and `pEffNorm`). Store it once in a local `const pEff = this.pEff(s);` and use that for both fields to avoid duplicate work and guarantee they always stay in sync if `pEff` changes later.
```suggestion
effectivePriceCurve(n = 11) {
const halfC = this.C / 2;
return Array.from({ length: n }, (_, i) => {
const s = (i / (n - 1)) * halfC;
const pEff = this.pEff(s);
return {
s,
sFraction: s / halfC,
pSwap: this.pSwap(s),
pSwapNorm: this.pSwapNorm(s),
pEff: pEff,
pEffNorm: pEff / this.p_list,
discount: this.discountPercent(s),
};
});
}
```
</issue_to_address>
### Comment 4
<location path="PiRC1/4-allocation/pirc_allocation_design2.js" line_range="242" />
<code_context>
+ console.log(JSON.stringify(PIRC_ALLOCATION_DB.steps[0], null, 2));
+}
+
+runDemo();
+
+// ─────────────────────────────────────────────
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid executing the demo automatically on import to prevent side effects in consumers.
Unconditional `runDemo()` causes console output and side effects whenever this module is imported, which is problematic for library consumers. Please gate this behind an entry-point check (e.g., `if (require.main === module)` in CommonJS or a separate CLI) so the demo only runs when executed directly.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 1 file
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="PiRC1/4-allocation/pirc_allocation_design2.js">
<violation number="1" location="PiRC1/4-allocation/pirc_allocation_design2.js:106">
P2: This guard does not reject `NaN`, `Infinity`, or non-numeric inputs. In JavaScript, `NaN <= 0` is `false`, so `NaN` silently passes through and contaminates every derived value (`p_list`, `k`, reserves, prices). Use `Number.isFinite()` to fail fast on non-finite inputs.</violation>
<violation number="2" location="PiRC1/4-allocation/pirc_allocation_design2.js:242">
P2: Avoid unconditional `runDemo()` execution on import; gate it so demo code only runs when this file is executed directly.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Add a new JavaScript module implementing the PiRC allocation period design option 2 with a static configuration and calculation engine for liquidity pool formation using deposits and swaps.
New Features:
Summary by cubic
Implements Allocation Design Option 2 as an executable model for LP formation using deposits and swaps. Adds a calculation engine and reference data for prices, discounts, and participant allocations.
PIRC_ALLOCATION_DBwith steps, token/Pi splits, LP fee, discount-to-lockup policy, and effective-price reference points.PiRCAllocationCalculatorfor listing price, AMM invariant, swap price and normalized price, effective price, and discount (with input validation).participantSummary,effectivePriceCurve, andpoolSummary(includes min/max effective prices and discounts).Written for commit 75d0287. Summary will update on new commits.