The Notification Gateway Network

19.1 Introduction#

OpenFiat is designed to operate without centralized infrastructure.

However, participants still need timely notifications during active trades.

A trader waiting for payment should know immediately when the counterparty reserves an advertisement.

A merchant should be notified when a new order is created.

A buyer should know when the merchant has released escrow.

An arbitrator should receive updates regarding disputes they have voluntarily joined.

A node operator may wish to receive infrastructure alerts.

Rather than requiring AllenHark or any single organization to permanently operate these services, OpenFiat introduces the Notification Gateway Network.

The Notification Gateway Network is a decentralized marketplace of independent infrastructure providers responsible for delivering optional notifications on behalf of OpenFiat users.

A Notification Gateway is any service that implements the OpenFiat Notification Gateway Specification.

The protocol does not define how notifications are delivered.

It only defines a standardized interface through which notification requests are accepted, processed, and acknowledged.

This allows anyone—from a global cloud provider to an individual operating a Raspberry Pi with a GSM modem—to participate in the ecosystem.

Notifications are therefore an optional infrastructure layer built on top of OpenFiat rather than a dependency of the protocol itself.

19.2 Design Objectives#

The Notification Gateway Network is designed around several principles.

Optional#

The OpenFiat protocol functions perfectly without notifications.

Participants who prefer not to receive notifications simply do not register a gateway.

Decentralized#

Anyone meeting the protocol requirements may operate a Notification Gateway.

Provider Choice#

Users decide which gateway operator they trust.

Privacy#

Gateway operators receive only the minimum information necessary to deliver notifications.

Open Standards#

The protocol defines interfaces rather than vendors.

Economic Sustainability#

Gateway operators receive protocol compensation for successful delivery services.

Vendor Independence#

AllenHark competes alongside every other gateway operator under identical protocol rules.

19.3 Why Notification Gateways?#

Traditional exchanges operate centralized notification infrastructure.

Every email, SMS, or push notification depends upon servers owned by the exchange.

This creates several disadvantages.

• Single points of failure.
• Vendor lock-in.
• Limited innovation.
• Privacy concerns.
• Concentrated operational costs.

OpenFiat decentralizes this responsibility.

Instead of one organization delivering every notification, a competitive marketplace of gateway operators emerges.

Participants remain free to:

• Operate their own gateway.
• Select any public gateway.
• Change providers at any time.
• Register multiple gateways.
• Disable notifications entirely.

19.4 Gateway Abstraction#

The OpenFiat protocol intentionally separates notification events from notification transport.

The protocol produces notification events.

Gateway operators determine how those events reach the recipient.

For example, identical protocol events may be delivered through:

• Email
• Telegram
• Discord
• SMS
• Mobile Push Notifications
• Browser Push Notifications
• Signal
• Matrix
• Slack
• Microsoft Teams
• Enterprise Webhooks
• Nostr
• Future communication platforms
• Custom local messaging systems

The protocol treats every gateway equally provided it implements the published Notification Gateway Specification.

This abstraction ensures that OpenFiat remains compatible with future communication technologies without requiring protocol changes.

19.5 Supported Communication Channels#

The following channels illustrate the flexibility of the gateway network.

Email#

Traditional SMTP or cloud email providers.

Telegram#

Telegram Bots.

Discord#

Direct Messages or dedicated channels.

SMS#

Commercial SMS providers or locally operated GSM gateways.

Mobile Push#

Firebase Cloud Messaging.

Apple Push Notification Service.

Other push providers.

Browser Push#

Modern web browsers supporting push notifications.

Enterprise Integrations#

Slack.

Microsoft Teams.

Internal corporate messaging systems.

Webhooks#

Custom integrations for third-party applications.

Future Channels#

Any communication platform may participate by implementing the Notification Gateway Specification.

The protocol itself remains transport-agnostic.

19.6 Gateway Registration#

Notification Gateway Operators announce themselves to the OpenFiat network.

Registration metadata includes:

• Gateway public key.
• Supported communication channels.
• Protocol version.
• Pricing information.
• Geographic regions (optional).
• Service capabilities.
• Software version.
• Public endpoints.

This metadata is propagated throughout the OpenFiat network using the gossip protocol.

Applications may present available gateways to users during wallet setup.

19.7 User Registration#

Participants choosing notifications register one or more communication endpoints.

Examples include:

• Verified email address.
• Verified Telegram account.
• Verified Discord account.
• Verified mobile push token.
• Verified phone number.

Every communication endpoint must be cryptographically linked to the participant's wallet.

Verification occurs using one-time authentication challenges.

Examples include:

• Email One-Time Password (OTP).
• Telegram bot verification.
• Discord account verification.
• SMS verification code.
• Push notification confirmation.

This prevents unauthorized registration of communication channels.

19.8 Selecting Notification Gateways#

Every wallet may choose one or more gateway operators.

For example:

Wallet

Preferred Gateway

Telegram

Trade Notifications

Changing gateways never affects:

• Wallet ownership.
• Trade history.
• Reputation.
• Escrow.
• Active advertisements.

Gateway selection remains entirely under user control.

19.9 Standard Notification Gateway Interface#

Every Notification Gateway implements the same standardized protocol interface.

The OpenFiat protocol creates notification events.

The gateway receives those events and performs delivery using its chosen communication technology.

Conceptually:

Notification Event

Gateway API

Delivery System

Recipient

Delivery Receipt

The protocol never needs to know whether delivery occurred through:

• SMTP
• Telegram
• Firebase
• Twilio
• A local GSM modem
• Another communication platform

Every compliant gateway behaves identically from the protocol's perspective.

This standardization allows gateways to compete while remaining completely interchangeable.

19.10 Multiple Gateway Configuration#

Participants may configure multiple gateways for redundancy.

