Developer Architecture

21.1 Introduction#

OpenFiat is more than a decentralized marketplace.

It is an open protocol designed to enable an ecosystem of applications, infrastructure providers, integrations, and third-party services.

The protocol itself defines the rules.

The reference implementation demonstrates those rules.

Anyone may build compatible software without requesting permission.

From the beginning, OpenFiat has been designed around a familiar philosophy shared by many successful Internet protocols:

One protocol. Many implementations.

This ensures the long-term health of the ecosystem by preventing dependence on a single software vendor while encouraging innovation through open competition.

21.2 Design Principles#

The OpenFiat developer ecosystem follows several guiding principles.

Open Source First#

Every core protocol component is open source.

Reference, Not Monopoly#

The official implementation serves as a reference rather than the only implementation.

Stable Protocol#

Protocol specifications evolve carefully with backwards compatibility whenever practical.

Language Independence#

Developers should be free to build compatible implementations in any programming language.

Developer Experience#

Building on OpenFiat should be simple, well documented, and predictable.

Extensibility#

New services should integrate through published interfaces rather than private APIs.

21.3 Reference Architecture#

The OpenFiat ecosystem consists of several independent software components.

                    OpenFiat Protocol
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
   Solana Programs     P2P Network      Specifications
        │                  │                  │
        └──────────────────┼──────────────────┘
                           │
                 Reference Implementation
                           │
      ┌────────────┬────────────┬────────────┐
      │            │            │            │
 Rust Node     React Web   Mobile App   Desktop App
      │            │            │            │
      └────────────┴────────────┴────────────┘

Each component may evolve independently while remaining compatible through the published protocol specifications.

21.4 Official Reference Node#

The official OpenFiat node is written in Rust.

Rust was selected because it provides:

• Memory safety.
• Excellent performance.
• Modern concurrency.
• Cross-platform support.
• Strong cryptographic ecosystem.
• Native Solana compatibility.

The reference node is responsible for:

• Peer-to-peer networking.
• Gossip propagation.
• Marketplace synchronization.
• RocksDB storage.
• Snapshot generation.
• Peer discovery.
• Notification routing.
• Risk intelligence synchronization.
• Protocol APIs.

Although the reference node is written in Rust, the protocol itself is language independent.

21.5 Storage Engine#

The official reference node embeds RocksDB as its storage engine.

RocksDB was selected because it provides:

• High write throughput.
• Excellent read performance.
• Crash recovery.
• Efficient snapshots.
• Mature production usage.
• Proven scalability.

RocksDB stores replicated marketplace state including:

• Advertisements.
• Reputation vectors.
• Risk intelligence.
• Trade sessions.
• Peer metadata.
• Notification Gateway directory.
• Snapshot metadata.
• Local synchronization state.

Authoritative financial state always remains on Solana.

The protocol itself does not require alternative implementations to use RocksDB, provided they correctly implement the published storage semantics.

21.6 Client Applications#

The OpenFiat Foundation maintains several official client applications.

These include:

Web Application#

Built using React.

Runs in modern browsers.

May be self-hosted.

May also be distributed through decentralized hosting platforms such as IPFS.

Desktop Application#

Built using the same React codebase with a native desktop runtime.

Supports Windows.

macOS.

Linux.

Mobile Applications#

Native mobile applications for:

• Android.
• iOS.

These applications communicate with OpenFiat nodes using the published protocol.

21.7 Self-Hosted User Interfaces#

OpenFiat intentionally separates the protocol from its user interfaces.

Anyone may host:

• Web interfaces.
• Mobile gateways.
• Enterprise portals.
• Regional marketplaces.
• Organization-specific interfaces.

Examples include:

Regardless of which interface is used, every participant interacts with the same decentralized marketplace.

21.8 SDKs#

Official Software Development Kits (SDKs) simplify application development.

Initially planned SDKs include:

• Rust SDK.
• TypeScript SDK.
• JavaScript SDK.

Future community SDKs may include:

• Go.
• Python.
• Java.
• Kotlin.
• Swift.
• C#.

SDKs abstract common protocol operations while remaining faithful to the published specifications.

