Deployment Guide
Deployment Guide
Build · Deploy · Verify · Monitor · Upgrade · Roll Back
Procedural reference for building, deploying, and verifying all platform on-chain programs across local, devnet, and mainnet environments. This guide is the authoritative procedure document for the operations team executing deployments and for auditors reviewing the deployment process.
The platform is operated by Groovy Company, Inc. The trading venue is CEDEX. The qualified-custody and onboarding anchor is Empire Stock Transfer. Production deployments support all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3).
This document describes what must happen in each deployment phase, why each step is required, and how each step is verified. Specific commands, code, and configuration files are maintained in the platform's internal operations runbooks and are available to authorized operators and auditors under non-disclosure agreement.
Table of Contents
Prerequisites and Approvals
Repository Structure
Local Development Setup
Building
Testing
Devnet Deployment
Mainnet Deployment
Post-Deployment Initialization
Module-Specific Initialization
Verification Procedures
Monitoring Setup
Upgrade Procedures
Rollback and Emergency Halt
What Cannot Be Rolled Back
Roles and Approvals
1. Prerequisites and Approvals
Required Toolchain
The platform programs are built on the Solana toolchain. Operators must have the following installed and version-aligned with the platform's published toolchain manifest:
ToolPurpose
Rust
Smart-contract compilation
Solana CLI
Cluster interaction, key management
Anchor
Build, test, and deployment framework
Node.js
SDK, scripts, integration tests
Yarn
Package management
jq
JSON parsing in verification scripts
Exact version requirements are maintained in the repository's toolchain manifest and operations runbook. Version mismatches are the single most common source of build determinism issues; auditors verify the toolchain version before reproducing any build.
Hardware Requirements
EnvironmentProfile
Local development
Standard developer workstation, sufficient RAM and SSD for Rust compilation
Devnet deployment
Equivalent to local development
Mainnet deployment
Workstation with redundant connectivity and access to the deployer Ledger device
Key Requirements
OperationKey TypeStorage
Local testing
File system keypair
Local development directory
Devnet deployment
File system keypair, funded via airdrop
Operator's development directory
Mainnet deployment
Ledger hardware wallet
Physical Ledger device, operator-controlled
Program upgrade
5-of-9 multi-signature
Distributed Ledger Enterprise HSMs
Required Approvals Before Mainnet
Mainnet deployment cannot proceed without all of the following:
All unit, integration, fuzz, and end-to-end tests passing.
Certora formal verification: all six invariants verified.
Independent audits (Quantstamp, Halborn, OtterSec): zero Critical or High findings.
Build hash matches the audited source.
Devnet deployment validated for at least seven days under representative load.
Multi-signature wallets configured (5-of-9 for upgrades, 3-of-5 for parameters and emergency).
Timelock program deployed and tested.
Oracle relay infrastructure tested across all module-specific oracles.
Empire Stock Transfer integration verified.
Helius dedicated RPC cluster provisioned. Triton fallback configured.
Datadog monitoring dashboards created. PagerDuty escalation policies configured.
Incident Response Playbook reviewed. Tabletop exercise completed within the prior quarter.
Legal Counsel sign-off on deployment.
CTO sign-off on deployment.
2. Repository Structure
The platform's monorepo contains five on-chain programs, the SDK, integration tests, deployment and initialization scripts, formal-verification specifications, and published audit reports.
Top-Level ComponentPurpose
Anchor and Cargo workspace configuration
Build orchestration
Programs directory
Five on-chain programs (Transfer Hook, AMM, Liquidity Pool, Governance, Oracle Aggregator)
Tests directory
Unit, integration, and end-to-end test suites
SDK directory
TypeScript SDK package consumed by CEDEX backend and external integrators
Scripts directory
Deployment, initialization, verification, and monitoring-setup scripts
Migrations directory
Anchor migration scripts for ordered program deployment
Specs directory
Certora formal-verification specifications corresponding to the six published invariants
Audits directory
Published audit reports from Quantstamp, Halborn, OtterSec, and Certora
The five on-chain programs are deployed in dependency order: Transfer Hook (no dependencies) → Oracle Aggregator → Liquidity Pool → AMM → Governance.
3. Local Development Setup
Local development uses a Solana test validator running on the operator's workstation, configured to load the SPL Token-2022 program from the official binary. This allows full integration testing of the Transfer Hook and Token-2022 interaction without devnet or mainnet exposure.
The local setup procedure is:
Clone the platform repository from the internal GitLab instance.
Install Node.js dependencies and run the Anchor build to produce program binaries and IDL files.
Configure the Solana CLI to point at the local validator.
Generate or import a local keypair for development use only — local keypairs must never be reused for devnet or mainnet operations.
Start the local Solana test validator with the SPL Token-2022 program loaded.
Deploy the platform's five programs to the local validator.
Run the full integration test suite to verify the local deployment is functional.
Local deployment is intentionally low-friction. Failure here typically indicates a toolchain version mismatch.
4. Building
Full Build
A full Anchor build produces five program binaries (one per platform program) and five corresponding IDL files. Build outputs are placed in the standard Anchor target directory.
Build Determinism
Reproducible builds are required so that auditors can verify that the bytecode deployed on chain matches the audited source. Every release is accompanied by a published SHA-256 hash for each program binary. Auditors and institutional reviewers reproduce the build and verify the hash matches.
Build determinism depends on the toolchain version. Operators must use the exact Rust, Solana CLI, and Anchor versions specified in the toolchain manifest at the time of the audited release.
Per-Program Builds
Individual programs can be built without rebuilding the entire workspace. This is useful during development and during upgrade preparation, when only one program is being modified. Per-program builds use the same toolchain and produce the same deterministic output as full builds.
IDL Verification
After build, the generated IDL is compared against a freshly parsed IDL derived from the source files. Any difference indicates a stale build cache or an inconsistency between source and generated artifacts; the build is rejected until reconciled.
5. Testing
Test Categories
CategoryPurposeRequired Pass Rate
Rust unit tests
Per-function correctness within Rust modules
100%
Anchor integration tests
Cross-program behavior on a local validator
100%
Boundary tests
Behavior at exact thresholds (4.99% wallet, 30% breaker, holding-period elapsed)
100%
Fuzz tests
Adversarial inputs across the Transfer Hook and AMM arithmetic
100,000+ runs with zero crashes
Certora formal verification
Symbolic proof of the six invariants
All six invariants must pass
End-to-end tests
Full lifecycle from mint creation through trading to fee distribution
100%
Coverage
Aggregate test coverage of the program codebases
Transfer Hook control logic and CPMM arithmetic at 100%; oracle and governance at 95% or higher
Key Test Scenarios
ScenarioWhat It Verifies
All 42 controls pass on a valid transfer
Successful transfer when every control's preconditions are met
Each control rejects individually when its precondition is violated
Specific error code (6001 through 6042) returned by the right control
Wallet limit boundary at 4.99% versus 5.00%
Control 15 rejects exactly at 5.00% and accepts at 4.99%
Circuit breaker boundary at 30%
Control 20 triggers at threshold and passes below
Holding period: locked versus unlocked
Control 24 rejects before elapsed and accepts after
CPMM u128 arithmetic
Maximum-value inputs do not overflow
CPMM fee accuracy
Fee within 1 lamport of expected value
Global Pool non-extractability
No instruction in any program reduces pool balance
Full lifecycle
Mint creation → offer → hold → unlock → trade → fee distribution all succeed
Circuit breaker recovery
Trigger → halt → cooldown → automatic resume
Formal Verification
The platform's six Certora invariants — E.1 (no unauthorized minting), E.2 (custody ratio), E.3 (pool non-extractability), E.4 (hook completeness), E.5 (fee accuracy), E.6 (circuit breaker correctness) — must all pass on every release before deployment. The Certora run is gated in CI: any specification failure blocks the release.
The full invariant set is documented in the Security Model.
6. Devnet Deployment
Devnet deployment is the operator's first opportunity to validate behavior on a real Solana cluster with mock module-specific oracle feeds. Devnet deployments use a file-system deployer keypair funded via airdrop.
Procedure
Configure the Solana CLI to target devnet.
Generate or load the devnet deployer keypair. Devnet deployer keypairs are isolated from mainnet keys.
Fund the deployer with a minimum of 5 SOL via airdrop (more if multiple deployment cycles are anticipated).
Update the Anchor configuration with the devnet program IDs.
Deploy all five programs in dependency order.
Record the deployed program IDs in the operations runbook and update the Network Configuration page.
Run the automated post-deployment verification script.
Devnet Validation Period
Devnet deployments must run for at least seven days under representative load before mainnet deployment is approved. This validation period exercises:
Custody oracle freshness over many block cycles.
OFAC and AML oracle staleness handling.
Circuit breaker triggering and automatic recovery.
Module 2 NAV oracle reappraisal cycle handling.
Module 3 Classification oracle refresh handling.
End-to-end trading paths under mock load.
7. Mainnet Deployment
Mainnet deployment is irreversible in the most important sense: although programs are upgradeable (except the Liquidity Pool), every transfer the platform processes after deployment is permanent on the Solana ledger.
Pre-Deployment Verification
Before mainnet deployment, the operator confirms every item in Section 1's "Required Approvals Before Mainnet" list. Deployment cannot proceed if any item is incomplete.
Hardware-Wallet Requirement
Mainnet deployment uses a Ledger hardware wallet — never a file-system keypair. The Ledger device is held by the deploying operator under documented chain-of-custody procedures. The operator's identity is logged in the operations runbook for each deployment.
Deployment Sequence
Programs must be deployed in this exact order, because of cross-program dependencies:
Transfer Hook — foundation; no dependencies.
Oracle Aggregator — Transfer Hook reads oracle accounts.
Liquidity Pool — AMM deposits fees here.
AMM — depends on Transfer Hook, Oracle Aggregator, and Liquidity Pool.
Governance — can modify parameters on all of the above.
After all five programs are deployed, the operator records the mainnet program IDs in the operations runbook and proceeds to upgrade-authority transfer.
Upgrade-Authority Transfer
Immediately after deployment, upgrade authority is transferred from the deployer to the appropriate multi-signature wallet. This is the most security-sensitive moment in the entire deployment process — until this transfer is complete, the deployer keypair has unilateral upgrade authority over every program except the Liquidity Pool.
ProgramFinal Upgrade Authority
Transfer Hook
5-of-9 multi-signature
AMM
5-of-9 multi-signature
Oracle Aggregator
5-of-9 multi-signature
Governance
3-of-5 multi-signature
Liquidity Pool
None — upgrade authority is permanently removed
The Liquidity Pool program's upgrade authority is removed via the Solana CLI's --final flag. This action is irreversible. Once complete, the Liquidity Pool program is permanently immutable. No combination of keys, votes, or legal orders can ever modify it. This is the structural foundation of the Global Pool non-extractability guarantee (Certora invariant E.3).
The CTO confirms each upgrade-authority transfer in the operations runbook before the next program is processed.
8. Post-Deployment Initialization
Once programs are deployed and upgrade authorities are transferred, the operator initializes the system accounts. These initializations are also irreversible in important respects.
8.1 Initialize Global Pool
One-time initialization. Seeds the Global Unified CEDEX Liquidity Pool with the platform's initial SOL allocation. Initialization burns LP tokens — no withdrawal function exists in the program code.
After initialization, the operator verifies that:
Global Pool state account is created.
LP mint supply is exactly zero (burned).
LP mint authority is
None.Pool program has no upgrade authority.
If any of these verifications fails, deployment must halt and the issue must be resolved before any other initialization proceeds.
8.2 Initialize Oracle Accounts
Creates the OFAC oracle (a global singleton serving all modules), sets initial staleness thresholds, and registers Empire Stock Transfer's Ed25519 public key for custody-attestation verification.
After initialization, the operator verifies:
OFAC oracle PDA exists and is populated.
Empire's public key is correctly registered.
Staleness thresholds match the values specified in the Network Configuration document.
8.3 Start Oracle Relay Services
Bring oracle relay services online in this order:
Empire custody relay (highest priority — produces per-block attestations).
OFAC indexer.
AML bridge (Chainalysis plus TRM Labs).
TWAP consumer (reads Pyth Network).
EDGAR pipeline (Module 1 issuer-disclosure intelligence).
NAV relay (Module 2 — see Section 9.2).
Classification relay (Module 3 — see Section 9.3).
Each service is verified healthy before the next is started. The custody relay is verified posting attestations within the first three Solana blocks; failure here halts the deployment.
9. Module-Specific Initialization
Each module has additional initialization steps beyond the cross-module foundation. Module-specific initialization is performed per issuance, not per module — every new mint requires the appropriate module-specific oracle and configuration.
9.1 Module 1 — Equities Mint Initialization
For each new equity issuer onboarded by Empire Stock Transfer:
Empire onboarding. Empire Stock Transfer completes issuer-side KYC, KYB, accreditation, and Common Class B custody-deposit confirmation before any on-chain action.
Mint creation. Operator creates the ST22 mint with the Transfer Hook extension permanently attached, the Metadata extension populated with issuer name, symbol, and CUSIP, the Transfer Fee extension set to 5%, and the Permanent Delegate extension set to Empire's authority.
SecurityConfig PDA initialization. Per-mint compliance parameters are set: 4.99% wallet limit, 30% circuit breaker, 2% price-impact cap, 30-minute TWAP window, holding-period configuration matching the offering exemption (Reg D, Reg S, or Reg CF).
ExtraAccountMetaList PDA initialization. Token-2022 hook account-resolution list is populated.
CustodyOracle PDA initialization. Empire's public key is registered for this mint's per-block custody attestations.
CEDEX trading pool initialization. After Empire confirms backing collateral is in custody, the AMM pool for this mint is initialized and seeded.
The Transfer Hook attachment and Permanent Delegate assignment are permanent and irreversible.
9.2 Module 2 — Real Estate Mint Initialization
Module 2 adds NAV oracle initialization and reappraisal-cycle configuration to the standard mint procedure. For each new real-estate property:
Property due diligence. Pre-issuance title search, jurisdictional review, transfer-tax review, and physical inspection completed by the issuer's professional service providers. Empire Stock Transfer reviews the diligence package.
Single-asset entity confirmation. The legal entity holding the property is confirmed in good standing in its jurisdiction of formation. The entity's structure permits Common Class B issuance with the Certificate of Designation filed with the appropriate Secretary of State.
Initial appraisal. An independent licensed appraiser produces the initial Net Asset Value appraisal. The appraisal is signed and submitted to Empire.
Empire onboarding. As with Module 1, Empire completes issuer-side KYC, KYB, and Common Class B custody-deposit confirmation.
Mint creation. Same procedure as Module 1, with the Metadata extension populated with property identifier, jurisdiction, appraisal-cycle tag, and NAV reference.
SecurityConfig PDA initialization. Standard parameters plus Module 2-specific values: NAV deviation maximum (in basis points), reappraisal maximum age, and the NAV-circuit-breaker enabled flag.
NAVOracle PDA initialization. Per-mint NAV oracle account created. The appraiser's authentication credentials and reappraisal-cycle cadence are registered.
CustodyOracle, ExtraAccountMetaList, and trading pool initialization. Same as Module 1.
The NAV reappraisal cadence is per-property and is set in the offering documentation. Common cadences are quarterly and semi-annually depending on property type.
9.3 Module 3 — CORECM Mint Initialization
Module 3 adds federal-classification oracle initialization and enhanced regulatory verification. For each new basin asset:
Geological and regulatory diligence. Independent geological survey of proven reserves. Verification of the basin's classification on the United States Geological Survey Critical Minerals List and the Department of Energy Critical Materials Strategy. Confirmation of the basin's status under Section 232 of the Trade Expansion Act of 1962, Title III of the Defense Production Act, the Inflation Reduction Act critical-minerals provisions, Executive Order 14017, and the Energy Act of 2020.
Basin-asset entity confirmation. The legal entity holding the basin or mining concession is in good standing. Mineral rights, surface rights, and any applicable federal program participation (such as Department of Energy coal-derived rare-earth element recovery) are documented.
Empire enhanced onboarding. Empire Stock Transfer applies enhanced KYC depth for Module 3 issuances, including verification of any federal program eligibility constraints applicable to the basin.
Mint creation. Same procedure as Module 1, with the Metadata extension populated with basin identifier, USGS classification, jurisdiction, and mineral-class tag.
SecurityConfig PDA initialization. Standard parameters plus Module 3-specific values: classification maximum age (24 hours by default) and the federal-action-freeze enabled flag.
ClassificationOracle PDA initialization. Per-mint classification oracle account created. USGS and DOE feed sources are registered. Initial classification is recorded.
CustodyOracle, ExtraAccountMetaList, and trading pool initialization. Same as Module 1.
If a basin asset participates in a federal program (such as DOE coal-derived rare-earth element recovery), the program's eligibility and reporting obligations are documented in the offering disclosure and reflected in the ClassificationOracle initial state.
10. Verification Procedures
After every deployment — devnet or mainnet — the operator runs an automated verification script and confirms each result against the expected baseline.
Verification Categories
CategoryWhat Is Verified
Program deployment
All five programs are present on the target cluster
Upgrade authorities
Each program's upgrade authority matches the expected multi-signature address (or None for the Liquidity Pool)
Transfer Hook attachment
Each ST22 mint has the Transfer Hook extension pointing to the correct program
SecurityConfig parameters
Per-mint parameters match the expected values for the issuance's module
Custody Oracle freshness
Oracle is updating within one to two slots of the current Solana slot
Module 2 NAV oracle (per Module 2 mint)
NAV oracle has a valid initial appraisal and the next-reappraisal timestamp is set
Module 3 Classification oracle (per Module 3 mint)
Classification oracle has a valid initial classification from USGS and DOE feeds
Global Pool LP burn
LP mint supply is zero and LP mint authority is None
Liquidity Pool program immutability
Pool program upgrade authority is None
Failure Handling
Any verification failure halts the deployment. The operator does not proceed to the next phase until the failure is investigated, the cause identified, and the issue resolved. For mainnet deployments, verification failures trigger a P1 incident response notification to the CTO.
11. Monitoring Setup
Datadog Integration
After successful deployment and verification, monitoring is brought online before any external traffic is permitted to reach the platform. Datadog dashboards are populated with the deployed program addresses and oracle PDAs.
Key Dashboards
DashboardPrimary MetricsCritical Alert Threshold
Transfer Hook
Control pass/fail rate, latency per control, error code distribution
Any Error 6001 (custody) → P0
CEDEX Trading
Order volume, fill rate, pre-flight rejection rate, average latency — segmented by module
Fill rate below 90% → P1
Oracle Health
Custody freshness (slot age), OFAC staleness, AML cache age, NAV freshness (Module 2), Classification freshness (Module 3)
Custody age above 5 slots → P0
Circuit Breakers
Active breakers, trigger count, cooldown status
Any global breaker → P1
RPC Performance
Request latency, error rate, sendTransaction throughput
Latency above 500ms → P2
Global Pool
Total deposited, fee deposit count, balance
Balance decrease → P0 (Certora invariant violation)
PagerDuty Escalation
SeverityResponse SLAEscalation
P0
15 minutes
CTO plus Legal Counsel plus all multi-signature holders
P1
1 hour
CTO plus DevOps lead
P2
4 hours
On-call engineer
P3
24 hours
On-call engineer
Health-Check Endpoint
The platform exposes a public health-check endpoint that returns the status of every oracle and the global circuit breaker. Automated external monitoring polls this endpoint every 60 seconds. Any non-healthy status triggers PagerDuty escalation per the table above.
12. Upgrade Procedures
Parameter Adjustment
Parameter adjustments — fee changes within governance bounds, threshold modifications, cooldown changes — follow the Parameter Authority procedure:
Governance proposal created (proposal type: Parameter Adjustment).
Voting period of at least 48 hours.
Simple majority required for passage.
48-hour timelock after passage.
3-of-5 multi-signature execution after timelock expires.
On-chain verification that the parameter is updated.
Parameter adjustments cannot exceed the governance ranges hard-coded in the program. For example, the wallet-limit parameter accepts values from 1.00% to 9.99%; values outside this range are rejected at the program level regardless of governance vote.
Program Upgrade
Program upgrades — Transfer Hook, AMM, Oracle Aggregator — follow the Upgrade Authority procedure, which is more restrictive than parameter adjustment:
New program version built with toolchain matching the audited release.
Build hash verified against the audited source.
Certora formal verification re-run on the new code: all six invariants must pass on the new bytecode.
Independent audit attestation obtained from Quantstamp or Halborn covering the upgrade scope.
Governance proposal created (proposal type: Program Upgrade).
Voting period of at least 48 hours.
Two-thirds supermajority required for passage (not simple majority).
24-hour timelock after passage.
During the timelock, any 2-of-5 of the parameter-authority multi-signature can cancel the upgrade.
After timelock expiry, 5-of-9 multi-signature executes the BPF upgrade instruction.
On-chain verification that the program bytecode hash matches the new audited version.
What Upgrades Cannot Do
Even with full multi-signature authority, no upgrade can:
Remove any of the 42 Transfer Hook controls (Certora invariant E.4 would fail).
Lower a holding period below the statutory minimum (hard-coded constants are outside parameter space).
Add a withdrawal function to the Global Pool (the Liquidity Pool program is immutable).
Remove the Transfer Hook from existing mints (SPL Token-2022 standard makes hook attachment permanent).
Bypass the multi-signature requirement (multi-signature is enforced at the Solana program level).
Liquidity Pool Upgrades
The Liquidity Pool program has no upgrade authority. It cannot be upgraded by any combination of keys, votes, or legal orders. This is the architectural foundation of the Global Pool non-extractability guarantee. Operators must understand that any future limitation discovered in the Liquidity Pool program cannot be patched — it can only be worked around by external programs that consume the pool's interface.
13. Rollback and Emergency Halt
Program Rollback
If a deployed upgrade introduces a critical issue that is not caught during the timelock window, rollback is possible for upgradeable programs. The procedure mirrors the upgrade procedure in reverse:
Identify the previous program buffer address from deployment logs.
Coordinate the same multi-signature threshold required for an upgrade (5-of-9 for Transfer Hook, AMM, and Oracle Aggregator).
Deploy the previous version's buffer to the program ID.
Verify the rolled-back program's bytecode hash matches the previously audited version.
Document the rollback in the operations runbook with root cause analysis.
Rollback latency is at least 24 hours due to the standard upgrade timelock, unless the issue qualifies for emergency halt (see below) as an interim measure.
Emergency Halt
If immediate action is required before a rollback can be coordinated, the platform's emergency-halt mechanism (Control 42, regulatory freeze) can pause transfers on affected mints immediately. Emergency halt:
Requires Legal Counsel authorization plus 3-of-5 multi-signature.
Has no timelock — execution is immediate.
Halts all transfers on the affected mint until lifted.
Does not move tokens — it pauses, it does not redirect.
Is logged on-chain as an immutable compliance record.
Emergency halt is the correct response to a Critical-severity incident under the Security Model's P0 procedure. Rollback follows once root cause is understood and a verified replacement is ready.
14. What Cannot Be Rolled Back
These actions are permanent and cannot be undone by any procedure:
ActionReason
Transfer Hook attachment to a mint
SPL Token-2022 standard — hook address is permanently stored in the mint account
Global Pool LP burn
LP mint authority was set to None at initialization; tokens cannot be re-minted
Removal of Liquidity Pool program upgrade authority
The Solana CLI --final flag is permanent; the program is immutable forever
On-chain compliance audit trail
Solana ledger is immutable
Empire custody-deposit confirmation logged on-chain
Same
Operators must understand these properties before they execute the corresponding initialization steps. The platform's security guarantees rest on these irreversibilities.
15. Roles and Approvals
RoleResponsibilitiesSign-off Required For
Chief Technology Officer (Frank Yglesias)
Engineering oversight; final technical sign-off on every mainnet deployment and upgrade
Mainnet deployment; program upgrades; emergency halts
Legal Counsel (JDT Legal)
Regulatory and legal sign-off; coordination with SEC and other regulators
Mainnet deployment; emergency halts; regulatory-freeze authorizations
Empire Stock Transfer (Patrick Mokros, Founder)
Custody, onboarding, and qualified-custodian functions for all modules
Custody-deposit confirmations; per-mint onboarding completion
Multi-signature signers (5-of-9)
Geographically distributed key holders for Transfer Hook, AMM, and Oracle Aggregator program upgrades
Program upgrades
Multi-signature signers (3-of-5)
Parameter authority and emergency authority signers
Parameter adjustments; emergency halts
DevOps lead
Infrastructure operations and monitoring
Datadog and PagerDuty configuration; oracle relay deployment
On-call engineer
First response for P0 through P3 incidents
Incident triage and initial containment
No single role has unilateral authority over any production action. Every mainnet operation requires at least two-party approval, and program upgrades require coordinated multi-signature execution across at least five geographically distributed signers.
Related Documentation
Solana Blockchain Foundation — Why Solana, Token-2022, Transfer Hook, module-specific foundations
Architecture Decisions — ADR-001 through ADR-012 with full alternatives analysis
Security Model — Threat model, key management, formal verification, module-specific threat surfaces
Infrastructure Overview — Cloud architecture, environment separation, blockchain infrastructure
Network Configuration — Program addresses, RPC endpoints, oracle PDAs, multi-signature addresses, production parameters
Smart Contract Reference — Program instruction specifications, account schemas, error codes
Oracle Integration Guide — Oracle relay service architecture, fail-safe cascade, module-specific oracles
Testing Guide — Detailed test procedures and coverage targets
Incident Response Playbook — P0 through P3 runbooks, communication protocol
RWA Tokens · Deployment Guide · Groovy Company, Inc.
Last updated
Was this helpful?