Update and rename 2026-09-BitDynamics-splice-tech-debt-dev-fund-propo…to 2026-09-RFP-06-BitDynamics-splice-tech-debt-dev-fund-proposal.md

Development Fund Proposal

Field	Details
Author	srikanth-bitdynamics
Organization	BitDynamics
RFP	RFP-6
Champion	Wayne Collier, Digital Asset
Total Funding Request	1,200,000 CC
Project Duration	6 months
Status	Approved
PR	#858
Created	2026-09-16
Approved	2026-10-07

---

Abstract

BitDynamics requests 1,200,000 CC for targeted improvements to Splice, with the scope developed in collaboration with the Splice maintainers.

Delivery is organized into two milestones, with contributions submitted upstream to canton-network/splice.

---

Specification

1. Objective

The work covers:

• Delayed Development Fund coupon payouts;
• CC burns and burns of unused CC minting allowances through SV governance;
• prevention of early dust expiry for locked CC backing Token Standard allocations and transfers;
• traffic-cost measurement and calibration;
• traffic purchase through token standard APIs;
• scalable Super Validator onboarding;
• removal of migration-ID requirements from Scan APIs and internal APIs, including documentation;
• running SVs without BFT sequencer connections.

2. Implementation Mechanics

Implementation Approach

Depending on the issue, the work may involve Daml, Scala services and automation, Token Standard integration, Scan APIs, frontend changes, and integration tests.

Larger changes will be split into smaller PRs where that makes review easier.

Scope

1. Delayed Development Fund Coupon Payout

Issue: #6722 — Delayed collection of DevFund coupons

Development Fund coupons should not become immediately mintable after allocation. A configurable delay gives SVs time to react if a coupon is unexpected or incorrect.

2. Support CC and CC Minting Allowance Burns

CC Burns

Issue: #6990 — Allow CC holders to burn CC using a TSv1 or TSv2 transfer

Provides a direct burn workflow and avoids workarounds that can unintentionally generate new rewards.

CC Minting Allowance Burns

Issue: #7254 — Support burn from unclaimed activity record pool via SV vote

Add an SV governance path for removing unused minting allowances when the CC is no longer intended to be minted.

3. Automatic Traffic Calibration

Canton protocol changes can alter serialized transaction size and therefore change traffic consumption even when the underlying operation has not changed.

DvP Settlement Traffic Measurement

Issue: #6991 — Make DvP settlement test fail on traffic cost changes

The DvP tests now track expected traffic consumption and detect material drift.

Preapproved CC Transfer Traffic Measurement

Issue: #6993 — Measure and monitor traffic cost of preapproved CC transfer

Adds traffic-cost measurement for a TSv2 preapproved CC transfer across participants.

4. Scalable SV Onboarding

Issue: #2872 — Make SV onboarding work with large ACS and topology sizes

Improve SV onboarding so it continues to work reliably as the Global Synchronizer and its state grow. Current onboarding endpoints return full ACS and sequencer topology snapshots, which become expensive at scale and fail under timeouts and non-incremental retries.

The exact implementation will follow maintainer guidance on this issue and may touch onboarding, state transfer, or the interaction between Splice and Canton.

5. Traffic Purchase Through Token Standard APIs

Issue: #7255 — Support traffic purchase through token standard v1 compat mode

Enable traffic purchase via Token Standard transfer APIs (v1 compatibility mode), so wallets and apps can buy member traffic through the same transfer path used for CC, rather than only through the dedicated BuyMemberTraffic flow.

6. Migration-ID Removal from Scan APIs and Internal APIs

Implementation issue: #598 — Make migration id optional in scan update and ACS APIs

Documentation issue: #5930 — cleanup the migration id from the docs

Make migration ID optional (or unnecessary) for Scan update and ACS APIs, and clean related documentation. Follow-on work for remaining internal APIs will be confirmed with Splice maintainers as needed.

7. Run SVs Without BFT Sequencer Connections

Issue: #6336 — Run SVs without BFT sequencer connections by default

Align SV defaults with production practice by running without BFT sequencer connections (and likely removing support for enabling them), so local and test setups match the incentive model used on the Global Synchronizer.

8. Prevent Early Dust Expiry of Locked CC

Issue: #7483 — Avoid early dust-expiry of locked amulet backing token standard allocations

Prevent small amounts of CC backing Token Standard allocations and transfers from expiring as dust before the coordinating contract expires. Update LockedAmulet_ExpireAmuletV2 so dust expiry is allowed only after lock.expiresAt when the dso party is included in lock.holders, and update ExpiredLockedAmuletTrigger to respect that condition.

Preserve the existing early dust-expiry safeguard for locks without the DSO as a lock holder, along with the existing Token Standard lifetime limits.

3. Architectural Alignment

Changes will be made directly against canton-network/splice and follow the existing Splice architecture and contribution process.

