DocsCurrent Page

Security Model


DexBotics employs multiple layers of security to protect users, robots, and the protocol.


Program Security


Time-Locked Upgrades


All program upgrades go through a time-lock:


  • Beta phase: 48-hour delay
  • Production: 7-day delay
  • Emergency: Guardian can pause (but not upgrade)

Process:

1. Proposal submitted on-chain

2. Time-lock period begins

3. Community review & discussion

4. Automatic execution after delay


Guardian Pause


A multi-sig guardian can pause the protocol in emergencies:


Triggers:
  • Exploit detected
  • Oracle network compromise
  • Smart contract bug

Limitations:
  • Cannot steal funds
  • Cannot upgrade programs
  • 7-day maximum pause duration
  • Requires 3-of-5 signatures

Guardian Members:
  • 2 team members
  • 3 community representatives

Rate Limits


Critical operations have rate limits:


| Operation | Limit | Window |

|-----------|-------|--------|

| Task creation | 100 | per address per day |

| Oracle attestation | 1,000 | per oracle per day |

| Dispute opening | 10 | per address per week |


Purpose:
  • Prevent spam attacks
  • Limit sybil exploitation
  • Protect network resources

Escrow Safety


Funds are protected through:


1. PDA Escrow Accounts
  • No private key exists
  • Only program can release
  • Deterministic derivation

2. Multi-Signature Settlement
  • Requires oracle quorum
  • Time-locked dispute window
  • Evidence-based arbitration

3. Collateral Requirements
  • Robot posts collateral
  • Slashed for failed tasks
  • Returned on success

Oracle Security


Stake Requirements


Minimum stake prevents sybil attacks:


  • Entry barrier: 1,000 $DEXB (~$1,000)
  • Economic security: Slashing > potential gain
  • Reputation weight: Long-term alignment

Diversity Requirements


No single oracle type can constitute >50% of votes:


if (geofence_votes > total_votes * 0.5) {
  reject_geofence_only_consensus();
}

Forces multi-type attestation for robustness.


Collusion Detection


On-chain analysis flags suspicious patterns:


  • Consistent minority voting
  • Coordinated timing
  • Identical vote sequences

Penalty: Investigation + temporary suspension

Robot Registry Security


NFT-Based Identity


Each robot has a unique NFT with:


  • Firmware hash (immutable)
  • Capabilities manifest
  • Owner signature
  • Reputation history

Benefits:
  • Prevents impersonation
  • Enables reputation tracking
  • Allows revocation

Firmware Attestation


Robots must prove firmware integrity:


rust 
pub fn verify_firmware(
    expected_hash: [u8; 32],
    provided_signature: [u8; 64],
    robot_pubkey: Pubkey,
) -> bool

Process:

1. Robot computes firmware SHA-256

2. Signs hash with private key

3. Program verifies signature

4. Match against registry


Audit Status


Current Status: Pre-audit (Beta)
Planned Audits:
  • [ ] Anchor programs (Q1 2026)
  • [ ] TypeScript SDK (Q1 2026)
  • [ ] Bridge daemon (Q2 2026)
  • [ ] Oracle network (Q2 2026)

Audit Partners:
  • TBD: Tier-1 smart contract auditor
  • TBD: Robotics security specialist

Bug Bounty:
  • Launch after initial audit
  • $10,000 - $100,000 rewards
  • Immunefi platform

Best Practices


For Task Creators


  • Start with small amounts
  • Test on devnet first
  • Use detailed requirements CIDs
  • Monitor oracle attestations

For Robots


  • Keep private keys secure
  • Use hardware security modules
  • Regular firmware updates
  • Monitor for anomalies

For Oracles


  • Run nodes with high uptime
  • Verify evidence thoroughly
  • Maintain stake buffer
  • Report suspicious activity

Incident Response


Severity Levels:
Critical (P0):
  • Funds at risk
  • Guardian pause activated
  • 24/7 response team

High (P1):
  • Oracle compromise
  • Exploit disclosed
  • Emergency patch within 48h

Medium (P2):
  • Non-critical bug
  • Performance degradation
  • Patch within 1 week

Low (P3):
  • Minor issues
  • Scheduled maintenance
  • Patch in next release