OpenFiat Network Security Protocol (ONSP)
The OpenFiat Network Security Protocol (ONSP) defines the security architecture governing communication between OpenFiat nodes.
Abstract
The OpenFiat Network Security Protocol (ONSP) defines the security architecture governing communication between OpenFiat nodes.
The protocol establishes how nodes authenticate one another, protect message integrity and confidentiality, resist network-based attacks, detect malicious peers, and maintain a resilient decentralized marketplace without trusted intermediaries.
Unlike wallet security, which protects user assets, the Network Security Protocol protects the integrity, availability, and authenticity of the OpenFiat network itself.
1. Introduction
OpenFiat is an open, permissionless network where any participant may operate a node.
As a result, nodes must assume that peers may be:
- Malicious
- Misconfigured
- Compromised
- Unavailable
- Outdated
- Sybil identities
The protocol therefore adopts a zero-trust networking model.
Every connection is independently authenticated, validated, monitored, and continuously evaluated.
2. Scope
This specification defines:
- Node identity
- Peer authentication
- Secure transport
- Message authentication
- Replay protection
- Rate limiting
- DoS resistance
- Sybil mitigation
- Peer reputation
- Key rotation
- Secure protocol negotiation
- Network abuse handling
It does not define:
- Wallet cryptography
- User identity
- Transaction signatures
- Stablecoin custody
3. Security Goals
The network SHALL provide:
- Authentication
- Confidentiality
- Integrity
- Availability
- Forward secrecy
- Replay protection
- Downgrade resistance
- Fault tolerance
4. Security Model
The protocol assumes:
- Every network is hostile.
- Every peer is initially untrusted.
- Trust is earned through observed behavior.
- No node possesses inherent authority over others.
5. Node Identity
Each node SHALL possess a long-lived cryptographic identity.
A node identity consists of:
- Public key
- Private key
- Node identifier
- Supported protocol versions
- Advertised capabilities
Private keys MUST never be transmitted across the network.
6. Secure Transport
Node-to-node communication SHALL occur over encrypted channels.
Transport implementations SHOULD provide:
- Mutual authentication
- Encryption in transit
- Integrity verification
- Forward secrecy
Alternative transport implementations MAY be adopted provided they satisfy these guarantees.
7. Peer Authentication
Before exchanging protocol data, peers SHALL:
- Establish a secure transport.
- Exchange node identities.
- Verify protocol compatibility.
- Validate cryptographic ownership.
- Confirm supported capabilities.
Unauthenticated peers MUST NOT participate in protocol synchronization.
8. Message Authentication
Every protocol message SHALL include:
- Message identifier
- Sender identifier
- Timestamp
- Sequence number
- Digital signature
Nodes MUST verify message authenticity before processing.
9. Replay Protection
Replay attacks are prevented through:
- Monotonic sequence numbers
- Message timestamps
- Session identifiers
- Expiration windows
Duplicate or expired messages MUST be discarded.
10. Protocol Negotiation
Peers SHALL negotiate:
- Protocol version
- Feature flags
- Serialization format
- Compression support
- Optional capabilities
If negotiation fails, the connection SHALL terminate gracefully.
11. Rate Limiting
Nodes SHOULD enforce independent limits for:
- Connection attempts
- Peer discovery requests
- Gossip messages
- Snapshot requests
- RPC requests
- Service announcements
Limits MAY adapt according to peer reputation.
12. Denial-of-Service Protection
Implementations SHOULD defend against:
- Connection flooding
- Message flooding
- Invalid protocol frames
- Oversized payloads
- Resource exhaustion
- Slow-client attacks
Suspicious peers MAY be temporarily isolated.
13. Sybil Resistance
OpenFiat is permissionless; therefore Sybil attacks cannot be eliminated entirely.
Mitigations include:
- Peer reputation
- Stake-weighted QoS
- Connection diversity
- Geographic diversity
- Behavior-based scoring
- Adaptive peer selection
14. Peer Reputation
Security decisions MAY incorporate the Reputation Engine.
Signals include:
- Invalid messages
- Frequent disconnects
- Failed verification
- Spam behavior
- Synchronization reliability
- Historical uptime
Nodes SHOULD prefer well-behaved peers.
15. Key Rotation
Node operators SHOULD periodically rotate identity keys.
Rotation SHALL preserve continuity through a signed transition linking the previous and new identities.
Unauthorized key replacement MUST be rejected.
16. Abuse Handling
Nodes MAY respond to abusive behavior by:
- Ignoring requests
- Throttling traffic
- Temporary bans
- Permanent bans
- Reducing reputation
- Reporting abuse through network telemetry
17. Security Logging
Nodes SHOULD maintain tamper-evident logs for:
- Authentication failures
- Replay attempts
- Invalid signatures
- Protocol violations
- Rate-limit events
- Synchronization failures
Logs SHOULD avoid exposing sensitive information.
18. Incident Recovery
Following a suspected compromise, operators SHOULD:
- Revoke compromised keys.
- Generate new node identities.
- Re-synchronize state.
- Notify peers where appropriate.
- Review audit logs.
19. Future Cryptography
Future protocol versions MAY introduce:
- Post-quantum key exchange
- Post-quantum signatures
- Hardware-backed key storage
- Threshold authentication
- Anonymous network identities
These extensions MUST remain backward compatible whenever practical.
20. Conformance
A compliant implementation MUST:
- Authenticate peers.
- Encrypt network communications.
- Verify message signatures.
- Prevent replay attacks.
- Support protocol negotiation.
- Detect malformed messages.
- Implement rate limiting.
- Recover safely from malicious peers.
21. Relationship to Other Specifications
22. Summary
The OpenFiat Network Security Protocol establishes the security foundation of the OpenFiat network by defining how nodes authenticate, communicate securely, resist abuse, and maintain trustworthy peer-to-peer interactions.
By standardizing secure transport, peer authentication, message integrity, replay protection, denial-of-service mitigation, and adaptive trust mechanisms, the protocol enables independent implementations to participate safely in a decentralized global marketplace.
The OpenFiat Network Security Protocol answers one fundamental question:
"How can untrusted OpenFiat nodes communicate securely while preserving the integrity, availability, and resilience of the decentralized network?"