Merge branch 'main' into Adding-a-logoURL-field-to-the-token-metadata-API

Signed-off-by: Amanda L Martin <[email protected]>

Author: hythloda

README.md

@@ -55,7 +55,7 @@ Global Synchronizer CIPs
 | [cip-0057](/cip-0057/cip-0057.md) |  | Add Quantstamp as a Weight 1 Super Validator | Eric Saraniecki | Governance  | Final |
 | [cip-0058](/cip-0058/cip-0058.md) |  | Add IntellectEU as Weight 1 SV |Christopher Kelly | Governance  | Final |
 | [cip-0059](/cip-0059/cip-0059.md) |  | Add Woodside AI as an SV of Weight 10 | Eric Saraniecki | Governance  | Final |
-| [cip-0060](/cip-0060/cip-0060.md) |  | Add Zero Hash as SV of Weight 7.5 | Eric Saraniecki | Governance  | Final |
+| [cip-0060](/cip-0060/cip-0060.md) |  | Add Zero Hash as SV of Weight 7.5 | Eric Saraniecki | Governance  | Approved |
 | [cip-0061](/cip-0061/cip-0061.md) |  | Add Chainlink as a Super Validator of Weight 7.5 | Thodoris Karakostas | Governance  | Final |
 | [cip-0062](/cip-0062/cip-0062.md) |  | Synchronizer Migration with Downtime to Splice 0.4.0 / Canton 3.3| Curtis Hrischuk| Standards | Final |
 | [cip-0063](/cip-0063/cip-0063.md) |  | Add Kaiko as a Super Validator of Weight 6.5 | Ambre Soubiran | Governance  | Final |
@@ -82,7 +82,15 @@ Global Synchronizer CIPs
 | [cip-0084](/cip-0084/cip-0084.md) |  | Tokenomics Committee to Recommend $/MB Price Tuning| Eric Saraniecki | Tokenomics | Approved |
 | [cip-0085](/cip-0085/cip-0085.md) |  | Add Talos as Weight 6.5 SV |Anton Katz| Governance | Approved |
 | [cip-0086](/cip-0086/cip-0086.md) |  |ERC-20 Middleware and Distributed Indexer for Canton Network |Eric Saraniecki | Tokenomics | Approved |
+| [cip-0087](/cip-0087/cip-0087.md) |  | Add Hex Trust as a Super Validator (Weight 3) | Giorgia Pellizzari, Alessio Quaglini | Governance | Approved |
 | [cip-0089](/cip-0089/cip-0089.md) |  |Synchronizer Migration with Downtime to Splice 0.5.0 / Canton 3.4|Curtis Hrischuk| Tokenomics | Approved |
+| [cip-0090](/cip-0090/cip-0090.md) |  |Onboard USDT0 to Canton — Outcome-Linked SV Weight (Max 10) |Eric Saraniecki | Governance | Approved |
 | [cip-0091](/cip-0091/cip-0091.md) |  |Add Zenith as an SV of Weight 10|Norbert Vadas, Teemu Paivinen, Heslin Kim, Henri Kamarainen| Governance | Approved |
 | [cip-0092](/cip-0092/cip-0092.md) |  |Controlled Transition to Dynamic Market Feeds Post-Listing of Canton Coin (CC)|Eric Saraniecki| Governance | Approved |
