Skip to content

Jg/cip 0105 externally implemented governance locks - #2

Open
jonored wants to merge 36 commits into
mainfrom
jg/cip-0105-externally-implemented-governance-locks
Open

Jg/cip 0105 externally implemented governance locks#2
jonored wants to merge 36 commits into
mainfrom
jg/cip-0105-externally-implemented-governance-locks

Conversation

@jonored

@jonored jonored commented Jul 15, 2026

Copy link
Copy Markdown

More of a directional sketch than a proper PR: implementation of basic CIP-0105 governance locking and unlock to a vesting state on top of V2 allocations.

Not intended to cover most of the scenario; only for technical approach discussion.

Pull Request Checklist

Cluster Testing

  • If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
  • If an upgrade test is required, comment /upgrade_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
  • If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
  • If a logical synchronizer upgrade test is required (from canton-3.5), comment /lsu_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

  • Include any change that might be observable by our partners or affect their deployment in the release notes.
  • Specify fixed issues with Fixes #n, and mention issues worked on using #n
  • Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

  • Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

jonored and others added 30 commits July 14, 2026 11:15
…ed-governance-locks' into jg/cip-0105-externally-implemented-governance-locks
…evelopment cycles by allowing the LSP to work cross-package when working on code.
Fix some issues related to PR comments for VestingLock
)

No need for admin auth as you can schedule a LSU without it so it doesn't really make sense

[ci]

Signed-off-by: Nicu Reut <nicu.reut@digitalasset.com>
* Remove scan transactions endpoint

Already deprecated, we removed /activities already, metrics show
basically no usage (< 1 request per day) and next release is 0.7.0 so
perfect time for removing a deprecated endpoint.

[ci]

Signed-off-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>

* fix rate limits

[ci]

Signed-off-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>

---------

Signed-off-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>
Co-authored-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>
Signed-off-by: Julien Tinguely <julien.tinguely@digitalasset.com>
…ev cycles (canton-network#6523)

---------

Signed-off-by: Cale Gibbard <cale.gibbard@obsidian.systems>
---------

Signed-off-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>
Co-authored-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>
fixes canton-network#6553

[ci]

---------

Signed-off-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>
Co-authored-by: moritz.kiefer@digitalasset.com <moritz.kiefer@purelyfunctional.org>
Prior to v1.11.1, sbt had a memory leak (sbt/sbt#8142) in its `update` task that caused memory usage to grow linearly with the number of `update`s performed. This affects regular development as `update` is called as part of the `compile` task dependency graph.

After upgrading to a version that includes the fix (coursier/sbt-coursier#563, coursier/sbt-coursier#564), I've found development with sbt, especially with long-running sbt shell sessions, to be a more pleasant experience; there's less sluggishness and a lot fewer warnings that say "X seconds of the last 10 seconds were spent in garbage collection."

Signed-off-by: Matt Dziuban <mrdziuban@gmail.com>
* Specify set of valid response content types.

Fixes canton-network#6483.

This updates `HttpClient.createHttpFn` to consider a response invalid if its content type is not `application/json`, `application/octet-stream`, or `text/plain`. This results in `httpClientWithErrors` calling `getApiErrorFromResponse`, which produces an `HttpCommandException` and includes the raw response body in its error message.

These three content types are the only ones used across all the OpenAPI specs in the repo. `text-plain` is used by [`devNetOnboardValidatorPrepare`](https://github.com/canton-network/splice/blob/main/apps/sv/src/main/openapi/sv-internal.yaml#L506-L508), and `application/octet-stream` is used by [`bulkStorageDownload`](https://github.com/canton-network/splice/blob/main/apps/scan/src/main/openapi/scan-stream-server.yaml#L46-L50).

Signed-off-by: Matt Dziuban <mrdziuban@gmail.com>

* Ensure responses with `ContentTypes.NoContentType` are considered valid.

Signed-off-by: Matt Dziuban <mrdziuban@gmail.com>

* Run scalafmt.

Signed-off-by: Matt Dziuban <mrdziuban@gmail.com>

---------

Signed-off-by: Matt Dziuban <mrdziuban@gmail.com>
…ing up development cycles by allowing the LSP to work cross-package when working on code."

This reverts commit 15dfa70.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants