Contracts

This page summarizes the on-chain contracts that make up a typical Goldie deployment and how they relate.

Goldie is modular: some contracts are shared infrastructure (used across ecosystems), while others are deployed per token ecosystem (scoped to a specific issuer/token). Exact sets vary by deployment and enabled features.

For wiring diagrams, see the Architecture page: /docs/architecture.

Shared infrastructure (protocol-level)

PreciousMetalTokenFactoryOptimized

The factory deploys and initializes a standardized ecosystem (token + per-ecosystem modules) and records the resulting addresses in discoverability layers (for example registries).

PlatformAccessManager

Defines platform-scoped roles for shared controls (for example shared registries and shared configuration). In deployments with emergency controls, platform authority is explicitly scoped to the actions enabled by governance.

IssuerRegistry

Represents issuer lifecycle state (for example eligibility/verification status). Ecosystem creation is commonly gated by issuer status.

TokenRegistry

Provides discoverability for deployed ecosystems (for example listing token addresses and/or associated module addresses) and supports indexers and integrators.

PreciousMetalPricingOracle

Provides pricing inputs used by settlement logic. Safety expectations typically include feed allowlists and staleness/validity checks.

PreciousMetalReserveProof

Stores a single “latest proof” reference per token address (plus events). This creates an auditable on-chain anchor for proof-of-reserve publishing cadence.

PreciousMetalBackingVerifier

Optional adapter/verifier that interprets proof-of-reserve state for consumers that need a boolean backing status (for example UIs or discovery flows).

Per-ecosystem modules (token-scoped)

PreciousMetalToken

The asset token itself (balances, transfers, allowances). Transfer behavior is designed to be enforceable by policy modules when configured.

TokenAccessManager

Defines token-scoped roles for issuer operations within a single ecosystem (for example mint/burn where enabled, compliance administration, redemption operations, and other token-scoped privileged actions).

ComplianceRouter (and SecuritiesComplianceRouter where applicable)

On-chain compliance enforcement layer. The router pattern supports policy composition and multi-authority operation (platform-scoped policy + token-scoped policy), depending on deployment configuration.

PreciousMetalPriceSettlement

Settlement-related logic that consumes oracle inputs and configured parameters to compute pricing/settlement values under explicit safety rails.

PreciousMetalRedemptionManager

Records an on-chain redemption lifecycle (requests and state transitions) to create an auditable trail, even when real-world fulfillment occurs off-chain.

Interfaces and extension points

• IComplianceChecker defines the on-chain interface expected by enforcement points.
• Some deployments integrate external attestation systems (for example via an IEAS interface) for proof references.

How integrators typically locate a deployment

• Use TokenRegistry (or deployment-specific discovery primitives) to find token addresses and associated module addresses.
• Use emitted events (for example ecosystem creation, proof publishing, redemption lifecycle events) for indexing and monitoring.

What external reviewers commonly evaluate

• Authority boundaries: which actions are platform-scoped vs issuer-scoped; how upgrades/emergency controls are authorized.
• Enforcement points: whether compliance checks are applied at issuance/transfer (where enabled) and cannot be bypassed.
• Oracle safety rails: staleness handling, feed allowlists, and governance of parameters.
• Proof semantics: what “latest proof” means (freshness/validity), how revocation or invalidation is represented.
• Redemption auditability: clear states/events that can be reconciled with off-chain fulfillment.