2.1 Detailed Daml Contract Specification

The Daml smart contract language is pivotal in ensuring the system is privacy-first and auditable. Daml enforces strict authorization rules and fine-grained privacy on a need-to-know basis.

This architecture leverages Daml's native capabilities to keep proprietary trading strategies and complex approval logic entirely within the permissioned Canton domain, ensuring such sensitive data never touches the public ledger.

A. Roles and Permissions (Vault.Policy:Role)

The implementation defines standard institutional roles:

Role	Responsibilities	Daml Enforcement
Operator	Proposes strategy changes	signatory on proposals
RiskOfficer	Monitors compliance	observer on policies
Approver	Signs off on high-value actions	controller for approval choices

RBAC Implementation

Daml's intrinsic Role-Based Access Control (RBAC) utilizes the signatory and observer keywords to enforce these permissions. This structure guarantees:

• Granular access controls
• Party whitelisting
• Prevention of unauthorized contract creation or viewing

B. Policy Definition (Vault.Policy:VaultPolicy)

The VaultPolicy contract represents the non-public, auditable constraints that govern the vault's operation.

Key Parameters

template VaultPolicy
  with
    policyId: Text
    controller: Party
    riskOfficer: Party
    maxExposurePerc: Decimal
    allowedProtocols: [Text]
    approverQuorum: Int
    approvers: [Party]
  where
    signatory controller
    observer riskOfficer

Critical Parameters

• maxExposurePerc: Maximum exposure percentage per protocol
• allowedProtocols: Whitelist of approved DeFi protocols
• approverQuorum: Number of approvals required for Flow B
• approvers: List of parties authorized to approve proposals

Living Document Design

The VaultPolicy is designed as an active, living document on the Canton ledger:

• Any execution decision (Flow A or B) must reference an active VaultPolicy instance
• Rebalances are halted if proposed actions violate current constraints
• Real-time compliance enforcement at the ledger level
• If policy check fails, transaction reverts internally

This prevents non-compliant operations from ever generating a signed instruction for the public chain.

C. Proposal and Approval Workflow (Vault.Policy:RebalanceProposal)

When human intervention or high-value approval is required (Flow B), the RebalanceProposal template is created.

Contract Structure

template RebalanceProposal
  with
    proposalId: Text
    vaultId: Text
    proposer: Party
    approvers: [Party]
    proposedAllocations: [(Text, Decimal)]
    approvals: [Party]
    quorumRequired: Int
    policy: ContractId VaultPolicy
  where
    signatory proposer
    observer approvers

    choice ApproveProposal : ContractId RebalanceProposal
      with
        approver: Party
      controller approver
      do
        assertMsg "Not authorized approver" (approver `elem` approvers)
        assertMsg "Already approved" (approver `notElem` approvals)
        create this with approvals = approver :: approvals

    choice ExecuteProposal : ContractId ExecutionIntent
      controller proposer
      do
        assertMsg "Quorum not met" (length approvals >= quorumRequired)
        -- Generate ExecutionIntent

Features

Confidential Storage:

• Full allocation proposal details remain private
• Protocol weightings kept confidential until consensus

Composable Approvals:

• ApproveProposal choice allows designated Approver parties to sign
• Daml's transaction logic ensures ExecutionIntent only created after quorum met

Immutable Audit Trail:

• Who initiated the proposal
• Who signed and when
• When consensus was reached
• Compliance-ready audit log with secure access controls

D. Execution Intent (Vault.Policy:ExecutionIntent)

The ExecutionIntent contract is the key cryptographic interface to the external world.

Data Minimization

Embodies the concept of data minimization critical for:

• Regulatory compliance (e.g., GDPR)
• Strategy protection
• Commercial privacy

Contract Structure

template ExecutionIntent
  with
    vaultId: Text
    nonce: Int
    actions: [Action]
    deadline: Time
    issuer: Party
    cantonSignature: Text
  where
    signatory issuer

data Action = Action
  with
    protocol: Text
    operation: Text
    params: [(Text, Text)]

Minimal Payload

Contains only the minimal data necessary for external execution:

• vaultId: Identifier for the target vault
• nonce: Anti-replay protection
• actions: Serialized list of operations
• deadline: Expiration timestamp

Privacy Preservation

Sensitive data remains private within Canton:

• Risk scores
• Optimization logic
• Full proposal details
• Internal strategy calculations

Only the verifiable, signed intent is published, ensuring:

• Data confidentiality
• Cryptographically sound instruction
• Non-repudiable authorization

Governance Structure Summary

Daml Template	Key Data Stored (Confidential)	Authorization Enforced	Role in Execution Flow
VaultPolicy	maxExposurePerc, allowedProtocols, Strategy ID	Signatory: Controller/Risk Officer	Gating mechanism for all new Intents
RebalanceProposal	proposedAllocations (Full Detail), Approvals List	Signatory: Proposer, Controller: Approvers	Private stage for multi-party consensus (Flow B)
ExecutionIntent	vaultId, nonce, actions (Minimal), deadline	Signatory: Policy Issuer (Canton Party)	Cryptographically verifiable proof of policy approval