Cosmos SDK Foundation
Specter is built on Cosmos SDK v0.53.2, the application framework for building sovereign, interoperable blockchains. The Cosmos SDK provides the module system, transaction handling, account model, and state machine that form the backbone of the Specter chain. Combined with CometBFT consensus and a full EVM, it gives Specter the flexibility to support both native Cosmos operations and Ethereum-compatible smart contracts.
Chain Identity
| Parameter | Value |
|---|---|
| Cosmos SDK Version | v0.53.2 |
| CometBFT Version | v0.38.17 |
| Bech32 Prefix | specter (accounts), spectervaloper (validators), spectervalcons (consensus) |
| Cosmos Chain ID | specter-testnet-1 |
| Native Denomination | aghost (1 GHOST = 10^18 aghost) |
| Binary Name | specterd |
The bech32 prefix specter is used for all native Cosmos addresses. Validator operator addresses use spectervaloper and consensus addresses use spectervalcons. On the EVM side, standard 0x-prefixed Ethereum addresses are used, with automatic conversion between the two formats.
CometBFT Consensus
CometBFT v0.38.17 is the consensus engine underlying the Specter chain. It implements a BFT (Byzantine Fault Tolerant) consensus protocol derived from Tendermint, providing strong safety and liveness guarantees.
Consensus Properties
Two-thirds-plus agreement. Every block requires pre-vote and pre-commit messages from validators representing more than 2/3 of the total staked weight. A block that receives 2/3+ pre-commits is considered committed and final.
Immediate finality. Unlike probabilistic finality chains (Bitcoin, Ethereum PoW), CometBFT blocks are final the moment they are committed. There are no confirmations to wait for, no reorganizations to worry about, and no uncle blocks. A transaction included in a committed block will never be reverted.
Byzantine safety. The network tolerates up to 1/3 of validators being Byzantine (malicious, offline, or faulty) without compromising safety. If more than 1/3 of validators go offline, the chain halts (preserving safety) rather than producing potentially conflicting blocks.
Block production. Specter is tuned for ~2.5-second block times, balancing interactive application responsiveness with consensus round-trip overhead. The mempool supports up to 20,000 pending transactions.
Module Architecture
The Cosmos SDK organizes blockchain functionality into discrete modules, each responsible for a specific domain. Specter uses the standard SDK modules plus a custom x/ghostmint module that bridges the privacy protocol to native token operations.
Core Modules
| Module | Source | Role |
|---|---|---|
x/auth | Cosmos SDK | Account management, transaction authentication, signature verification |
x/bank | Cosmos SDK | Native token transfers, supply tracking, multi-denomination balances |
x/staking | Cosmos SDK | Validator registration, delegation, unbonding, reward distribution |
x/slashing | Cosmos SDK | Validator punishment for double-signing and extended downtime |
x/gov | Cosmos SDK | On-chain governance: proposals, deposits, voting, execution |
x/distribution | Cosmos SDK | Block reward and fee distribution to validators and delegators |
x/mint | Cosmos SDK | Inflation control (configured for zero inflation on Specter) |
x/evidence | Cosmos SDK | Submission and handling of Byzantine validator evidence |
x/feegrant | Cosmos SDK | Fee allowances enabling one account to pay fees for another |
x/upgrade | Cosmos SDK | Coordinated chain upgrades without hard forks |
EVM Modules
| Module | Source | Role |
|---|---|---|
evm (vm) | cosmos/evm v1.0.0-rc2 | Full Ethereum Virtual Machine execution within Cosmos |
evm (feemarket) | cosmos/evm v1.0.0-rc2 | EIP-1559 dynamic base fee and priority fee market |
evm (erc20) | cosmos/evm v1.0.0-rc2 | Bidirectional conversion between Cosmos native tokens and ERC-20 |
Custom Module
| Module | Source | Role |
|---|---|---|
x/ghostmint | Specter | Bridges EVM smart contracts to x/bank for native GHOST minting and burning. Provides the ghostmint precompile at 0x0808. Tracks cumulative mint/burn totals. Enforces supply invariant every block. |
IBC Module
| Module | Source | Role |
|---|---|---|
ibc | ibc-go v10 | Inter-Blockchain Communication protocol for cross-chain transfers and data |
IBC enables Specter to communicate with any IBC-compatible chain in the Cosmos ecosystem. This includes transferring tokens to/from other chains, cross-chain governance messages, and custom IBC packet types. The ibc-go v10 dependency provides the latest IBC protocol features including multi-hop channels.
The x/ghostmint Module
The x/ghostmint module is Specter's custom Cosmos SDK module. Its primary purpose is to enable EVM smart contracts (specifically the NativeAssetHandler) to mint and burn native GHOST tokens by calling into the Cosmos x/bank module through an EVM precompile.
Why a Custom Module?
In a standard Cosmos EVM chain, EVM contracts cannot directly interact with native Cosmos module operations like minting or burning tokens. The x/bank module manages native token supply, but it is only accessible through Cosmos SDK message handlers — not through EVM opcodes.
The x/ghostmint module solves this by:
- Registering an EVM precompile at address
0x0808that EVM contracts can call like any other contract - Routing those calls through a keeper that has direct access to the
x/bankmodule's mint and burn functions - Enforcing authorization so only designated NativeAssetHandler contracts can trigger minting/burning
- Tracking supply with cumulative
totalMintedandtotalBurnedcounters stored in the module's KVStore - Checking invariants every block to detect unexpected supply changes
Supply Invariant
The ghostmint module runs a supply invariant check at the end of every block. It compares the current total supply of GHOST (from x/bank) against the previous block's supply. If the supply has increased unexpectedly (indicating inflation outside of the ghostmint mint/burn cycle), the module logs an error.
This invariant operates at the consensus level, independent of the EVM smart contract layer, providing a defense-in-depth check against bugs in the contract system.
Hard Cap
A hard maximum mint supply of 1 billion GHOST (10^27 aghost) is enforced at the module level. Even if a bug in the vault contracts allowed unbounded minting calls, the ghostmint keeper would reject any mint that would push the cumulative total above this cap.
Validator Mechanics
Specter uses Proof-of-Stake consensus with GHOST as the staking token.
Staking
- Validators must stake GHOST tokens to participate in consensus
- Delegators can delegate their GHOST to validators and earn a share of block rewards
- Unbonding period applies when un-staking (tokens are locked during this period)
- Validator voting power is proportional to their total stake (self-stake + delegations)
Slashing
Validators face economic penalties for two categories of misbehavior:
| Offense | Trigger | Consequence |
|---|---|---|
| Double-signing | Validator signs two different blocks at the same height | Severe slash of staked tokens, permanent jailing |
| Downtime | Validator misses a threshold of consecutive blocks | Moderate slash, temporary jailing (can unjail) |
Slashing is enforced automatically by the x/slashing module based on evidence submitted through CometBFT. Double-signing evidence can be submitted by any network participant.
Governance
The x/gov module enables on-chain governance for protocol upgrades and parameter changes. Governance proposals follow this lifecycle:
Governance can modify chain parameters, trigger software upgrades, spend community pool funds, and execute arbitrary module-level operations — including updating the authorized callers for the ghostmint precompile.
Transaction Flow
A transaction on Specter follows this path through the stack:
Both native Cosmos transactions and Ethereum-formatted transactions are supported. Ethereum JSON-RPC endpoints are available for standard Ethereum tooling (MetaMask, Foundry, ethers.js), while Cosmos endpoints support Cosmos-native clients and IBC relayers.