[CIP discuss] CIP TBD - CIP draft - Canton Access and Privacy Standard (CAPS)

Hi All, 

RedStone, supported by the grant from the Canton Development Fund, is proposing a Standards Track CIP, the Canton Access and Privacy Standard (CAPS): Daml interfaces for publishing, distributing, and verifying oracle data on Canton.

A data set is published in numbered rounds whose price-free records (round number, fixing time, commitment) are visible to the feed's readers; the data travels in capsules that each distributor scopes to its own clients; and a consumer proves on its own participant, with no informee but itself, that a capsule's content is what the oracle's nodes signed and that it is the content fixed in the round of its number. The publisher is a stakeholder of nothing a consumer touches: it learns who holds a license and nothing about consumption.

The standard is oracle-agnostic (an oracle joins by providing one Verifier contract) and builds on the Canton Data Standard: every capsule implements PublishedDataPoint, so applications written against it read CAPS data unchanged.

Draft: https://github.com/canton-foundation/cips/pull/283

Reference implementation (interfaces, reference templates, verifiers for RedStone payloads and for the Data Standard envelope, tests, docs): https://github.com/redstone-finance/canton-access-privacy-standard-public

We welcome feedback on the interfaces and the privacy rules, and, once the discussion settles, a Super Validator willing to sponsor the CIP and a second one to endorse it.

RedStone team

I think there’s a gap that may need to be examined if you haven’t already  

Inside a multi-party transaction, the RoundView passed to Verifier_VerifyRound is supplied by the submitter and is not anchored to a ledger Round, and the round number is not covered by the oracle's signature. Counterparties re-executing the checks therefore confirm authenticity but not canonicality.

The economic consequence is that the submitter holds a free option. They may present any genuinely signed payload within the freshness window, paired with a matching round view, and so settle at whichever price favours it. With the RedStone verifier, a k-of-n threshold below n widens this further, since different package subsets at the same timestamp aggregate to different valid prices. For margin, liquidation and valuation, that is the absence of a canonical fixing that the Motivation section sets out to remove.

Off the top of my head, a potential fix would be that consumers bind to a signed fixing time rather than the unsigned round number, and the signed payload is made unique per fixing time (for RedStone, by requiring every signer or having the nodes sign the aggregate)  

Daryn  

Hi Daryn,

Thank you for reading it this closely. The draft stated the re-execution
claim too broadly: the design rests on a reader checking canonicality
against the round on its own participant, which is why the round is never
fetched, but the text did not say what re-execution gives a party that does
not read the round. The draft in
https://github.com/canton-foundation/cips/pull/283 now makes it precise
(sections 5, 6 and 8, and the rationale):

- Re-execution carries authenticity and freshness; canonicality carries
  over inside a transaction only through the round's attestation, and
  outside it through a reader's own comparison before it consents.
- A round carries an attestation: the data producer's signature over the
  round number and the commitment, checked with keys the consumer pins in
  its own verifier instance. A party that cannot read the round runs the
  same check on the view it is handed; no submitter can forge it. The
  fixing time is covered by the commitment, so it needs no signature of
  its own.
- The producer signs one candidate per round number, so two attested
  candidates for one number are its own equivocation, provable by whoever
  holds both: the one thing the attestation polices rather than excludes.

Fetching the round instead is possible, but the round's signatories confirm
the fetch and learn of it, so the settlement would depend on the operator's
and the auditors' participants and reveal who used which round. Hence not
the default.

On k-of-n: several authentic aggregates per fixing time is the reason a
round, and the producer's designation of one of them, exist. A consumer
that wants no such choice pins the full node set as its quorum, at the
cost of liveness; nodes signing the aggregate would need a consensus
among them that RedStone's nodes do not run.

The reference implementation follows the draft:
https://github.com/redstone-finance/canton-access-privacy-standard-public

RedStone team