This document describes the security mechanisms implemented in Stateset Core to protect against common attack vectors and ensure the safety of user funds.
- Circuit Breaker System
- Rate Limiting
- Oracle Security
- Liquidation Protection
- Compliance Integration
- Access Control
- Emergency Procedures
- Threat Model
The system includes a global pause mechanism that can halt all operations in case of emergency.
Features:
- Instant activation by authorized parties
- Optional auto-resume after specified duration
- Maximum pause duration limit (default: 24 hours)
- Full audit trail with timestamps and reasons
Usage:
# Pause system
statesetd tx circuit pause-system \
--reason "Security incident detected" \
--duration 3600 \
--from authority
# Resume system
statesetd tx circuit resume-system --from authorityEach module can have its circuit breaker tripped independently.
States:
CLOSED: Normal operationOPEN: Operations blockedHALF_OPEN: Recovery mode, limited operations
Automatic Tripping:
- Configurable failure threshold (default: 5 consecutive failures)
- Automatic reset after recovery period (default: 5 minutes)
- Specific message types can be disabled
Manual Control:
# Trip circuit for stablecoin module
statesetd tx circuit trip-circuit stablecoin \
--reason "Investigating anomaly" \
--disable-messages "/stateset.stablecoin.Msg/LiquidateVault" \
--from authority
# Reset circuit
statesetd tx circuit reset-circuit stablecoin --from authorityConfigurable rate limits per address to prevent spam and abuse.
Default Limits:
| Operation | Max Requests | Window |
|---|---|---|
| All transactions | 100 | 60s |
| Stablecoin mints | 10 | 60s |
| Large settlements | 5 | 300s |
System-wide rate limits to prevent network saturation.
Default: 1000 transactions per 60 seconds
Rate limits can be applied to specific message types:
{
"name": "mint_limit",
"max_requests": 10,
"window_seconds": 60,
"per_address": true,
"message_types": ["/stateset.stablecoin.Msg/MintStablecoin"]
}Prevents oracle manipulation by limiting price changes per update.
Configuration:
{
"denom": "uatom",
"max_deviation_bps": 500, // 5% max per update
"staleness_threshold_seconds": 3600,
"min_update_interval_seconds": 60
}Protection Mechanisms:
- Deviation Limits: Rejects price updates that deviate more than configured threshold
- Update Frequency: Prevents rapid-fire price updates
- Staleness Checks: Operations fail if price is older than threshold
Support for multiple oracle providers with weighted voting:
Provider Features:
- Registration with governance approval
- Success rate tracking
- Automatic slashing for poor performance
- Manual slashing for malicious behavior
Slashing Criteria:
- Success rate below 50% after 10+ submissions
- Manual slash by governance for detected manipulation
Maintains historical price data for:
- Audit trails
- Anomaly detection
- TWAP calculations (future)
Prevents liquidation cascades that could destabilize the system.
Limits:
- Maximum liquidations per block: 10
- Maximum liquidation value per block: 1,000,000 units
- Cooldown blocks after hitting limits: 5
- Vault health check (collateral ratio)
- Surge protection check
- Liquidator pays outstanding debt
- Collateral transferred to liquidator
- Liquidation recorded for analytics
| Parameter | Value | Purpose |
|---|---|---|
| Liquidation Ratio | 150% | Minimum collateral before liquidation |
| Stability Fee | 2% annual | Cost of maintaining debt |
| Liquidation Penalty | 10% | Incentive for liquidators |
All addresses must have a compliance profile for certain operations.
KYC Levels:
NONE: No verification, limited operationsBASIC: Basic identity verification, standard limitsSTANDARD: Full verification, higher limitsENHANCED: Enhanced due diligence, highest limits
Profile Status:
PENDING: Awaiting verificationACTIVE: Fully operationalSUSPENDED: Temporarily blockedREJECTED: Verification failedEXPIRED: Needs renewal
Risk Levels:
LOW: Standard monitoringMEDIUM: Enhanced monitoringHIGH: Enhanced due diligence required
High-Risk Indicators:
- Location in high-risk jurisdiction (AF, BY, MM, VE, YE)
- Business type flagged for enhanced scrutiny
- Transaction patterns triggering alerts
Blocked Jurisdictions:
- KP (North Korea)
- IR (Iran)
- SY (Syria)
- CU (Cuba)
- RU (Russia)
High-Risk Jurisdictions: Require enhanced KYC for transactions exceeding thresholds.
Daily and monthly limits based on KYC level:
| KYC Level | Daily Limit | Monthly Limit |
|---|---|---|
| NONE | $1,000 | $5,000 |
| BASIC | $10,000 | $50,000 |
| STANDARD | $100,000 | $500,000 |
| ENHANCED | Unlimited | Unlimited |
Limits are automatically reset:
- Daily: Every 24 hours from last reset
- Monthly: First transaction of new month
Operations checked against compliance:
- Settlement instant transfers
- Escrow creation
- Batch settlements
- Payment channel operations
- Vault creation
Sanctioned addresses are blocked from:
- All stablecoin operations
- Settlement operations
- Payment channel participation
All profile changes are logged:
- Timestamp
- Actor (who made the change)
- Action type
- Old status → New status
- Reason (if provided)
Maximum 100 audit entries retained per profile.
Module Authorities:
- Oracle: Can update prices, manage providers
- Settlement: Can settle batches
- Circuit: Can pause/resume system
- Compliance: Can manage profiles
Vault operations require owner verification:
- Deposit collateral
- Withdraw collateral
- Mint stablecoin
- Repay debt
Certain operations are intentionally permissionless:
- Vault liquidation (incentivized by profit)
- Escrow release (by sender only)
- Channel claims (by recipient with valid nonce)
| Level | Response | Authority |
|---|---|---|
| Low | Monitor | Operations team |
| Medium | Trip affected module | Security team |
| High | Pause affected modules | Governance |
| Critical | Global pause | Emergency multisig |
-
Detection
- Monitor alerts trigger
- Community reports
- Audit findings
-
Assessment
- Determine severity
- Identify affected modules
- Estimate impact
-
Containment
- Trip relevant circuits
- Pause if critical
- Disable specific messages
-
Resolution
- Deploy fix
- Test in staging
- Governance approval
-
Recovery
- Reset circuits
- Resume operations
- Post-mortem analysis
Emergency multisig requires 3-of-5 signatures for:
- Global pause activation
- Emergency parameter changes
- Emergency upgrades
Threat: Attacker controls oracle and sets manipulated prices
Mitigations:
- Price deviation limits
- Multi-provider system
- Provider slashing
- Price history tracking
Threat: Mass liquidations destabilize system
Mitigations:
- Per-block liquidation limits
- Value-based limits
- Cooldown periods
Threat: Spam transactions overwhelm network
Mitigations:
- Gas-based costs
- Rate limiting (per-address and global)
- Circuit breakers
Threat: Reusing signed messages
Mitigations:
- Nonce-based payment channels
- Sequence numbers in transactions
- Unique settlement IDs
Threat: Borrowing large amounts to manipulate state
Mitigations:
- Block-scoped operations
- Atomic transaction validation
- Compliance checks
Threat: Malicious authority abuse
Mitigations:
- Governance oversight
- Action logging
- Multi-sig requirements
- Time-locked operations
- All tests passing
- Test coverage > 80%
- Static analysis clean
- Dependencies audited
- Documentation complete
-
Smart Contract Logic
- Stablecoin vault mechanics
- Liquidation logic
- Settlement flows
-
Oracle System
- Price validation
- Provider management
- Staleness handling
-
Access Control
- Authority checks
- Owner validation
- Compliance integration
-
Economic Security
- Incentive alignment
- Attack profitability
- Edge cases
- Address all critical findings
- Address all high findings
- Document accepted risks
- Implement monitoring
- Update documentation
-
System Health
- Circuit breaker states
- Rate limit hits
- Error rates
-
Oracle Health
- Price freshness
- Deviation alerts
- Provider performance
-
Economic Health
- Total collateral
- Total debt
- Collateralization ratios
- Liquidation volume
-
Security Events
- Failed authorization attempts
- Compliance blocks
- Unusual patterns
| Metric | Warning | Critical |
|---|---|---|
| Rate limit hits | 50% capacity | 80% capacity |
| Price staleness | 30 min | 1 hour |
| Liquidation volume | 500k/hour | 1M/hour |
| Circuit trips | Any automatic | Multiple |
CosmWasm integration is currently disabled pending a compatible wasmd release for Cosmos SDK v0.53.x.
Reason: The wasmd module does not yet have a stable release compatible with Cosmos SDK v0.53.4. Development is underway (see PR #2319).
Once a compatible wasmd version is released:
- Update go.mod with compatible wasmd version
- Uncomment imports in app/app.go
- Re-enable wasm keeper initialization
- Run migration tests for any state changes
- Security audit of CosmWasm configuration
When re-enabled, the following security measures apply:
Contract Deployment:
- Governance-gated uploads (optional)
- Code pinning for frequently used contracts
- Gas limits for instantiation
Execution Safety:
- Gas metering prevents infinite loops
- Deterministic execution across all nodes
- Sandboxed WebAssembly environment
Access Control:
- Contract admin can migrate/update
- Governance can freeze contracts
- Circuit breakers apply to wasm module
| Version | Date | Changes |
|---|---|---|
| 1.0.0 | 2024-01 | Initial security architecture |
| 1.1.0 | 2024-03 | Added circuit breakers |
| 1.2.0 | 2024-06 | Enhanced oracle security |
| 2.0.0 | 2024-12 | Major security overhaul |
| 2.1.0 | 2025-12 | Added CosmWasm status section |
| 2.2.0 | 2025-12 | Enhanced compliance with KYC/AML workflow, jurisdiction controls, transaction limits, audit logging |
For security concerns, contact: security@stateset.network
For responsible disclosure, please encrypt communications using our PGP key.