4. Technical Architecture & System Design

UST Protocol is built as a hybrid system:

• Terra Classic: All critical logic and funds custody live on Terra Classic (CosmWasm smart contracts). This layer is the source of truth.

• Decentralized off-chain services: Operational components (UI hosting, RPC, indexing, price relays, and optional liquidity bots) run on decentralized third-party infrastructure—primarily Akash Network, Jackal Protocol, and GetBlock.

This split keeps user funds and core rules on-chain (secure and auditable), while the off-chain parts stay decentralized and easy to scale.

4.1. Underlying Blockchain & Infrastructure

4.1.1. Base layer: Terra Classic blockchain

• CosmWasm smart contracts on Terra Classic enforce mint/burn, collateral, yield routing, oracles integration, and safety controls.
• Validators and on-chain governance provide security and transparency.

4.1.2. Operational layer:

We use a mix of Akash, Jackal, and GetBlock for decentralized, pay-as-you-go infrastructure. Deployments are funded on-chain from a protocol-owned multisig wallet, with no logins or passwords.

Key components and providers:

Front-end / dApp UI (stateless web app) – Akash

• Why Akash: Supports one-click deploys for modern frameworks (React, Next.js, Vue), handles domains and TLS.
• How: We deploy a Docker image or link a repo; Akash providers bid to host it. The UI is stateless; assets/config are pinned in CI/CD.

Price-feed oracle relayers / keepers – Akash

• Why Akash: Ideal for long-running containers with environment variables set at deploy.
• Ops: Multiple replicas in different regions for redundancy; stable ingress via Akash IP Leases if needed.

Private RPC provider (Terra Classic full/RPC node) – GetBlock

• Why GetBlock: Reliable, ready-to-use RPC endpoints.
• Usage: Dedicated endpoints for stable, low-latency blockchain access; reduces operational complexity while keeping access decentralized through a third-party provider.

Data indexer (FCD-classic + Postgres) – Akash + Jack

• Why: Provides fast reads and analytics for protocol operations.
• Setup: Runs on Akash for compute and database hosting (Postgres + indexer in Docker containers). Backups stored on Jackal’s decentralized storage network for persistence and recovery. If the database isn’t persistent, it will need to reindex after every reboot—backups solve this.

(Optional) Liquidity-ops bot (e.g., Hummingbot) - Akash

• Fit: Any Dockerized workload can run; recommend externalizing any crucial state.
• Networking: Outbound to DEX/RPC; optional public health probe.

4.1.3. Web3 domain:

• ENS-style name points to the Akash gateway for the dApp. This provides a familiar entry point while keeping hosting decentralized.

4.1.4. Why this setup is decentralized and safe:

• On-chain payments & control: Deployments are funded directly with a multisig wallet; leases and payments happen on-chain in AKT via a reverse-auction marketplace. No single operator can take over infrastructure or funds.

• Redundancy by design: Multiple providers and replicas reduce downtime risk. If one provider fails, we redeploy via the same on-chain process.

• Operational transparency: Changes (like front-end updates) are authorized by multisig votes, creating a clear on-chain audit trail.

4.1.5. Interoperability:

• CCTP V1 Integration: Integration with Circle’s CCTP V1 network allows for native cross chain transfers of USDC between multiple blockchains. 

• IBC Integration: Enables seamless communication and asset transfer between Terra Classic and other blockchains. You can learn more about IBC functionality here - https://ibc.cosmos.network/v8/

• Optional Thorchain/Rujira Integration: Enables native cross chain swaps of multiple assets across multiple chains. You can learn more about Thorchains functionality here - https://dev.thorchain.org/

• Optional EVM Compatibility: Future provisions for EVM bridges are considered to extend USTD’s integration with other EVM-based ecosystems.

4.1.6. Multisig wallets: governance for infrastructure operations:

Why we need them:

•To own and pay for Akash, Jackal, and GetBlock services (leases, storage, RPC), manage the Web3 domain, fund the indexer, and approve emergency UI updates—while safeguarding community funds.

Why safer than a single key:

• If one operator disappears, other signers can renew/migrate leases.
• Prevents domain hijack; mirrors best practice used by major foundations.
• Protects hot wallets that pay AKT gas and renew TLS; no single signer can drain funds.
• Front-end upgrades (e.g., new IPFS hash) require a visible, legitimate multisig vote.

How many wallets:

• 2–4 (e.g., one for hosting/leases, one for domains/certificates, optional separation for monitoring and emergency ops).

Signers & thresholds:

• Total signers (N): 7 to 11 (balances decentralization with agility).
• Threshold (M): 5-of-7, 6-of-9, or 7-of-11 (≥ ~70% quorum). This prevents a small collusion from seizing control while keeping routine actions (e.g., lease renewals) fast.

