Order System
Order System (Off-Chain Order Layer)
The Signex order system handles how trades are created, stored, discovered, and delivered between participants without storing funds on-chain. It acts as the coordination layer between users and the smart contract while keeping execution fully trustless.
Overview
Signex uses an off-chain signed order model. Trades are created and signed locally by users, then stored in a database so the intended counterparty can view and execute them.
The blockchain is only used when:
Executing swaps
Cancelling trades
Verifying signatures
Enforcing atomic settlement
This architecture reduces gas costs, improves speed, and enables real-time trade dashboards.
Order Creation Flow
1. Maker Creates Trade
The maker selects:
Counterparty wallet address
Token they are offering
Token they want to receive
Token amounts
Expiration time
The frontend then generates a structured trade object.
2. EIP-712 Signature
The trade is signed using EIP-712 typed structured signing.
This signature proves:
The maker intentionally created the trade
Trade parameters cannot be modified
The order can later be verified on-chain
Signing happens locally in the user wallet. No private keys or sensitive data leave the wallet.
3. Order Storage
After signing, the trade is stored in the Signex database (Supabase).
Stored data includes:
Trade parameters
Maker signature
Trade hash
Expiry timestamp
Trade status
Maker and taker wallet addresses
Supabase acts only as an indexing and delivery layer. It cannot execute trades or access user funds.
Order Discovery
Private Counterparty Delivery
Orders are not public marketplace listings.
Instead:
The order is indexed under the taker wallet address
When the taker connects their wallet, the system queries orders assigned to them
Orders appear instantly in the taker dashboard
This ensures true peer-to-peer trading and prevents public order sniping.
Trade Acceptance Flow
1. Taker Reviews Order
The taker can:
Accept trade
Ignore trade
Cancel trade (invalidate locally and on-chain)
2. Taker Signs Order
If accepted:
The taker signs the same EIP-712 trade structure
This produces a second signature confirming agreement
Now both participants have cryptographically approved the trade.
3. Atomic Execution
The frontend submits:
Trade parameters
Maker signature
Taker signature
To the smart contract.
The contract then:
Verifies both signatures
Validates nonce and expiry
Transfers tokens atomically
Emits trade event
Trade State Management
Each trade moves through defined states:
Pending
Signed by maker
Waiting for taker action
Accepted / Executed
Both parties signed
Swap completed on-chain
Cancelled
Maker or taker invalidated order
Expired
Expiry time passed
Cannot be executed
State is tracked both:
Off-chain (dashboard UX)
On-chain (nonce usage + expiry enforcement)
Signature Storage Security
Signatures stored in Supabase are safe because:
They do not grant spending permissions
They only prove trade intent
They cannot move funds without blockchain execution
Security protections include:
Row-level access control
Wallet-based query filtering
Immutable trade hashing
Status locking after execution
Even if database data were modified, the smart contract would reject invalid trades because signatures must match the original parameters.
Replay Protection
Each trade contains a unique nonce.
When a trade executes or cancels:
The contract marks the nonce as used
Any future attempt to reuse that trade automatically fails
This prevents:
Duplicate execution
Signature replay attacks
Order reuse exploits
Expiry Handling
Each trade contains an expiration timestamp defined during creation.
Expiry is enforced in two layers:
On-Chain
Contract rejects execution after expiry
Off-Chain
Expired trades are hidden from dashboards
Periodic cleanup removes outdated entries
This prevents stale trades from being executed.
Real-Time Order Updates
Signex uses live database listeners to update dashboards instantly.
This enables:
Near real-time order appearance
Immediate status updates
Responsive trade tracking
Users do not need to refresh or rescan blockchain activity manually.
Why Off-Chain Orders Are Used
The off-chain order model provides several benefits:
Eliminates gas cost for order creation
Enables fast UI interaction
Allows private P2P trade routing
Reduces blockchain storage overhead
Improves scalability
The blockchain remains responsible only for settlement and enforcement.
Trust Model
The order system assumes:
Database can fail or go offline
Frontend may malfunction
Orders may be deleted or altered off-chain
Even under these conditions:
Funds remain safe
Trades cannot execute without valid signatures
Smart contract enforces final truth
Future Order System Expansion
Planned improvements may include:
Cross-chain order routing
Multi-asset bundle trades
Encrypted order sharing
Advanced trade matching logic
Decentralized order relayers
Last updated