Splice 0.6.7
Action recommended for validator operators: upgrade to this release before the SVs start testing traffic-based app rewards in dry-run mode (see SV Longterm Operations Schedule for dates for the different networks)…
- A newer release in the 0.6 line: Splice 0.6.14
- Newest Splice: Splice 0.9.4
Open the release notes (opens in a new tab)docs.canton.network
-
Daml
-
Add
RewardCouponV2to represent rewards available from traffic-based app rewards that are computed by the SV apps off-ledger as described in CIP 104. They are created in an efficient batched fashion once per-round for every party that is eligible for traffic-based app rewards. In contrast to the existing reward coupons, these new coupons are using time based expiry, and can be minted by default up to 36h after their creation, thereby allowing their beneficiaries to batch the minting to save traffic costs. They can be minted like all other coupon types using one of the following methods:- Automated minting via the Splice Wallet backend that is part of the validator app, which works for onboarded internal parties and for external parties with a minting delegation.
- Direct minting by constructing calls to
AmuletRules_Transferthat uses them as an transfer input. These calls can be made directly against the Ledger API, or indirectly via custom Daml code deployed to the validator node.
-
Add a new interface package
splice-api-reward-assignment-v1. Apps whose ultimate beneficiaries are different from the app provider party (e.g., decentralized apps) can use this package to assign the rewards to their ultimate beneficiaries. -
Add a new field
rewardConfigto theAmuletConfigfor configuring whether rounds should use traffic-based app rewards or on-ledger reward accounting, and whether traffic-based app reward coupon creation should be simulated in a dry-run mode. See theRewardConfigdata type definition for the list of reward configuration fields and their semantics. -
Store the current
rewardConfigandtrafficPriceon everyOpenMiningRoundcontract when creating it. This information serves to synchronize the SV apps on the parameters to use for processing traffic-based app rewards. -
Add
CalculateRewardsV2andProcessRewardsV2templates together with supporting code to implement the creation of the new reward coupons based on the reward values computed off-ledger by the SV apps. -
Adjust the CC transfer implementation such that it stops creating featured app activity markers when it runs against a round (or external party configuration state) where traffic-based app rewards are enabled.
Due to the propagation delay of updating the external party configuration state in the
splice-amuletcode, there will be a transition phase where token standard CC transfers still create featured app markers. These will be automatically archived as soon as traffic-based app rewards are enabled. Thus no double-issuance of rewards will occur. -
The Daml changes require an upgrade to these versions:
-
Add
-
Validator app
-
TransferPreapprovalProposals are now only accepted for parties hosted on your node. To recover the prior behavior you can enablecanton.validator-apps.validator_backend.transfer-preapproval.accept-non-hosted-preapproval-proposals = true. Thanks to Rhaydden for reporting.
-
-
Deployment
-
Remove leftover code from Hard Synchronizer Migrations. In particular the
migrationflags are gone from SV and validator helm charts as well as the-Moption in docker compose. ThelegacyIdflag is also removed from the SV chart. -
Changed the default JVM args from
-Dscala.concurrent.context.numThreads=8 -XX:ActiveProcessorCount=8to-Dscala.concurrent.context.numThreads=12 -XX:ActiveProcessorCount=12for the participant, mediator, sequencer, sv app and scan app deployments. -
Changes to
splice-info:deploymentDetailsrequire specifyingsynchronizerSerialIdin addition to a frozenmigrationIddeploymentDetailshasactiverenamed tocurrentandstagingtosuccessorruntimeDetailsreqires specifyingsynchronizerSerialIdinstead ofmigrationIdscanUrlunderruntimeDetailsis now optional
-
Remove leftover code from Hard Synchronizer Migrations. In particular the
-
Observability
- The automation background services no longer affect the
/readyzendpoint of Splice apps and instead were replaced with asplice_automation_background_service_healthgauge that reports the health of each background service registered with an automation service. The gauge is0when the service is healthy and1when it is unhealthy, and is labeled withautomation_serviceandservice.
- The automation background services no longer affect the
-
Scan
-
The following deprecated endpoints have been removed from the public API:
/v0/rewards-collected/v0/round-party-totals/v0/round-totals/v0/aggregated-rounds/v0/round-of-latest-data
-
The following deprecated endpoints have been removed from the public API:
-
SV app
-
Amulet-based expiry triggers now skip batches whose preferred amulet package version is listed in the
ignored-amulet-versionsconfiguration and prior to the minimal supported version. Parties from skipped batches are added to an in-memory ignore list. This allows the sv app to better handle participants that have not yet vetted the latest amulet package and avoid repeated failures. - Unresponsive parties are now also skipped by the amulet-based expiry triggers and added to the in-memory ignore list.
-
Removed the
ignored-expired-rewards-party-idsandignored-expired-amulet-transfer-instruction-party-idsentries from the automation config. The existingignored-party-idsentry is now used as an additional ignore list for all amulet-based triggers.
-
Amulet-based expiry triggers now skip batches whose preferred amulet package version is listed in the