Security

Overview

Security is foundational to Nonterritorial's mission. We're building infrastructure meant to last generations—this requires security practices that match that ambition.

Our security model addresses multiple layers: smart contract security, chain security, operational security, and content integrity. Each layer has specific threats, mitigations, and verification mechanisms.

---

Security Philosophy

Defense in Depth

No single security measure is sufficient. We implement multiple overlapping protections:

┌─────────────────────────────────────────────────────────────────┐
│                      SECURITY LAYERS                            │
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │  Layer 1: Language Safety (Rust/CosmWasm)                 │ │
│  │  • Memory safety at compile time                          │ │
│  │  • No buffer overflows, null pointers, data races         │ │
│  └───────────────────────────────────────────────────────────┘ │
│                              │                                  │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │  Layer 2: Contract Architecture                           │ │
│  │  • Actor model prevents reentrancy                        │ │
│  │  • Minimal attack surface                                 │ │
│  └───────────────────────────────────────────────────────────┘ │
│                              │                                  │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │  Layer 3: Professional Audits                             │ │
│  │  • Multiple independent auditors                          │ │
│  │  • Pre-mainnet and ongoing                                │ │
│  └───────────────────────────────────────────────────────────┘ │
│                              │                                  │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │  Layer 4: Operational Security                            │ │
│  │  • Multi-signature administration                         │ │
│  │  • Hardware security modules                              │ │
│  └───────────────────────────────────────────────────────────┘ │
│                              │                                  │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │  Layer 5: Continuous Monitoring                           │ │
│  │  • Bug bounty program                                     │ │
│  │  • Real-time alerting                                     │ │
│  └───────────────────────────────────────────────────────────┘ │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Transparency

Security through obscurity doesn't work. Our approach:

• All contract source code is public

• Audit reports published in full

• Security incidents (if any) disclosed transparently

• Bug bounty program open to all researchers

---

Smart Contract Security

Language Choice: Rust

Nonterritorial smart contracts are written in Rust using CosmWasm. This choice eliminates entire categories of vulnerabilities common in Solidity/EVM:

Vulnerability	Solidity/EVM	Rust/CosmWasm
Buffer Overflow	Possible	Prevented at compile time
Null Pointer Dereference	Possible	Prevented at compile time
Data Races	Possible	Prevented at compile time
Reentrancy	Common attack vector	Prevented by architecture
Integer Overflow	Requires SafeMath	Checked by default
Uninitialized Storage	Possible	Not applicable

CosmWasm Architecture

CosmWasm's actor model provides structural security:

// CosmWasm execution flow - reentrancy impossible by design

