Security Model

The Nector protocol is designed to operate in a trust-minimized environment, where participants may act dishonestly and no central authority exists to resolve disputes.

Instead of relying on verification of real-world events, Nector enforces security through:

  • Deterministic state transitions
  • Time-based constraints
  • Economic penalties

Threat Model

The primary adversaries in the system are:

  • Buyers attempting to obtain goods without paying
  • Sellers attempting to receive payment without delivering

The protocol does not assume honest behavior from either party.

Constraints

Attackers are limited by:

  • Strict state machine enforcement
  • Time-based execution rules
  • On-chain validation of all transitions

Unauthorized actions, invalid state transitions, or early timeout triggers are rejected at the contract level.

Trust Assumptions

The protocol makes minimal assumptions:

  • block.timestamp is reasonably accurate
  • Users understand and accept risk warnings before funding
  • The underlying blockchain (Solana) is secure

There is:

  • No admin key
  • No upgrade authority (if deployed as immutable)
  • No privileged access to escrow funds

Non-Custodial Design

All funds are stored in program-derived escrow accounts (PDAs).

Properties:

  • No private key controls the escrow
  • Funds can only move via program instructions
  • Configure environment variables
  • The platform cannot arbitrarily withdraw funds

This ensures:

The protocol is non-custodial by design.

Buyer Fraud

Scenario:

Buyer receives the item but falsely claims non-delivery and escalates to dispute.

Outcome:

  • If the dispute reaches draw = buyer loses bond + payment
  • If seller does not respond = buyer wins but seller is penalized

Analysis:

Attempting to cheat introduces financial risk.

The buyer cannot guarantee profit from dishonest behavior.

Seller Fraud

Scenario:

Seller marks item as shipped without actually delivering.

Outcome:

  • Buyer can open dispute
  • If unresolved → draw → seller loses bond

Analysis:

False shipment claims are economically discouraged.

Collusion Attack

Scenario:

Buyer and seller collude to manipulate the system (e.g., fake orders → force draw).

Outcome:

  • Both parties lose funds in draw
  • Platform may gain (depending on configuration)

Analysis:

Collusion is self-destructive and does not yield profit.

Timeout Attack

Scenario:

A participant refuses to act (e.g., does nothing to delay outcome).

Outcome:

  • Seller inactivity = buyer win + penalty
  • Buyer inactivity = seller gets paid
  • Both inactive → draw → both lose

Analysis:

Inaction is always penalized.

Keeper / Bot Risk

The protocol relies on external actors to trigger timeouts.

Risk:

  • If no one triggers = order remains in current state

Mitigation:

  • Permissionless execution (anyone can trigger)
  • Open-source keeper bots
  • Incentive for third-party automation

Reality Check:

  • Liveness depends on off-chain actors.

Smart Contract Attack Surface

The contract’s attack surface includes:

1. State Transition Validation

Incorrect state checks could allow:

  • Skipping phases
  • Triggering unauthorized payouts

Mitigation:

  • Strict state matching in every instruction

2. Lamport Manipulation

Direct lamport transfers (try_borrow_mut_lamports) must ensure:

  • No underflow / overflow
  • No double-spend via reentrancy-like patterns

Mitigation:

  • Solana runtime prevents reentrancy
  • Explicit balance accounting required

3. PDA Integrity

Incorrect seeds or account substitution could allow:

  • Escrow hijacking
  • Unauthorized fund movement

Mitigation:

  • Deterministic PDA derivation
  • Anchor account constraints

4. Missing Field Separation (Critical)

The contract currently overwrites bond_lamports.

Risk:

  • Loss of distinction between buyer and seller bond
  • Incorrect payout logic in edge cases

5. Time Validation

Reliance on block.timestamp introduces:

  • Minor manipulation risk by validators

However:

  • Impact is limited to small timing shifts
  • Does not enable economic exploits

Economic Security

The protocol is secured primarily through economic design.

Core Principle

Dishonest behavior must be less profitable than honest behavior. Current Reality (Brutal Truth)

Conclusion

The system reduces fraud, but does not eliminate all profitable attack scenarios.

Griefing Attacks

Attackers may attempt to:

  • Force disputes
  • Waste counterparty time
  • Trigger draw intentionally

Outcome:

  • Attacker incurs financial loss
  • No asymmetric gain

Platform Incentives

The platform receives:

  • Transaction fees
  • Penalties

Critical Observation

Even though:

  • Platform cannot open disputes
  • Platform cannot respond

It still benefits from:

Disputes resolving as draw

Security Philosophy

Nector does not attempt to determine truth.

Instead, it enforces the following rule:

Every participant must commit capital, and failure to resolve conflicts results in loss.