4. Backward Compatibility

Changes will preserve existing integrations and workflows where possible. The scope includes intentional behavior changes to coupon mintability, burn and traffic-purchase workflows, dust-expiry timing for locks with the DSO as a lock holder, migration-ID handling and SV sequencer-connection defaults. Any compatibility impact or required operator action will be reviewed with the Splice maintainers and documented alongside the relevant change.

---

Milestones and Deliverables

The proposed delivery windows include allowance for implementation, upstream review and MainNet release coordination. They are confirmed with the Splice maintainers before submission.

Milestone 1 — Tokenomics Safety & Traffic Calibration

Estimated Delivery: 2 months after grant approval
Focus: Tokenomics Safety & Traffic Calibration
Funding: 600,000 CC

Deliverables / Value Metrics

Scope

• Delayed Development Fund coupon payout — #6722
• Scalable SV onboarding — #2872
• Automatic traffic calibration — #6991 and #6993
• Traffic purchase through token standard APIs — #7255

Milestone 2 — Scalability & API Improvements

Estimated Delivery: 4 months after Milestone 1 completion (target: 6 months after grant approval)
Focus: Scalability & API Improvements
Funding: 600,000 CC

Deliverables / Value Metrics

Scope

• Support CC and CC minting allowance burns — #6990 and #7254
• Prevent early dust expiry of locked CC backing Token Standard allocations and transfers — #7483
• Migration-ID removal from Scan APIs and internal APIs, including adjusting documentation — #598 and #5930
• Run SVs without BFT sequencer connections — #6336

Deliverables: Implementation, tests and documentation for the agreed issues.

---

Acceptance Criteria

Each milestone is complete when its in-scope pull requests are reviewed and accepted by the Splice maintainers.

Scope Changes

Any pause for a material scope change must be mutually agreed and recorded by BitDynamics and the Splice maintainers, with Tech & Ops Committee agreement on changes to grant commitments. The agreement will identify the affected work and when the timeline pauses and resumes. Ordinary review iterations and corrections needed to meet the agreed scope remain included. New requirements or architectural rework beyond that scope will be agreed separately before the affected work resumes.

---

Funding

Total Funding Request: 1,200,000 CC

Payment Breakdown by Milestone

Milestone	Proposed delivery after grant approval	Funding
Milestone 1 — Tokenomics Safety & Traffic Calibration	2 months	600,000 CC
Milestone 2 — Scalability & API Improvements	6 months (4 months after Milestone 1 completion)	600,000 CC
Total	6 months	1,200,000 CC

Each milestone payment is due upon Voting Committee acceptance of the corresponding milestone against the acceptance criteria above.

Retroactive Funding

The request includes retroactive funding for contributions BitDynamics has already delivered and that have been merged upstream: Development Fund coupon controls (#6722, PRs #6793 and #6944); DvP traffic-cost monitoring (#6991, PR #7268); and preapproved CC transfer traffic-cost monitoring (#6993, PR #7286).

These contributions are included within Milestone 1’s 600,000 CC allocation. The total request covers both this completed work and the remaining agreed scope.

The grant is denominated in CC. The funding covers implementation, testing, review iterations, documentation and coordination for the agreed scope, including the delivered contributions identified above.

Volatility Stipulation

The grant is denominated in fixed Canton Coin. Should Committee-requested scope changes extend the project beyond 6 months after grant approval, any remaining milestone funding must be renegotiated to account for significant USD/CC price volatility.

---

Co-Marketing

BitDynamics will coordinate release communications with the Splice maintainers where useful, using the accepted upstream pull requests, accompanying documentation and Splice release notes to explain the delivered improvements.

---

Motivation

The work improves shared Splice functionality used by SV operators, validators, wallets and applications. Coupon controls and burn workflows address tokenomics safety, traffic-cost measurement helps detect consumption changes, and Token Standard traffic purchases give wallets and applications a familiar integration path.

Scalable SV onboarding and simpler Scan APIs address operational and integration friction as the Global Synchronizer grows. Delivering these changes upstream makes the improvements available through Splice's existing release and maintenance processes rather than through separate tooling.

---

Rationale

Delivery

BitDynamics will submit contributions through the normal Splice pull-request process, including the tests and documentation required for each issue.

Before publication, BitDynamics will confirm the complete issue list and its technical implications with the Splice maintainers. The confirmed issues will define the delivery scope and acceptance expectations.

Material additions or changes to the agreed scope will be discussed with the maintainers and agreed separately.

---

Team

BitDynamics will own implementation and delivery.

Maintenance

Contributions will become part of Splice’s normal release, CI, upgrade and maintenance processes. BitDynamics intends to remain an active upstream contributor and will collaborate with the maintainers to address defects or omissions identified in its delivered changes, including after merge.