Goldie City

Architecture

This page explains the system architecture at a high level and clarifies boundaries between on-chain modules and off-chain operations.

Goldie City as a launchpad (non-custodial by design)

Goldie City is a launchpad for deploying standardized precious‑metal token ecosystems.

The protocol is designed to be non‑custodial:

Goldie City does not hold user private keys.
Token balances remain controlled by the token holder’s wallet.
Administrative controls are limited to explicit governance actions (for example upgradeability and emergency controls where enabled), and do not operate as a “custodian” of user funds.

Goldie City separates operational responsibilities from governance powers.

Issuer responsibility: the issuer is the accountable operator for real‑world processes (custody/audits, eligibility decisioning, and redemption fulfillment). The protocol provides enforcement and auditability.
Upgradeability (where enabled): upgrades are on-chain transactions and therefore publicly auditable. In the standard “launchpad” model, upgrade authority is controlled by issuer governance (typically an issuer-controlled multisig). This prevents the platform from unilaterally changing token behavior.
Emergency pause (where enabled): emergency controls exist to respond to critical bugs or unsafe conditions. In the standard model, emergency pause/unpause is executed by issuer governance. The platform may request an emergency action, but the issuer approves and executes it on-chain.

Many deployments also add operational safeguards, such as limiting emergency pause duration or requiring multi-approval for emergency actions.

Think of Goldie City as three cooperating parts:

Deployment system: a factory creates a standardized token ecosystem.
Policy system: access control (roles) and compliance decide what is allowed.
Audit trail: registries, state, and events provide observable evidence.

Goldie City is easiest to understand if you separate protocol-level infrastructure (shared) from ecosystem-level modules (per token).

Factory (launchpad): deploys and wires new token ecosystems.
Registries: provide discoverability and lifecycle state (for example issuer eligibility and token discovery), depending on deployment.
Platform governance: shared governance controls and role administration where applicable.

A typical token ecosystem includes:

Token: the asset token itself (balances, transfers, allowances).
Access control: token-scoped roles (and any references to platform roles where applicable).
Compliance: checks eligibility for issuance/transfers (where configured).
Pricing/settlement: transparent pricing inputs and safety checks.
Proof of reserve: publishes latest proof references and validity semantics.
Redemption: records redemption requests and lifecycle transitions.

An end-to-end lifecycle commonly looks like:

Issuer onboarding happens off-chain (KYB), with the result represented on-chain as issuer eligibility state.
Ecosystem deployment occurs on-chain via the factory, producing a discoverable set of module addresses.
Steady-state operations follow: compliance updates eligibility state, users transfer subject to policy, proofs are published on a cadence, and redemptions proceed via an auditable on-chain lifecycle.

Privileged actions require the correct role (platform or token-scoped).
If compliance enforcement is enabled, issuance/transfers cannot bypass it.
Oracle-derived pricing rejects unsafe data according to staleness/validity rules.
Proof publishing yields a single, auditable “latest proof” state.
Redemption produces an on-chain audit trail even though fulfillment is off-chain.

Goldie City separates authority so that issuers are isolated:

Platform roles cover shared protocol controls (for example shared registries and global configuration where applicable).
Token roles cover issuer operations scoped to one ecosystem.

This reduces blast radius: compromising one issuer’s operational key does not grant control over the platform or other issuers.

Rendering diagram…

Rendering diagram…