-
+| [cip-0093](/cip-0093/cip-0093.md) |  | Add Bosphorus SV (BSV) as a Super Validator (Max Weight 6) | Eric Saraniecki | Governance | Approved |
+| [cip-0094](/cip-0094/cip-0094.md) |  | Add Blockdaemon as a Super Validator (weight 5.0) | Brad Turner, Demo Skalkotos, Jesse Farese | Governance | Approved |
+| [cip-0095](/cip-0095/cip-0095.md) |  | Onboard Mesh to Canton — Outcome-Linked SV Weight (Max 10) | Jacob McCrum  | Governance | Approved |
+| [cip-0096](/cip-0096/cip-0096.md) |  | Removing Liveness Rewards from Validator Rewards Pool | Chris Zuehlke, Andrew Bryan | Tokenomics | Approved |
+| [cip-0097](/cip-0097/cip-0097.md) |  | Nasdaq Super Validator Participation | Eric Saraniecki | Governance | Approved |
+| [cip-0098](/cip-0098/cip-0098.md) |  | Cap Per-Transaction Application Rewards at $1.50 | Eric Saraniecki | Tokenomics | Approved |
+| [cip-0099](/cip-0099/cip-0099.md) |  | Zero Hash Modifications to Adoption Incentive  | Eric Saraniecki | Governance | Approved |

cip-0056/cip-0056.md

@@ -186,17 +186,14 @@ Likewise, DVP allocations of CC are created within a single Daml transaction ins
 No preapproval by the receiver is required, as that authorization is expected to
 be funneled through the apps' settlement worklows.
 
-CC is standards compliant except for the following two limitations:
+As of Splice version 0.4.23,
+CC is standards compliant except for the following limitation:
 
-- *short submission delay*: the CC implementation only supports a 1 minute
+- *short submission delay*: the CC implementation only supports a 10 minute
   delay between preparing a transaction and submitting it to the network.
   This is in contrast to the 24h delay targeted by the standard.
-- *no holding fees in portfolio view*: the amounts of CC holdings always show
-  the amount as of the round that they were created in. Wallets cannot
-  use the standardized APIs to display holding fees for CC holdings, but they
-  can read the `Amulet` contracts themselves if they desire to show holding fees.
 
