[FREEZE-EXCEPTION] docs(ECO-005): disambiguate healthy/N=12 vs Veterano/N=24 solvency figures#440
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Internal review caught a narrative inconsistency in the ECO-005 bullet: the sentence mixed two pools. "+$2.756" is the `healthy` preset (Comprovado, N=12), but the bullet's context is the pitch's "+$4.152" claim, which derived from the `tripleVeteranDefault` scenario (Veterano, N=24). Quoting the N=12 figure next to a N=24 discussion lets a reader (or judge) flag an internal inconsistency in our own audit doc. Fix: label every figure by preset explicitly and note that the $4.152 claim was the Veterano/N=24 scenario, distinct from the +$2.756 healthy/N=12 figure. The conclusion (solvency is yield-backed, not by construction) is unchanged. Note: the reviewer suggested also stating the Veterano/N=24 healthy analogue as "+$3.205". That figure is NOT inserted here — it does not appear anywhere in the repo and could not be reproduced from the sandbox (no built SDK + would be this session's execution, not the reviewer's). Rather than bake an unverified number into a security doc, this edit only disambiguates the figures already present and verified in-repo. If the team wants the +$3.205 datapoint, it should land via a runSimulation run whose output is captured in-repo first. https://claude.ai/code/session_01YapZy1Z5gzbV5EammBkSQm
alrimarleskovar
force-pushed
the
claude/fix-eco005-doc-pool-disambiguation
branch
from
83ab599 to
7634d50
Compare
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
2 participants
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.
[FREEZE-EXCEPTION rationale: documentation-only, single-line clarity fix in the internal cryptoeconomic audit findings. No code, no behavior change. Removes a self-inconsistency a judge could flag.]
What
Internal review of the ECO-005 re-audit caught a narrative inconsistency in
docs/security/internal-audit-findings.mdline 107: the bullet mixed two distinct pools in one sentence.+$2.756is thehealthypreset (Comprovado, N=12) at 6.5% APY — verified in-repo.+$4.152claim, which derived from thetripleVeteranDefaultscenario (Veterano, N=24).Quoting the N=12 figure next to an N=24 discussion lets a reader (or hackathon judge) flag an apparent internal inconsistency in our own audit doc. The fix labels every figure by preset and notes the $4.152 claim was the Veterano/N=24 scenario.
What this PR deliberately does NOT do
The reviewer suggested also stating the Veterano/N=24 healthy analogue as
+$3.205. That figure is not inserted here — it appears nowhere in the repo and could not be reproduced from the sandbox (no built SDK; and even if run, it'd be this session's execution, not an independently-captured datapoint). Baking an unverified number into a security doc is exactly what an audit doc shouldn't do. This edit only disambiguates the figures already present and verified in-repo.If the team wants the
+$3.205datapoint recorded, it should land via arunSimulationrun whose output is captured in-repo first (e.g. a fixture or a logged test), then cited.The other two reviewer points — verified, no action needed
Logged here for the record (both checked against
mainHEAD):reserveLpInFloatinvariance test (ECO-007) — does it force LP > 0? ✅ Yes.tests/economic_parity.spec.ts:723setskaminoApy: 500explicitly "so the GF fills and the LP slice is non-zero", and line 730 assertslpDistribution > 0before checking the flag invariance. The CI guard is not trivial — it exercises the LP>0 case the reviewer's manual sweep (which only hit LP=0 with the GF cap absorbing yield) didn't reach.ECO-001 reachability guard — is it in
parity.spec.tsand in the js lane? ✅ Yes.tests/parity.spec.ts:342-383(describe("ECO-001 reachability — netSolvency must not leak into programs/")), andci.yml:96runspnpm test:parityin the js lane. The reviewer's grep missed it (they only foundeconomic_parity.spec.ts), but the guard is present and running.Test plan
Documentation-only change to a single markdown line. No code paths touched;
tsc/tests unaffected.https://claude.ai/code/session_01YapZy1Z5gzbV5EammBkSQm
Generated by Claude Code