Voltar para Documentação

Docs Técnicas

Hedge Contracts

TREA ships two ready-to-use hedge contract templates that settle FX derivative positions whose terms were priced off-chain by QuoteNet:

O conteúdo abaixo vem das fontes técnicas do repositório e é prerenderizado no site para leitura direta por pessoas, crawlers e agentes.

TREA ships two ready-to-use hedge contract templates that settle FX derivative positions whose terms were priced off-chain by QuoteNet:

  • contracts/products/hedge_fx_option.trea
  • contracts/products/hedge_fx_ndf.trea

Like the FX settlement and insurance templates, these contracts do not do price discovery. They consume a signed quote that was produced externally (the QuoteNet provider), verify its Ed25519 signature on-chain, and account for premium, margin and final settlement deterministically.

Products

FxOptionHedge models a simple FX Call/Put option. The requester opens the hedge by presenting a DerivativeQuoteLock signature from the provider and pays the option premium. At maturity, either party submits a SignedFixing from the agreed market-data source; the contract computes the option payoff (max(fixing - strike, 0) * notional for a call, max(strike - fixing, 0) * notional for a put) and settles it from the provider to the requester.

FxNdfHedge models a simple Non-Deliverable Forward. The requester opens the hedge the same way, but locks a margin amount instead of paying a premium. At maturity, the contract computes the absolute difference between the forward rate and the fixing rate, and the side that pays is determined by the difference's sign and by whether the requester is long or short the notional asset (hedge.ndf_requester_is_payer).

Both products support cancelling the hedge as Expired if maturity passes without a fixing being submitted before the configured fixing_deadline.

States

The templates use explicit lifecycle states:

  • Drafted
  • Open
  • Settled
  • Expired
  • Cancelled

Participants

The templates store the relevant parties and the cryptographic material needed to verify off-chain quotes directly in storage:

  • requester / provider
  • provider_public_key, used to verify the DerivativeQuoteLock signature
  • fixing_source / fixing_source_public_key, used to verify the SignedFixing signature

These fields are visible to ABI, receipts and AI Audit, so a reviewer can see which counterparty and which fixing source the contract trusts before it is deployed.

Accounting Effects

The runtime exposes hedge-specific posting helpers:

  • hedge.premium_lines(asset, requester, provider, amount)
  • hedge.margin_lock_lines(asset, requester, provider, amount)
  • hedge.settlement_lines(asset, payer, receiver, amount)

They map to distinct operation kinds:

  • HedgePremium
  • HedgeMarginLock
  • HedgeSettlement

hedge.settlement_lines accepts amount == 0: an out-of-the-money option or a flat NDF fixing is a valid settlement with no posting lines, not an error.

Payoff is computed in Rust, not in TREA, because RuntimeValue::Integer is an unsigned u128; hedge.option_call_payoff, hedge.option_put_payoff, hedge.ndf_payoff_amount and hedge.ndf_requester_is_payer use saturating_sub/checked_mul to avoid underflow and overflow.

Quote and Fixing Verification

  • hedge.verify_option_quote_lock(...) and hedge.verify_ndf_quote_lock(...) verify a DerivativeQuoteLock Ed25519 signature against the provider's registered public key.
  • hedge.verify_fixing(...) verifies a SignedFixing Ed25519 signature against the registered fixing source's public key.

Both intrinsics bind the signed payload to self.active_contract_id, injected by the runtime — never by a TREA argument. This is the same anti-replay mechanism already used by fx.verify_quote_lock: a signature produced for one contract instance cannot be replayed against another instance, even if every other field is identical.

The v0.1 MVP has no global registry of consumed quote_lock_id/fixing_id values. Duplicate use of the same fixing inside one contract instance is blocked by the state machine instead: settle_hedge only runs from Open, and the transition to Settled is irreversible.

Receipts

Each settlement and expiration emits domain events plus a normalized HedgeReceipt event:

text
HedgeReceipt(
  quote_lock_id,
  fixing_id,
  requester,
  provider,
  notional_amount,
  fixing_rate,
  payoff_amount,
  final_state
)

Examples:

  • settlement emits final_state = "Settled" with the fixing id and computed payoff
  • expiration emits final_state = "Expired" with an empty fixing id and zero payoff

Simulation

Both products expose @view functions that let a caller preview the option/NDF payoff for a hypothetical fixing rate before any signature is collected:

  • estimate_payoff(fixing_rate) — the payoff amount
  • estimate_requester_is_payer(fixing_rate) (NDF only) — which side would pay

These functions read storage but cannot write it, so they are safe to call against an Open (or even Drafted) hedge for exposure analysis.

AI Audit

Predeploy AI Audit sees the provider/fixing-source public key fields, the monetary posting effects, the expiry surface (fixing_deadline) and the absence of external ContractRef dependencies or HTTP calls. External facts — the quote and the fixing — enter only as signed transaction parameters, never as live lookups during execution.