21.9 Public APIs#

Every OpenFiat node exposes standardized APIs.

Examples include:

Marketplace APIs

• Search advertisements.
• Create advertisements.
• Update advertisements.
• Remove advertisements.

Trading APIs

• Reserve advertisements.
• Synchronize trade sessions.
• Submit payment confirmations.

Infrastructure APIs

• Peer discovery.
• Gateway discovery.
• Snapshot information.
• Risk intelligence.

Governance APIs

• Proposal discovery.
• Vote submission.
• Treasury information.

These APIs are identical across all compliant implementations.

21.10 Event Streaming#

Applications often require real-time updates.

The reference node therefore exposes event streams for:

• Advertisement updates.
• Trade lifecycle events.
• Reputation updates.
• Governance changes.
• Notification events.
• Risk intelligence updates.

This enables responsive user interfaces without continuous polling.

21.11 Plugin Architecture#

Many protocol services are intentionally modular.

Examples include:

• Oracle Providers.
• Notification Gateways.
• Risk Intelligence Providers.
• Snapshot Providers.

Each service integrates through a published interface.

Future protocol extensions can introduce additional provider types without modifying the core architecture.

21.12 Development Workflow#

The OpenFiat Foundation maintains a transparent development process.

Typical workflow:

Major architectural changes should be publicly discussed before implementation.

21.13 Testing Strategy#

OpenFiat adopts multiple layers of automated testing.

These include:

Unit Tests

Individual component correctness.

Integration Tests

Interaction between protocol components.

Network Tests

Peer-to-peer synchronization.

Smart Contract Tests

Escrow and settlement correctness.

Performance Tests

High-volume marketplace activity.

Regression Tests

Protection against previously fixed issues.

Continuous testing helps maintain protocol stability across releases.

21.14 Documentation#

Documentation is considered part of the protocol.

Official documentation includes:

• Protocol Specification.
• Whitepaper.
• Developer Guides.
• API Reference.
• SDK Documentation.
• Example Applications.
• Infrastructure Guides.
• Governance Documentation.

Every protocol feature should be documented before public release.

21.15 Versioning#

OpenFiat follows semantic versioning principles.

Examples:

Major versions

Breaking protocol changes.

Minor versions

Backward-compatible features.

Patch versions

Bug fixes and implementation improvements.

Nodes advertise supported protocol versions during peer discovery.

21.16 Open Governance for Development#

Although AllenHark initially leads development, protocol evolution is governed through the OpenFiat Governance Protocol.

Community members may:

• Submit proposals.
• Review specifications.
• Contribute code.
• Improve documentation.
• Build independent implementations.

The protocol belongs to its community rather than a single organization.

21.17 Community Contributions#

The OpenFiat ecosystem welcomes contributions from developers worldwide.

Examples include:

• Bug fixes.
• Documentation improvements.
• SDK development.
• Client applications.
• Infrastructure software.
• Testing tools.
• Security research.
• Educational resources.

Contributions strengthen the ecosystem while reducing dependence on any single team.

21.18 Reference vs Independent Implementations#

The OpenFiat Foundation maintains the official Rust reference implementation.

Independent developers remain free to build alternative implementations.

Examples include:

• Lightweight embedded nodes.
• Enterprise gateway software.
• Academic research implementations.
• Specialized infrastructure services.
• Custom client applications.

Compliance is determined by adherence to the protocol specification rather than the programming language or internal architecture.

21.19 Why This Architecture Matters#

Many blockchain projects tightly couple their protocol with a single software implementation.

OpenFiat intentionally separates these concerns.

The protocol defines the rules.

The reference implementation demonstrates those rules.

Independent implementations expand the ecosystem.

This approach encourages innovation while preserving interoperability.

21.20 Looking Ahead#

With the protocol, infrastructure, security model, and developer ecosystem established, the remaining chapters focus on operating OpenFiat in production.

The next chapter introduces Deployment & Operations, covering production environments, bootstrap infrastructure, monitoring, upgrades, disaster recovery, release management, and best practices for running reliable OpenFiat services at global scale.