OwarineDocs
Open app
How it works

Who sees what

Core contract stakeholders and the shared participant's server trust boundary.

Reviewed 2026-10-06

Canton contract visibility follows stakeholders: signatories and observers. A seat's position and cash belong to a different visibility group from the oracle prices and resolution.

Core contract visibility groups

Loading diagram…

Read diagram source

flowchart TD
contracts[Core Daml contracts] --> private[Seat and venue]
contracts --> evidence[Price and outcome]
contracts --> series[Series]
private --> legs[Leg, VenueCash, VenueAccount]
private --> quotes[Quote and BuyQuote]
private --> records[Publication and SettlementReceipt]
evidence --> prices[PriceQuote: its oracle, venue, resolver]
evidence --> outcome[OpenPrint and Resolution: resolver, venue]
series --> readers[Venue, resolver, auditor]
ContractSignatoriesObservers
SeriesVenueResolver, auditor
MarketTerms, WindowStateVenueResolver
PriceQuoteThe oracle that posted itVenue, resolver
OpenPrint, ResolutionResolver, venueNone
Quote, BuyQuoteVenueQuoted seat
VenueAccount, VenueCash, LegVenue, ownerNone
Publication, SettlementReceiptVenue, ownerNone
AgentGrantOwner, venueNamed agent

This table covers the core market path. Ticket, desk and game templates have their own stakeholder declarations in the corresponding Daml packages.

Disclosure and public pages

A seat is not a stakeholder on Resolution. Settlement exposes the relevant result inside the transaction, and Leg_Claim can receive it as a disclosed contract. That does not make every other seat's position visible.

A Publication is still bilateral on the ledger. Its owner's choice to publish permits the app to use the projected record in public profiles and leaderboards. Public website access and ledger stakeholder access are separate checks.

The venue sees positions as counterparty. Owarine's shared participant and server credentials are an additional trust boundary: server routes must bind requests to the current lease. System context explains that boundary.

Private balance and ordinary cash

Private mode is implemented using the same bilateral VenueCash contract with bucket = "private". A private call is an ordinary bilateral Leg tagged beneficiaryRef = "private". Its stakeholders remain the owner and venue; moving into a private bucket does not hide it from the venue.

The server separates private cash and legs from ordinary spendable cash and the public portfolio. Private calls stay in the private list and are excluded from ordinary exits and publication routes. Moving funds into or out of the bucket uses an atomic seat-and-venue transaction.

In abu-pm-main 0.5.2, settlement, owner claim and stale refund route any private-call proceeds directly back to the private bucket. A settlement receipt records paidInto = "private"; a loss has zero owner payout. The older Cash out compatibility path applies to receipts paid by the 0.5.1 engine into ordinary cash.

Cash and Trading Balance are app views, not additional Daml stakeholder groups. The Trading Balance component supports available, private, in-trade and grant figures; the ledger contracts and server read split determine what those figures represent. A displayed balance or an implemented private route does not by itself establish a completed hosted private-call journey.

On this page