pub fn execute(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, ContractError> {
    // 1. Validate inputs
    // 2. Update state
    // 3. Return response with sub-messages
    
    // External calls happen AFTER this function returns
    // State is already committed - no reentrancy possible
    
    Ok(Response::new()
        .add_message(bank_send)  // Executed after state commit
        .add_attribute("action", "execute"))
}

Why Reentrancy Is Impossible:

In Solidity, external calls happen during execution—allowing callbacks before state updates complete. In CosmWasm, all state changes commit before any external messages execute. The attack vector doesn't exist.

Access Control

All privileged functions verify authorization:

fn execute_admin_function(
    deps: DepsMut,
    info: MessageInfo,
    // ... parameters
) -> Result<Response, ContractError> {
    // Verify caller is authorized
    let config = CONFIG.load(deps.storage)?;
    
    if info.sender != config.admin {
        return Err(ContractError::Unauthorized {});
    }
    
    // Proceed with privileged operation
    // ...
}

Immutable Core Logic

Constitutional protections cannot be modified:

// These constraints are hardcoded, not configurable
pub fn validate_constitutional_compliance(
    proposed_change: &ProposedChange,
) -> Result<(), ContractError> {
    // Artist share floor - cannot be reduced below 35%
    if proposed_change.affects_artist_share() {
        if proposed_change.new_artist_share < Decimal::percent(35) {
            return Err(ContractError::ConstitutionalViolation {
                constraint: "Minimum artist share is 35%".to_string(),
            });
        }
    }
    
    // Anti-speculation - transfer can never be enabled
    if proposed_change.enables_transfer() {
        return Err(ContractError::ConstitutionalViolation {
            constraint: "Transfer functionality cannot be added".to_string(),
        });
    }
    
    Ok(())
}

---

Chain Security

CometBFT Consensus

Nonterritorial uses CometBFT (Tendermint) consensus, battle-tested across 50+ production chains managing billions in value.

Byzantine Fault Tolerance:

• Tolerates up to ⅓ malicious validators

• Instant finality—no chain reorganizations

• Deterministic block production

Validator Requirements:

• Minimum stake commitment

• Hardware Security Module (HSM) for signing keys

• Geographic distribution

• 99.9% uptime requirement

Validator Security

Requirement	Purpose
HSM Key Storage	Signing keys never exposed to network
Sentry Node Architecture	Validator node not directly exposed
DDoS Protection	Resilient to network attacks
Geographic Distribution	No single point of failure
Minimum Stake	Economic commitment to honest behavior

Slashing Conditions

Validators face economic penalties for:

Violation	Penalty	Duration
Double Signing	5% stake slashed	Permanent jail
Extended Downtime	0.01% stake slashed	10 min jail
Governance Attack	Governance removal	Case-by-case

---

Audit Program

Audit Schedule

Audit	Timing	Scope	Status
Internal Review	Pre-testnet	All contracts	Planned
External Audit 1	Pre-mainnet	Full contract suite	Planned Q1 2026
External Audit 2	Post-mainnet	Upgrade verification	Planned Q2 2026
Continuous	Ongoing	Bug bounty	Launches with mainnet

Audit Scope

External audits will cover:

Smart Contracts:

• Exhibition contract (creation, metadata, status)

• License contract (issuance, validation, completion)

• Payment contract (distribution, fee calculation)

• Governance contract (proposals, voting, execution)

• Provenance contract (history, verification)

Chain Configuration:

• Genesis parameters

• Module configurations

• Upgrade mechanisms

• Emergency procedures

Operational Security:

• Multi-sig configurations

• Admin key management

• Deployment procedures

Auditor Selection Criteria

We select auditors based on:

• Cosmos/CosmWasm specialization

• Track record with high-value protocols

• Independence and reputation

• Comprehensive methodology

Target Auditors:

• Oak Security (Cosmos specialist)

• Halborn (blockchain security)

• Informal Systems (Cosmos core contributor)

Report Publication

All audit reports will be published in full, including:

• Findings by severity

• Remediation status

• Auditor recommendations

• Our responses

---

Bug Bounty Program

Rewards

Severity	Description	Reward
Critical	Direct loss of funds, consensus failure	Up to €50,000
High	Significant functionality impact, governance bypass	Up to €20,000
Medium	Limited impact, edge case exploits	Up to €5,000
Low	Minor issues, best practice violations	Up to €1,000

Scope

In Scope:

• All deployed smart contracts

• Chain consensus mechanism

• Governance system

• Payment distribution

• Access control mechanisms

Out of Scope:

• Frontend applications (separate program)

• Third-party integrations

• Social engineering attacks

• Already-reported issues

Responsible Disclosure

1

Report via email

Report via [email protected]

2

Include reproduction details

Include detailed reproduction steps

3

Remediation window

Allow 90 days for remediation before public disclosure

4

Coordinate disclosure

Coordinate disclosure timing with our team

---

Operational Security

Multi-Signature Administration

All privileged operations require multiple approvals:

Operation	Signers Required	Total Signers
Contract Upgrade	3 of 5	5
Treasury Transfer	3 of 5	5
Emergency Pause	2 of 5	5
Parameter Change	3 of 5	5

Signer Distribution:

• Signers in different geographic locations

• Different security setups (hardware wallets, HSMs)

• No single organization controls majority

• Regular key rotation schedule

Key Management

┌─────────────────────────────────────────────────────────────────┐
│                    KEY HIERARCHY                                │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Root Keys (Cold Storage)                                │   │
│  │  • Never connected to network                            │   │
│  │  • Used only for emergency recovery                      │   │
│  │  • Geographically distributed custody                    │   │
│  └─────────────────────────────────────────────────────────┘   │
│                              │                                  │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Admin Keys (HSM)                                        │   │
│  │  • Hardware security modules                             │   │
│  │  • Multi-sig required for use                            │   │
│  │  • Audit trail for all operations                        │   │
│  └─────────────────────────────────────────────────────────┘   │
│                              │                                  │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Operational Keys (Hot)                                  │   │
│  │  • Limited permissions                                   │   │
│  │  • Rate-limited operations                               │   │
│  │  • Automated monitoring                                  │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Emergency Procedures

Circuit Breakers:

• Automatic pause on anomaly detection

• Manual pause capability (2-of-5 multi-sig)

• Graduated response levels

Incident Response

1

Detection

Automated monitoring + manual reports

2

Assessment

Severity classification

3

Containment

Pause affected systems if necessary

4

Remediation

Fix deployment

5

Communication

Stakeholder notification

6

Post-mortem

Public report

---

Content Security

IPFS Integrity

Exhibition content is stored on IPFS with on-chain hash verification:

pub struct Exhibition {
    // ... other fields
    
    /// SHA-256 hash of primary content - immutable after creation
    pub content_hash: String,
    
    /// IPFS URI for content retrieval
    pub metadata_uri: String,
}

// Verification function
pub fn verify_content(
    exhibition: &Exhibition,
    provided_hash: &str,
) -> bool {
    exhibition.content_hash == provided_hash
}

Guarantees:

• Content hash set at creation, never modified

• Anyone can verify content matches on-chain record

• Tampering is detectable and provable

Content Availability

• Multiple IPFS pinning services

• Foundation-operated pinning infrastructure

• Incentivized community pinning (planned)

• Content mirroring across geographic regions

---

Threat Model

Addressed Threats

Threat	Mitigation
Smart contract exploit	Rust memory safety, audits, bug bounty
Validator collusion	BFT consensus, stake slashing, distribution requirements
Admin key compromise	Multi-sig, HSM, key rotation
DDoS attack	Sentry architecture, geographic distribution
Long-range attack	21-day unbonding period
Content tampering	On-chain hash verification
Governance attack	Constitutional protections, council structure

Accepted Risks

Risk	Acceptance Rationale
Rust/CosmWasm zero-day	Industry-standard stack, active development
Cosmos SDK vulnerability	Battle-tested across ecosystem
Catastrophic validator failure (>⅔)	Extremely unlikely with proper distribution

---

Transparency Commitments

We Will Publish

• All smart contract source code

• All audit reports (unredacted)

• Security incident post-mortems

• Regular security status updates

• Bug bounty statistics

We Will Not

• Rely on security through obscurity

• Hide vulnerabilities after remediation

• Delay disclosure beyond responsible timeline

• Downplay security incidents

---

Security Contacts

Report Vulnerabilities: [email protected]

PGP Key: Available at nonterritorial.network/security/pgp

Response Time:

• Critical: < 4 hours

• High: < 24 hours

• Medium/Low: < 72 hours

---

Security | Nonterritorial Network Sovereign Infrastructure for Autonomous Art Circulation