Legal note:
• All of this sits outside core CosmWasm contracts, so it does not change the utility-token legal analysis; it is sound operational hygiene for auxiliary infrastructure.

4.1.7. Costs & how we pay for them:

Reference pricing (providers):

• GetBlock (RPC): Dedicated node for Terra Classic, starting ~$1,000/month (custom instance).
• Akash (compute): Market-priced via reverse auction; final cost depends on vCPU/RAM/disk bids.
• Jackal (backups): Low monthly cost per TB for storing indexer database backups/artifacts.

Recommended deployment profile (Phase 1 / POC) & monthly estimate:

• RPC: 1× GetBlock Dedicated LUNC node → ~$1,000/mo.
• Indexer: 1× FCD-classic + Postgres on Akash with NVMe → $200–$400/mo, plus Jackal backups (≈ low double-digits per TB).
• App/ops containers on Akash: UI (×2), Keepers (×2), Oracles (×2) → $100–$250/mo depending on bids.
• Minor extras: Web 3.0 domains, IP leases, bandwidth → $25–$50/mo (small swing item).

Estimated total (Phase 1 / POC): $1,325 – $1,700 per month.
Range includes buffer for Akash bid swings, storage size, and egress.

Scale-up scenarios (for clarity):

• If RPC traffic grows meaningfully, the dedicated plan cost may rise; we’ll re-shop options (e.g., different regions, negotiated terms) or consider self-hosting a full node on Akash if it becomes more cost-effective.
• Enterprise requirements: Dedicated RPC (from ~$1,000/mo) or Enterprise plan (from $999/mo) and/or larger Akash indexer volumes. 

Funding source: 

• 50% of yield generated by UST Protocol goes to Protocol Reserves. 2–4% of those reservesare allocated to infrastructure (Akash, Jackal, GetBlock, web 3.0 domains). Payments are automated from multisig-controlled wallets.

Note: Infrastructure setup and hosting providers are subject to change during development/implementation if better or cheaper decentralized options are found.

4.2. Smart Contract Framework

Modular Design - The UST Protocol is composed of four core interconnected modules:

• Minting/Burning Module: Manages collateral deposits, token issuance, and redemptions.

• Yield Harvesting Module: Automates the allocation of collateral to yield-generating liquidity pools.

• Yield Distribution Module: Automates yield distribution between holders and protocol reserves.

• Buyback/Burn Module: Executes market operations to repurchase and burn LUNC & USTC tokens.

4.3. Yield Generation Mechanism

Liquidity Pools:

UST Protocol deploys collateral into stablecoin-to-stablecoin pools on decentralized exchanges (DEXs), where yield is generated primarily through transaction fees and optimized liquidity management.

Automated Harvesting:

Smart contracts continuously monitor pool performance and adjust collateral allocations to maximize yield while mitigating risk.

Importantly, all yield generation processes are hard-coded into the smart contracts and are solely determined by decentralized market dynamics, without any discretionary adjustments or central oversight. This means that yield outcomes are a natural byproduct of liquidity provision, arbitrage opportunities, and other market forces rather than any guarantee made by a central operator.

Harvested yields are automatically split between two primary functions:

• A portion is allocated for direct rewards to USTD holders.

• The remaining portion is reinvested to support buyback and burn operations that help maintain the peg.

4.4. Collateral & Reserve Management

1:1 Backing:

• Every USTD token is fully backed by a corresponding unit of USDC/USDT. Reserves are tracked and governed on Terra Classic L1 (transparent on-chain accounting), while the underlying USDC/USDT is deployed into whitelisted stablecoin-to-stablecoin liquidity pools on decentralized exchanges to earn fees.

Overcollateralization & Diversification (Future Consideration):

• As the protocol scales, a portion of yield may be allocated to building reserves of decentralized assets (e.g., BTC, ETH) to further hedge against volatility and regulatory risks.

Real-Time Auditing:

• On-chain proofs and periodic third-party audits ensure that collateral reserves are fully verifiable at any given time.

4.5. Security Architecture

Smart Contract Audits:

• USTD’s smart contracts are rigorously audited by leading security firms. Audit reports and remediation actions are made publicly available.

Bug Bounty Programs:

• A comprehensive bug bounty initiative encourages external security researchers to identify vulnerabilities, with rewards offered for confirmed findings.

Formal Verification:

• Critical modules—especially those governing yield harvesting and buyback/burn operations—undergo formal verification to ensure their mathematical and functional correctness.

Fallback Mechanisms:

• Emergency protocols (such as circuit breakers) are integrated to protect user funds during extreme market conditions or unforeseen technical issues.