Example:

Primary Gateway

Telegram

Fallback Gateway

Email

Emergency Gateway

SMS

If the preferred gateway fails to acknowledge delivery within a configurable timeout, another configured gateway may attempt delivery.

This improves reliability without introducing centralized infrastructure.

19.11 Notification Workflow#

Notification delivery follows a deterministic process.

Protocol Event

Notification Event Created

User Gateway Selected

Gateway Accepts Request

Notification Delivered

Delivery Receipt Returned

Notification Gateways never generate protocol events.

They only deliver events already created by the protocol.

19.12 Notification Events#

Examples include:

Marketplace#

• Advertisement reserved.
• Reservation expired.
• Trade cancelled.

Payments#

• Payment marked as sent.
• Payment confirmed.
• Escrow released.

Disputes#

• Dispute opened.
• Arbitration joined.
• Evidence requested.
• Voting completed.
• Dispute resolved.

Governance#

• Proposal published.
• Proposal approved.
• Governance vote reminder.

Infrastructure#

• Node registration completed.
• Snapshot available.
• Software update available.

Future protocol upgrades may introduce additional notification events.

19.13 Privacy Model#

Gateway operators receive only the minimum information necessary to perform delivery.

Typical information includes:

• Notification identifier.
• Destination address.
• Notification template.
• Timestamp.
• Delivery metadata.

Gateway operators should not receive unnecessary protocol information.

Examples include:

• Wallet balances.
• Private dispute evidence.
• Internal marketplace state.
• Unrelated participant information.

This minimizes privacy exposure while maintaining reliable delivery.

19.14 End-to-End Encryption#

Where technically possible, notification payloads should be encrypted.

Examples include:

• Encrypted gateway communication.
• Encrypted push notifications.
• Secure webhook delivery.
• TLS-encrypted communication channels.

Applications should clearly indicate the privacy guarantees offered by each gateway.

19.15 Gateway Reputation#

Every gateway accumulates a public reputation based upon objective protocol metrics.

Examples include:

• Delivery success rate.
• Delivery latency.
• Availability.
• Uptime.
• Failure rate.
• User reliability reports.

Gateway reputation influences marketplace visibility and future reward eligibility.

19.16 Gateway Staking#

Notification Gateway Operators stake OPEN before becoming eligible to receive protocol notification traffic.

Staking provides:

• Economic accountability.
• Long-term commitment.
• Sybil resistance.
• Service quality incentives.

Repeated protocol violations or persistent service failures may reduce reward eligibility or trigger governance-defined penalties.

19.17 Gateway Rewards#

Notification delivery is an optional premium service.

When creating a trade, participants may enable notifications by paying a small fixed protocol fee denominated in OPEN.

The protocol automatically distributes that fee.

Revenue is shared between:

• The selected Notification Gateway.
• Protocol Treasury.
• Ecosystem incentives.
• Other governance-approved allocations.

Gateway operators are rewarded for successfully processing notification jobs rather than simply remaining online.

This naturally encourages:

• High reliability.
• Low latency.
• Competitive pricing.
• Excellent service quality.

19.18 Gateway Diversity#

One of the strengths of the Notification Gateway Network is that providers may specialize.

Examples include:

• Global commercial email providers.
• Regional SMS operators.
• Community-operated Telegram gateways.
• Privacy-focused notification services.
• Enterprise messaging platforms.
• Universities operating campus gateways.
• Companies integrating OpenFiat into internal systems.
• Individuals operating Raspberry Pi devices connected to local GSM modems.
• Local telecom providers exposing standardized notification APIs.

Every gateway participates under identical protocol rules.

The protocol neither favors nor distinguishes between implementations.

19.19 AllenHark's Initial Role#

During the bootstrap phase, AllenHark will operate several public Notification Gateways to ensure reliable service from the first day of network operation.

These services may include:

• Email Gateway.
• Telegram Gateway.
• Discord Gateway.
• Push Notification Gateway.

AllenHark receives no special privileges.

Its gateways compete under the same staking requirements, reputation system, pricing model, and performance metrics as every other operator.

As the ecosystem matures, AllenHark expects independent gateway operators to assume an increasingly significant share of notification traffic.

19.20 Failure Handling#

Notification failures never affect protocol execution.

For example:

A payment may be successfully confirmed.

Escrow may be released.

The trade may complete.

Even if every Notification Gateway is offline.

Notifications improve usability.

They do not determine protocol correctness.

Client applications should therefore always synchronize directly with the OpenFiat network rather than relying exclusively upon notifications.

19.21 Open Implementation#

The Notification Gateway Specification is fully open.

Any developer or organization may build a compatible gateway.

Examples include:

• Self-hosted gateways.
• Commercial notification providers.
• Government or institutional gateways.
• Community-operated gateways.
• Regional telecom integrations.
• Enterprise infrastructure.
• Open-source notification software.

Innovation occurs at the gateway layer without requiring modifications to the OpenFiat protocol.

19.22 Why the Notification Gateway Network Matters#

The Notification Gateway Network embodies one of OpenFiat's core architectural principles.

The protocol defines standards—not providers.

Rather than depending upon a single company or communication platform, OpenFiat specifies an open, interoperable interface that anyone may implement.

As messaging technologies evolve, new gateway operators can immediately participate by implementing the published specification.

This creates a competitive ecosystem where reliability, innovation, privacy, and user choice determine success—not centralized control.

19.23 Looking Ahead#

The OpenFiat marketplace now consists of decentralized trading, escrow, governance, infrastructure, and communication layers.

The next chapter examines the protocol's Security Model, detailing the technical and economic mechanisms that protect OpenFiat against fraud, network attacks, Sybil attacks, bribery, smart contract exploits, oracle manipulation, infrastructure failures, and other threats while preserving decentralization.