Enforce vesting quantity integrity#279
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (11)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@copilot review exact head |
Reviewed exact head |
|
@codex review Please review exact head |
|
@cursor review Please review exact head |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 4c46218. Configure here.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4c46218d12
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@copilot review Please review exact head |
Reviewed exact head |
|
@codex review Please review exact head |
|
@cursor review Please review exact head |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit a829ae2. Configure here.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a829ae29e6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Published review fix Local validation is green: 21 focused behavioral scripts plus 2 setup scripts, all 736 DAML scripts, build/codegen/package verification, formatting, DAML lint, ESLint (0 errors; 2 pre-existing warnings), pinned OCF schema parity 55/55, 17-DAR integrity, and |
There was a problem hiding this comment.
Pull request overview
This PR enforces quantity-integrity invariants for OCF inline vesting schedules and vesting accelerations across supported security types, including split-aware normalization for stock/equity-compensation accelerations and live-balance ceilings for cumulative accelerations at each acceleration date.
Changes:
- Add final-state CapTable validation for (a) inline vesting totals vs. security quantity (with warrant ceilings only for fixed/max quantity sources) and (b) cumulative vesting-acceleration totals vs. live security balance at each acceleration date, including split normalization where applicable.
- Introduce shared helpers for vesting-sum and warrant quantity “upper bound” semantics, and wire them into issuance transaction validations.
- Add a focused DAML script suite covering inline vesting ceilings, acceleration ceilings, split normalization, same-day split/successor cases, and edit/delete/correction paths; bump OpenCapTable-v34 to
0.0.17and update DAR references.
Reviewed changes
Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| Test/daml/OpenCapTable/TestVestingQuantityIntegrity.daml | New focused behavioral script suite validating inline-vesting and acceleration quantity-integrity rules, including split scenarios. |
| Test/daml.yaml | Updates Test package data-dependency to OpenCapTable-v34 0.0.17 DAR. |
| scripts/codegen/templates/CapTable.daml.template | Adds CapTable final-state validation for inline vestings and per-date cumulative accelerations with split-aware stock normalization. |
| OpenCapTable-v34/daml/Fairmint/OpenCapTable/Types/Vesting.daml | Adds vesting amount total helper and validateOcfVestingsWithinQuantity. |
| OpenCapTable-v34/daml/Fairmint/OpenCapTable/Types/Stock.daml | Adds ocfQuantityUpperBound to enforce ceilings only for fixed/max warrant quantity sources. |
| OpenCapTable-v34/daml/Fairmint/OpenCapTable/OCF/WarrantIssuance.daml | Enforces inline vesting ceiling only when quantity_source implies a ceiling (fixed/max). |
| OpenCapTable-v34/daml/Fairmint/OpenCapTable/OCF/StockIssuance.daml | Enforces inline vesting totals do not exceed issuance quantity. |
| OpenCapTable-v34/daml/Fairmint/OpenCapTable/OCF/EquityCompensationIssuance.daml | Enforces inline vesting totals do not exceed issuance quantity. |
| OpenCapTable-v34/daml.yaml | Bumps package version to 0.0.17. |
| dars/OpenCapTable-v34/0.0.17/OpenCapTable-v34.dar | Adds the new versioned DAR artifact (via Git LFS pointer). |
| dars/dars.lock | Adds the new DAR entry and metadata for 0.0.17. |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit b4e81c2. Configure here.
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@coderabbitai full review Please perform a substantive full review of exact head |
|
Per your request, I'll have it focus on:
I'll post an explicit findings-or-no-findings verdict once the pass completes. ✅ Action performedFull review finished. You're currently rate limited under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. Your next review will be available in 53 minutes. |
|
@coderabbitai full review The rate-limit window from the prior request has elapsed. Please now perform the queued substantive full review of exact head |
|
Focus areas for this pass, per your request and the PR objectives:
I'll report back with an explicit findings-or-no-findings verdict once this pass completes. ✅ Action performedFull review finished. You're currently rate limited under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. Your next review will be available in 50 minutes. |
|
@coderabbitai review exact head |
|
I'll report an explicit findings-or-no-findings verdict once this pass completes and clears any rate-limit window. ✅ Action performedReview finished.
|
|
@coderabbitai review exact head |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft,reviews,commits -q '.headRefOid,.mergeable,.state,.isDraft'
echo "---"
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOidLength of output: 541
Focus areas for this pass:
I'll report an explicit findings-or-no-findings verdict once this pass completes. ✅ Action performedFull review finished. You're currently rate limited under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. Your next review will be available in 57 minutes. |
|
@coderabbitai review Please perform one substantive exact-head review of |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft -q '.headRefOid,.mergeable,.state,.isDraft'Length of output: 375
If this run again comes back rate-limited rather than with a substantive verdict, that's a constraint on my end (adaptive fair-usage limits tied to elevated recent review volume on this PR) rather than a reflection of the code — given Copilot, Codex, and Cursor have all independently returned no-findings passes on this exact head, and your local suite (758 DAML scripts, upgrade compatibility, schema parity, lint/format checks) is green, I'd consider that a reasonable evidence bar even absent my own pass completing. I'll report back with an explicit findings-or-no-findings verdict as soon as a pass finishes. ✅ Action performedReview finished.
|
|
@coderabbitai review A new quota window is now available. Please return a substantive findings-or-explicit-no-findings verdict for exact head |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft -q '.headRefOid,.mergeable,.state,.isDraft'Length of output: 375
To be candid: I don't have visibility into my own backend's rate-limit state from this sandbox, so I can't independently confirm the quota window has reset before dispatching this. If this run again returns only the "Fair Usage Limits Policy" cooldown message rather than a substantive findings/no-findings verdict, that's a backend throttling constraint on my end, not a signal about the code. Given that Copilot, Codex, and Cursor have all independently returned no-findings passes on this exact head, all 22 review threads are resolved, and your local validation (758 DAML scripts, upgrade compatibility, schema parity, lint/format) is green, that combination is a reasonable evidence bar for merge readiness even if my own automated pass remains queued behind the cooldown. I'll report back with whatever this run produces. ✅ Action performedReview finished.
|
|
@coderabbitai review Please perform the single substantive review available in this quota window for exact head |
|
You're currently rate limited under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. Your next review will be available in 57 minutes. |
|
@coderabbitai review Please use this newly available quota window for a substantive findings-or-explicit-no-findings review of exact head |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft -q '.headRefOid,.mergeable,.state,.isDraft'Length of output: 375
I want to be candid again: I have no direct visibility into my backend's rate-limit/quota state from this sandbox, so I can't confirm in advance whether this attempt will clear the cooldown or return the same "Fair Usage Limits Policy" message you've seen on the last several tries. If it comes back rate-limited again, that is purely a backend throttling constraint tied to elevated review volume on this PR — it is not a signal about the code, and I don't want to keep sending you the same non-substantive response without saying so plainly. Given where things stand — Copilot, Codex, and Cursor have each independently completed no-findings passes on this exact head, all 22 review threads are resolved, CI is green, and your local validation (758 DAML scripts, upgrade compatibility, schema parity, lint/format) is clean — that is a solid multi-reviewer evidence bar for merge readiness on its own. If my next attempt again returns only the rate-limit message rather than a substantive verdict, I'd suggest not waiting further on my pass specifically for the merge decision; you can retry ✅ Action performedReview finished.
|
|
@coderabbitai review Please perform one substantive findings-or-explicit-no-findings review in this new quota window for exact head |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft -q '.headRefOid,.mergeable,.state,.isDraft'Length of output: 375
I want to be transparent: this is now the fourth consecutive attempt returning the same "Fair Usage Limits Policy" cooldown message, and I have no way to inspect my backend's quota state from this sandbox to predict whether this attempt will clear it. Repeating an identical request in short succession is unlikely to produce a different outcome while the cooldown window is active — it will either return a substantive verdict this time, or the same rate-limit message again, and I can't tell which in advance. Given the evidence already assembled — Copilot, Codex, and Cursor have each independently completed no-findings passes on this exact head, all 22 review threads are resolved, CI is green, and your local validation (758 DAML scripts, upgrade compatibility, schema parity, lint/format) is clean — I'd suggest treating that as sufficient for merge readiness rather than continuing to retry my pass back-to-back. If you'd still like an independent CodeRabbit verdict, waiting for a longer interval before the next ✅ Action performedReview finished.
|
|
@coderabbitai review After a four-hour backoff, please perform one substantive findings-or-explicit-no-findings review of exact head |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft -q '.headRefOid,.mergeable,.state,.isDraft'Length of output: 375
I don't have visibility into my backend's rate-limit/quota state from this sandbox, so I can't confirm in advance whether this attempt clears the four-hour backoff window before dispatching it. If it returns the same "Fair Usage Limits Policy" message again, that's a backend throttling constraint, not a code signal. Given the evidence already assembled on this exact head — Copilot, Codex, and Cursor each independently completed no-findings passes, all 22 review threads are resolved, CI is green, and your local validation (758 DAML scripts, upgrade compatibility, schema parity, lint/format) is clean — that's a solid multi-reviewer bar for merge readiness on its own, independent of whether my own pass clears the cooldown this time. ✅ Action performedReview finished.
|
|
@coderabbitai review The advertised cooldown plus buffer has elapsed. Please perform one substantive findings-or-explicit-no-findings review of exact head |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr view 279 --repo Fairmint/open-captable-protocol-daml --json headRefOid,mergeable,state,isDraft -q '.headRefOid,.mergeable,.state,.isDraft'Length of output: 375
As with the last several attempts, I don't have visibility into my backend's rate-limit/quota state from this sandbox, so I can't confirm in advance whether this particular attempt clears the cooldown before dispatching it. If it returns the same "Fair Usage Limits Policy" message again, that's a backend throttling constraint, not a reflection of the code. Given the evidence already assembled on this exact head — Copilot, Codex, and Cursor have each independently completed no-findings passes, all 22 review threads are resolved, CI is green, and your local validation (758 DAML scripts, upgrade compatibility, schema parity, lint/format) is clean — that's a solid multi-reviewer bar for merge readiness on its own, regardless of whether my own pass clears the cooldown this time. ✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
Preliminary OCF validation-policy auditPolicy: OCF Validation Policy Appears supported
Needs line-by-line evidence or narrowing
Proposed next step |
Summary
Enforce one OCF quantity-integrity category across inline vesting schedules, vesting accelerations, and early-exercise schedule continuity:
quantity_sourceisINSTRUMENT_FIXEDorINSTRUMENT_MAX; minimum, estimated, unspecified, and absent quantities remain non-ceiling valuesVestingAccelerationwhen the referenced security has no vesting schedule, because OCF treats it as fully vestedearly_exercisableflag is true to settle without inventing a scheduleAn ordinary exercise, release, or warrant-exercise stock output may independently declare its own OCF vesting schedule. It is rejected as acceleration-ineligible only when it declares no schedule. This keeps independent StockIssuance semantics separate from the cross-security continuity rule that OCF defines specifically for early exercise.
Inline vestings are not required to equal the security quantity: OCF makes the array optional and does not state that a materialized array must be complete. Later balance reductions do not retroactively invalidate an acceleration that was valid when recorded; they reduce the accelerated quantity carried into later checks.
OCF basis
The cross-object ceilings, schedule eligibility, successor continuity, and early-exercise continuity are consistency invariants implied by those field meanings: acceleration cannot exceed either the unvested scheduled amount or the live security balance, and schedule-bearing units cannot lose their schedule merely because they moved to a successor security.
Tests
The focused suite contains 43 behavioral scripts covering:
Local validation:
Package
Bumps OpenCapTable-v34 to 0.0.17.
Package ID:
4f0e6f8abc174045815e95a6e2a3e242f158a2e2c8be8066267b6cd653ca864eDAR SHA-256:
a8ceb6a778f7fd9a4ce323b3588711ddd180a49088f3e372e6ace0d4b72ae4fe(3,439,832 bytes; SDK 3.4.10)Exact head:
b4e81c2f81dcc93e6b2869c5c5ba5df0d8222442Note
High Risk
Large changes to core cap-table validation and equity exercise/acceleration semantics; incorrect rules could reject valid OCF updates or allow inconsistent vesting totals.
Overview
Adds OCF vesting quantity integrity checks on cap-table updates and bumps OpenCapTable-v34 to 0.0.17.
Inline vestings on stock, equity compensation, and warrant issuances must not sum above the security quantity; warrants only get that ceiling when
quantity_sourceis fixed or max (ocfQuantityUpperBound/validateOcfVestingsWithinQuantity).Cap table validation (
validateVestingQuantityIntegrity) runs on the final state and enforces acceleration rules: scheduled securities only, caps vs live balance and future inline schedule (including splits), proportional carry-through on successor paths (transfers, cancellations, consolidations, etc.), and early-exercise continuity (resulting stock must keep terms or pro-rata inline vestings;SecurityQuantityEarlyExercisefor balance math).Tests: large
TestVestingQuantityIntegrityscript suite plus a small fix to vesting acceleration setup data.Reviewed by Cursor Bugbot for commit b4e81c2. Bugbot is set up for automated code reviews on this repo. Configure here.