-Both of these limitations are expected to be removed in the future, as
+This limitation is expected to be removed in the future, as
 explained in [Canton Coin Limitations](#canton-coin-limitations).
 
 
@@ -512,46 +509,20 @@ total supply correctly.
 #### Canton Coin Limitations
 
 As explained in [Canton Coin Implementation](#canton-coin-implementation),
-the CC implementation of this CIP will come with two limitations:
-a shorter submission delay and no generic support for wallets
-to display holding fees.
-
-There are two reasons for the shorter submission delay:
-
-1. The `AmuletRules_Transfer` choice calls `getTime` to check that the
-   round is open for recording transfers. These calls require the prepared
-   transaction to pin the ledger time (see [Canton Time
-   Model Docs](https://docs.daml.com/concepts/time.html)), which in turn limits the
-   maximal record time up to which the transaction can be sequenced on the
-   Global Synchronizer. The maximal skew between ledger time and record time
-   allowed on the Global Synchronizer is 1 minute.
-2. The `OpenMiningRound` contracts referenced in the `AmuletRules_Transfer`
-   choice have a maximal life-time of 20 minutes, as that is the duration
-   for which a round stays open for recording activity before it moves into
-   the issuing phase. Thus any transaction referencing them becomes stale after
-   20 minutes, as it refers to an archived contract (i.e., a spent UTXO).
-
-The solution to both of these limitations is to restructure the activity recording
-and CC issuance such that no round contracts are required at all. This can
-be done by summarizing activity records for 10 minute intervals of ledger effective time
-that are far enough in the past so that no new activity records can be created
-within that interval.
-
-Getting rid of round contracts also requires moving away from the round-based
-holding fees that are currently charged. We expect to replace holding fees with
-a time-based expiry of coin contracts that depends on their amount: for example at
-an expiry rate of $1 per year, a coin contract worth $100 could be archived
-by any SV after 100 years. This solves for the problem of SVs not having to
-store dust-coins forever without the complication of time-dependent holding balances.
-
-The CIP accepts the current CC limitations, as these two changes are non-trivial
-pieces of work that we we didn't want to put on the critical path of
-establishing a Canton Network token standard.
-
-Furthermore, existing wallets already do have direct integrations with
-[CC-specific FOP
-workflows](https://docs.dev.sync.global/app_dev/validator_api/index.html#external-custody-api)
-that allow for a 24h submission delay.
+the CC implementation comes with limitations.
+As of Splice version 0.4.23, the CC implementation of this CIP has
+the limitation of only supporting a 10' submission delay.
+
+The reason for this limitation is that currently
+an `OpenMiningRound` contract must be referenced in the `AmuletRules_Transfer`
+choice; and these contracts are only guaranteed to be available
+for 10 minutes.
+
+The solution for this limitation is to restructure the activity recording
+such that no round contracts are required at all.
+Compared to the time of writing of this CIP,
+removing the limitation has become simpler thanks to
+CIP-0078 "Canton Coin Fee Removal" and CIP-0047 "Featured App Activity Markers".
 
 
 #### No Authentication on Registry Off-Ledger APIs
@@ -588,15 +559,14 @@ implementations to their templates as part of a smart-contract upgrade.
 Analogously to how the Amulet implementation was changed to support the APIs.
 
 
-## Implementation proposal
-
-A proposal for the implementation of the Daml interfaces and the OpenAPI specifications
-can be found in the `token-standard/` directory in the `splice` repository on
-the [`canton-3.3` branch](https://github.com/hyperledger-labs/splice/tree/canton-3.3/token-standard#readme).
-The same branch also contains the `Amulet` implementation of the token standard
-APIs and a Daml script test harness for apps building on the token standard and
-for registries implementing the standard.
+## Implementation
 
+The implementation of the Daml interfaces and the OpenAPI specifications
+can be found in the `token-standard/` directory in the
+https://github.com/hyperledger-labs/splice repository. Documentation is
+[part of the Splice docs](https://docs.dev.sync.global/app_dev/token_standard/index.html).
+All of the token standard Daml APIs are implemented by `Amulet` and Scan
+serves the OpenAPI endpoints for them.
 
 
 ## Copyright
@@ -608,4 +578,7 @@ This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https:/
 
 * **2025-03-18:** - Initial Draft
 * **2025-03-31:** Approval announced via [mailing list thread](https://lists.sync.global/g/cip-announce/topic/cip_0056_canton_network/112004244)
-* **2025-11-25:** - Addition of the Logo URL optional field in the off-ledger token metadata API ([draft PR](https://github.com/hyperledger-labs/splice/pull/3210))
+* **2025-11-25:** - Addition of the Logo URL optional field in the off-ledger token metadata API ([draft PR](https://github.com/hyperledger-labs/splice/pull/3210))
+* **2025-12-01:** Replaced implementation proposal section with references to the actual implementation
+  that was released as part of [Splice 0.4.0](https://docs.dev.sync.global/release_notes.html#id-0-4-0).
+* **2025-12-03:** Updated Canton Coin limitations to reflect the state as of Splice 0.4.23.

cip-0060/cip-0060.md

@@ -4,7 +4,7 @@
   CIP: CIP 0060
   Title:  Add Zero Hash as SV of Weight 7.5
   Author: Eric W Saraniecki 
-  Status: Final 
+  Status: Approved 
   Type: Governance 
   Created: 2025-04-23
   Approved: 2025-05-13

cip-0073/cip-0073.md

@@ -5,11 +5,13 @@
 * Layer: Daml
   Title: Weighted Validator Liveness Rewards for SV-Chosen Parties
   Author: Moritz Kiefer
-  Status: Approved
+  Status: Replaced
   Type: Tokenomics
   Created: 2025-07-23
   Approved: 2025-08-27
   License: CC0-1.0
+  Post-History: https://lists.sync.global/g/cip-discuss/topic/cip_0073_weighted_validator/114411475
+  Superseded-By: CIP 0096
 </pre>
 
 ## Abstract
@@ -22,9 +24,9 @@ This allows hosting multiple parties on a single validator while still providing
 rewards to the parties on the same node as if they were running their
 own node. It also allows weighting certain some parties higher, e.g.,
 because they have been shown to contribute significantly to the
-success of the network, or have committed to do so. 
+success of the network, or have committed to do so.
 
-This CIP also enables external parties to sign a contract authorizing any party to automatically submit a minting transaction on behalf of the external party. 
+This CIP also enables external parties to sign a contract authorizing any party to automatically submit a minting transaction on behalf of the external party.
 
 
 ## Specification
@@ -130,6 +132,7 @@ Note: other licenses are avilable see recommendations in [cip-0000](../../cips/c
 
 * **2025-08-19:** Initial draft of the proposal sent to cip-discuss
 * **2025-08-27:** Approved CIP.
+* **2026-01-05:** Add post history and mark this CIP is superseded by CIP-0096.
 
 
 The reference implementation of the Daml changes is available in two draft PRs.

cip-0087/cip-0087.md

@@ -0,0 +1,109 @@
+## CIP 0087
+
+
+<pre>
+  CIP: 0087
+  Title: Add Hex Trust as a Super Validator (Weight 3)
+  Author: Giorgia Pellizzari, Alessio Quaglini
+  Status: Approved
+  Type: Governance
+  Created: 2025-09-26
+  Approved: 2025-11-14
+  License: CC0-1.0: Creative Commons CC0 1.0 Universal
+</pre>
+
+---
+
+## Abstract
+
+Add Hex Trust as an SV of Weight 3.
+
+Hex Trust commits to:
+-   Bring a comprehensive financial ecosystem to the Canton Network through the integration of regulated custody, on/off-ramp, payments, and yield products for stablecoins.  
+- Support development of Canton by providing practical feedback and suggestions on documentation, requirements, and use cases.
+
+---
+
+## About Applicant
+
+Hex Trust is a fully licensed and regulated digital asset financial institution, providing an end-to-end suite of services to hold, trade, issue, and transfer digital assets. Its offerings encompass Custody, Markets services, OTC trading, Escrow and Collateral Management, Staking, Investment solutions, and Asset Issuance — all designed to deliver seamless access, robust protection, and operational excellence for institutional and professional clients.
+
+Founded in 2018 in Hong Kong, Hex Trust has rapidly emerged as a global leader in digital asset custody and financial services, standing at the forefront of innovation in the blockchain and Web3 ecosystem. Built on a foundation of uncompromising security, regulatory compliance, and institutional-grade infrastructure, Hex Trust empowers the world’s most sophisticated investors, builders, and service providers to unlock the full potential of digital assets.
+
+Distinguished by its in-house technology platform and a team of seasoned financial and blockchain experts, Hex Trust combines deep industry expertise with cutting-edge security protocols to safeguard and grow the digital asset portfolios of its clients. Trusted by over 350 institutional clients, the company continues to set new standards for operational resilience and institutional adoption of digital assets.
+
+With a global presence spanning Singapore, Hong Kong, Dubai, Italy, and Vietnam, Hex Trust serves a diverse and expanding client base across Asia, Europe, the Middle East, and the Americas. Its mission is clear: to be the most trusted partner for institutions navigating the future of finance in the digital age.
+
+## Specification
+
+### Deliverables for Full SV Reward
+
+| Deliverable | Acceptance Criteria | Deadline | Weight Earned |
+|--------------|--------------------|-----------|----------------|
+| **Hex Trust integration of Canton Coin and Canton Token Standard** | Hex Trust customers can safekeep CC and any asset on the Canton Network that adheres to the Canton Token Standard | +180 days from CIP Approval | 1 |
+| **Adoption Bonus** | All CC burn attributable to Hex Trust–facilitated inelastic burn on the Network | +180 days from Integration Go Live | +0.5 per $2M of inelastic burn generated on the network (Max +2) |
+
+### SV Reward Mechanics
+
+- An extraBeneficiary PartyID associated with the ‘escrowed’ Super Validator will be setup by the Foundation, or another SV node operator approved to provide SV rewards escrow services, with an SV Weight at the maximum earnable weight.
+
+- The Applicant is responsible for coordinating the process of setting up the escrowed weights with the GSF and the operator of the SV node.
+- The Applicant is responsible for all costs associated with the operation of the escrow SV
+- The escrow SV will NOT mint rewards on a block by block basis
+- All escrow SV rewards will go to the Unclaimed Rewards pool
+- ⅔ of the Super Validator Operators will update their configurations to allow the escrowing SV node to host the full weight to be earned by the given Super Validator
+
+- Applicant is required to present proof of successful completed milestones to the Tokenomics Working Group
+
+- Applicant is required to present a calculation for number of Canton Coin it should earn for meeting the requirements of the milestone
+- If the Tokenomics Working Group agrees the milestone has been met and agrees with the calculation, an announcement will be sent via the Tokenomics-Announce mailing List
+
+- The GSF will update the extraBeneficiary to an active PartyID controlled by that Super Validator.
+- ⅔ of Super Validator Operators will then assign a portion of the Unclaimed Rewards to be minted by the Applicant’s Validator, based on the calculation approved by the Tokenomics working group.
+- If any milestones and associated rewards are not achieved by the deadline
+  - Applicant will be notified they have not met a deliverable by the GSF
+  - Remaining SV Weight assigned to the extraBeneficiary SV will be removed from the GSF node configuration, and the total SV weight of the GSF SV node will be reduced by the same amount by a vote of the Super Validators.
+  - The Tokenomics Working Group will make a recommendation to the SVs on what to do with the Unclaimed Rewards
+
+- Applicant is subject to CIP-0045 : SV Operating Requirements
+
+- If, at any time, the Applicant has been rewarded SV Weight > 2.5, they are required to operate their SV within 6 months of crossing that Weight. This SV node will join the network with an SV weight of zero (0) and may add weights as the SV completes the milestones listed in this CIP.
+
+Applicant is subject to **CIP-0045: SV Operating Requirements**.  
+If the applicant’s SV Weight > 2.5, they must operate their SV within six months. This SV node will join the network with weight zero and may add weights as milestones are completed.
+
+
+## Copyright
+
+This CIP is licensed under **CC0-1.0: Creative Commons CC0 1.0 Universal**.
+
+
+## Changelog
+
+- **2025-09-26**: Initial draft of the proposal.
+- **2025-11-12**: New draft of the CIP.
+- **2025-11-14**: CIP Approved.
+
+
+## Appendices
+
+### Appendix I — Motivation
+
+The Canton Network’s long-term success depends on its ability to bridge institutional finance with decentralized infrastructure in a secure, compliant, and scalable manner. As adoption accelerates, institutional participants require partners that can provide regulated financial services and integrated digital asset infrastructure across jurisdictions.
+
+Hex Trust — as a regulated financial institution across Asia, the Middle East, and Europe — brings this capability to Canton through its established licensing framework and robust infrastructure spanning custody, brokerage, asset management, and payments.
+
+Hex Trust’s mission aligns with Canton’s core principles: to create an institutional-grade and interoperable financial network that can power real-world use cases and regulated asset activity at scale.
+
+**Global Regulatory Posture and Institutional Coverage**
+
+Hex Trust operates under a multi-jurisdictional regulatory framework, including licenses and authorizations across key financial hubs in Hong Kong, Singapore, Dubai, and Europe. Through these entities, Hex Trust provides:
+
+* Regulated Custody Services for digital and tokenized assets under financial authority supervision  
+* Staking  
+* Escrow  
+* Wrapping services  
+* Broker-Dealer and Asset Management Services, enabling compliant market participation and tokenized investment products  
+* Major Payment Institution capabilities, bridging fiat and digital economies through regulated on/off-ramps and settlement rails  
+
+This regulatory breadth ensures that Canton participants benefit from a globally recognized and compliant framework, unlocking institutional confidence and cross-border utility.