Aurogy: A Quantum-Resistant Encrypted Messenger with Native Token Economy and Telecom Integration

1. Abstract

Aurogy is a production-grade, privacy-first communication platform that combines full-featured P2P encrypted messaging with a native blockchain token economy and deep telecom integration. The protocol employs a hybrid post-quantum encryption scheme — pairing the battle-tested X25519 Diffie-Hellman with NIST-standardized ML-KEM-768 (CRYSTALS-Kyber) — to provide encryption that remains secure against both classical computers today and quantum computers tomorrow. Messages and calls are end-to-end encrypted and zero-knowledge to the operator. The financial layer, by contrast, is transparent, programmable, and compliance-ready: a custom Substrate blockchain hosts the AURO native token, a constant-product DEX, a merchant payment infrastructure, and on-chain compliance tooling that gives regulated entities the controls they need. A SIP TLS bridge connects Aurogy users to the global telephone network, creating a revenue stream from carrier termination fees. The result is a communication super-app where privacy is absolute for content, payments are instant and borderless, and the operator can fulfill legal obligations without ever reading a single message.

2. Introduction

2.1 The Problem Space

Modern messaging applications face a fundamental tension between user privacy and commercial viability. This tension has produced three distinct, mutually exclusive categories of products — none of which fully serves users' real needs.

Category 1: Privacy-First Messengers. Applications like Signal demonstrate that strong end-to-end encryption is achievable at scale. They have excellent cryptographic foundations but deliberately avoid building payment infrastructure, telecom integration, or token economies. Their revenue models are donation-based or foundation-funded, limiting their commercial sustainability. Critically, they offer users no way to transact within the same trusted, private context they communicate in.

Category 2: Super-App Messengers. Platforms like WhatsApp and WeChat have achieved enormous scale and now include payment features in many markets. However, their encryption implementations are inconsistent (WhatsApp's metadata exposure is well-documented), their token economies are absent, and their telecom integrations are limited to VoIP that terminates in the app, not to the global telephone network. Their payment features depend on banking partnerships that exclude large portions of the global population.

Category 3: Crypto-Native Messengers. Several projects have attempted to build encrypted messaging on top of blockchain infrastructure. Without exception, these projects have delivered poor user experience, incomplete feature parity with mainstream messengers, or encryption designs that sacrifice privacy for on-chain verifiability. None has successfully bridged the crypto-native world to traditional telecom.

The quantum threat is not theoretical. The National Institute of Standards and Technology finalized post-quantum cryptographic standards in 2024. Adversaries engaged in "harvest now, decrypt later" attacks are actively collecting encrypted traffic today to decrypt it when quantum computers become capable. Any messenger that does not begin the migration to post-quantum encryption now is leaving its users exposed to a retroactive breach of every message they have ever sent.

The banking exclusion problem is real. An estimated 1.4 billion adults worldwide remain unbanked. Traditional payment infrastructure requires government-issued identity documents, physical branch proximity, and credit histories that billions of people do not have. A messenger with a native token economy and a fiat bridge through banking partners can serve these users — but only if the underlying technology is trustworthy and the operator has the compliance tools to satisfy regulators in each jurisdiction.

2.2 Aurogy's Vision

Aurogy is built on a single conviction: the right to private communication and the right to participate in the financial system are not in conflict — they require the same infrastructure.

The architecture reflects this conviction precisely. The communication layer is zero-knowledge to the operator: messages are encrypted blobs stored on IPFS, the chain only stores delivery pointers (a content-addressed hash, a sender account, an expiry block, and a nonce). No one at Aurogy can read a message. The financial layer is the opposite: every token transfer is on-chain, auditable, and subject to the compliance controls that banks and regulators require — freeze, seize, KYC tier enforcement, and daily transfer limits.

This is not a compromise. It is an architectural choice that makes both properties stronger. Because the operator never holds message keys, no court order can compel them to produce message content that does not exist on their infrastructure. Because the token ledger is transparent, the operator can produce a complete audit trail of financial activity to any regulator with appropriate authority. Aurogy is the bank but not the post office.

3. Architecture Overview

3.1 Layered Architecture

Aurogy is organized into five layers, each with distinct responsibilities and trust boundaries.

Client layer. Aurogy clients run on Android (Kotlin Multiplatform with Compose), desktop (macOS, Windows, Linux), and web. Each client embeds a smoldot light node, meaning the device participates directly in the Substrate P2P network without routing all requests through a centralized RPC server. This eliminates a classic trust bottleneck: users do not need to trust an RPC provider to get an accurate view of chain state.

Communication layer. 1:1 and group text messages are stored as encrypted IPFS blobs. The chain stores only the pointer: a CID (content-addressed hash), the sender's account ID, the block-height expiry, and a replay-prevention nonce. Voice and video calls use WebRTC with direct P2P connection where NAT permits. TURN relay servers handle the fallback case. The operator runs TURN infrastructure but cannot decrypt the media stream — DTLS-SRTP encryption is established end-to-end.

Cryptography layer. All message and call encryption is performed in a dedicated Rust crate (crypto/) that is compiled to native code via UniFFI for Android and desktop. The crate exposes a clean interface: generate_keypair(), encapsulate(), decapsulate(), encrypt(), and decrypt(). No cryptographic logic lives in application code.

Blockchain layer. The Aurogy chain is a Substrate solochain running Aura block authoring and GRANDPA finality. Seven custom pallets handle messaging delivery pointers, identity, groups, DEX, payments, compliance, and a general template. The runtime is upgradeable via on-chain governance without a hard fork.

Managed infrastructure. Validator nodes, IPFS pinning services, TURN servers, and the SIP gateway are operated by Aurogy or trusted partners. These components see routing metadata but never message content.

3.2 The Operator's Unique Position

The architecture creates an operator that is simultaneously powerful and constrained:

• Powerful over finance. Aurogy operates the only route by which AURO tokens flow. It can freeze accounts, execute court-ordered seizures, enforce KYC tiers, and set daily transfer limits. This makes Aurogy a viable partner for banks and payment regulators globally.
• Constrained over content. Aurogy holds no message decryption keys. Messages are encrypted on the sender's device before they leave it. The IPFS CID stored on-chain is a hash of ciphertext, not plaintext. Even if every Aurogy validator, IPFS node, and infrastructure server were seized simultaneously, the content of messages would remain encrypted.

This distinction — the bank but not the post office — is the central design principle of Aurogy.

4. Encryption Protocol

4.1 Threat Model and Motivation

Aurogy's encryption is designed to defeat the following adversaries:

1. A passive network observer who records all traffic today with the intention of decrypting it when quantum computers arrive (harvest-now-decrypt-later).
2. A compromised server that gains access to stored ciphertext and delivery metadata.
3. A state-level adversary with a court order compelling the operator to disclose message content.
4. A future adversary who breaks either the classical or the post-quantum component of the hybrid scheme.

The fourth adversary leads directly to the hybrid design. If only classical X25519 is used, a quantum computer breaks it. If only ML-KEM-768 is used, a future classical attack against Kyber (unlikely but not impossible for a new standard) breaks it. The hybrid approach means both the classical and post-quantum components must be broken simultaneously to compromise a session key.

4.2 Key Exchange: Hybrid X25519 + ML-KEM-768

Every Aurogy user holds a hybrid keypair. The keypair consists of two independent key pairs that are used in parallel:

• An X25519 static key pair for classical Diffie-Hellman.
• An ML-KEM-768 key pair (CRYSTALS-Kyber, NIST FIPS 203) for post-quantum key encapsulation.

When Alice wants to send a message to Bob, she performs a hybrid key encapsulation that produces a single 32-byte shared secret:

// From crypto/src/hybrid_kem.rs

pub fn encapsulate(
    peer_public: &HybridPublicKey,
) -> Result<(HybridEncapsulation, HybridSharedSecret), CryptoError> {
    // X25519 ephemeral DH
    let ephemeral_secret = StaticSecret::random_from_rng(OsRng);
    let ephemeral_public = X25519PublicKey::from(&ephemeral_secret);
    let classical_shared = ephemeral_secret.diffie_hellman(&peer_x25519);

    // ML-KEM-768 encapsulation
    let (ct, pq_shared) = ek.encapsulate(&mut OsRng)?;

    // Combine via HKDF-SHA256
    // IKM = classical_shared_bytes || pq_shared_bytes
    // salt = b"Aurogy-hybrid-kem-v1"
    // info = b"shared-secret"
    let combined = Self::combine_secrets(
        classical_shared.as_bytes(),
        pq_shared.as_slice()
    );

    Ok((encapsulation, combined))
}

The combination step uses HKDF-SHA256 with a domain-separated salt (Aurogy-hybrid-kem-v1) over the concatenation of both shared secrets. This construction ensures the output is indistinguishable from random if either input is indistinguishable from random — the formal security property that makes the hybrid binding work.

The HybridEncapsulation value that Alice sends to Bob contains two elements:

• Her ephemeral X25519 public key (32 bytes).
• The ML-KEM-768 ciphertext (~1,088 bytes for ML-KEM-768).

Bob calls decapsulate() to recover the same 32-byte shared secret from his own keypair and the received encapsulation.

Key sizes at a glance:

The modest size overhead of the post-quantum component (~1 KB per session establishment) is acceptable given that session establishment happens once per conversation thread, not once per message.

4.3 Session Encryption: AES-256-GCM

The 32-byte shared secret derived from the hybrid KEM becomes the key for an AES-256-GCM session. AES-256-GCM provides both confidentiality and integrity — an attacker who modifies ciphertext will cause decryption to fail with a detectable authentication tag mismatch.

// From crypto/src/session.rs

pub fn encrypt(&self, plaintext: &[u8]) -> Result<(Vec<u8>, [u8; 12]), CryptoError> {
    let cipher = Aes256Gcm::new_from_slice(&self.key)?;
    let mut nonce_bytes = [0u8; 12];
    rand::thread_rng().fill_bytes(&mut nonce_bytes);  // cryptographically random nonce
    let nonce = Nonce::from_slice(&nonce_bytes);
    let ciphertext = cipher.encrypt(nonce, plaintext)?;
    Ok((ciphertext, nonce_bytes))
}

A fresh 12-byte nonce is generated from the OS random source (OsRng) for every encryption operation. The nonce is transmitted alongside the ciphertext. Because AES-256-GCM nonces are 96 bits and generated randomly, the probability of a nonce collision within a single session key is astronomically low (birthday bound at approximately 2^48 messages per key).

4.4 Message Signing: Ed25519 + ML-DSA

Message authentication in Aurogy uses a hybrid signature scheme parallel to the hybrid KEM:

• Ed25519 (classical) for fast signature generation and verification.
• ML-DSA (CRYSTALS-Dilithium, NIST FIPS 204) as the post-quantum component.

Signatures ensure that a received message was produced by the stated sender — preventing a server-in-the-middle from substituting ciphertext. As with the KEM, the hybrid approach means both the classical and post-quantum components must be broken for a forgery to succeed.

4.5 Extended Double Ratchet with PQ Steps

For 1:1 conversations, Aurogy uses an Extended Double Ratchet protocol. The Double Ratchet algorithm (used in Signal) provides forward secrecy and break-in recovery by continuously deriving new message keys from a ratcheting chain. Aurogy extends this with periodic post-quantum ratchet steps: at regular intervals (configurable by chain governance), the symmetric ratchet chain is refreshed with a fresh hybrid KEM exchange. This ensures that even a long-lived conversation's past messages remain secure if a post-quantum key is later compromised — PQ ratchet steps provide PQ forward secrecy, not just PQ session establishment.

The ratchet operates on three chains:

• Root chain — updated by Diffie-Hellman ratchet steps (PQ or classical).
• Sending chain — derives per-message encryption keys.
• Receiving chain — mirrors the sender's sending chain for decryption.

4.6 Group Messaging: Sender Keys

Group messaging uses the Sender Keys scheme. Instead of the O(n^2) overhead of encrypting a message individually for each group member, each participant generates a single Sender Key — a symmetric key and a counter. The sender encrypts the message once under their Sender Key, then distributes an encrypted copy of the Sender Key to each group member (encrypted under each member's individual hybrid public key). Recipients cache the Sender Key and use it to decrypt future messages from that sender without any additional per-message key exchange.

Group membership changes (member add/remove) trigger a key refresh: all remaining members receive new Sender Key distributions, ensuring that removed members cannot decrypt future messages even if they retain old keys.

The Aurogy chain's groups pallet stores group membership on-chain. Each group message is an encrypted IPFS blob; the chain stores a GroupMessagePointer containing the CID, sender account, and nonce for each member's inbox. The group name itself is stored as a hash (name_hash: [u8; 32]) — the chain never holds plaintext group names.

4.7 Media Encryption

Media files (images, video, audio, documents) are encrypted with a per-file AES-256 key before upload to IPFS. The encryption key is embedded within the encrypted message that links to the file. From the chain's perspective, a media message is identical to a text message: a pointer to an IPFS CID. The media decryption key is only accessible to message recipients who can decrypt the message body.

This two-layer approach has a significant property: even if an IPFS node operator inspected the raw content stored at a CID, they would see only random-looking bytes — the AES ciphertext — with no indication of what type of media it represents.

4.8 Hot-Swappable Algorithms

The choice of ML-KEM-768 and ML-DSA is not permanent. The Aurogy chain's governance system can upgrade the post-quantum algorithm set via on-chain vote. If a future NIST revision supersedes Kyber or Dilithium, or if a weakness is discovered in either algorithm, the chain can coordinate a migration to new algorithms without requiring clients to be manually updated. Clients advertise their supported algorithm set in the identity pallet; the negotiation logic selects the best mutually-supported algorithms during session establishment.

4.9 Security Guarantee Summary

"If either the classical component OR the post-quantum component holds, your encryption holds."

This guarantee applies to:

• Message confidentiality (via hybrid KEM + AES-256-GCM).
• Message authenticity (via Ed25519 + ML-DSA signatures).
• Forward secrecy (via Double Ratchet with periodic PQ ratchet steps).
• Media confidentiality (via per-file AES-256 encryption).

5. Blockchain and Token Economy

5.1 The Aurogy Chain

The Aurogy chain is a Substrate-based solochain. Substrate, developed by Parity Technologies and the foundation of Polkadot, is the industry's most mature framework for building purpose-built blockchains. Substrate provides a production-grade P2P networking layer, an efficient state machine, WebAssembly-based runtime upgrades, and a rich ecosystem of pre-built modules (pallets).

The Aurogy runtime uses two consensus mechanisms in combination:

• Aura (Authority Round) for block authoring. Validators take turns producing blocks in a round-robin fashion. Block time is configurable (currently targeting 6 seconds). Aura is fast and predictable, making it suitable for a network where validator identity is known.
• GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) for finality. GRANDPA provides provable finality: once a block is finalized by GRANDPA, it can never be reverted. This property is essential for payment finality — Aurogy Pay merchants need to know that a payment is irreversible before releasing goods.

The combination of Aura + GRANDPA gives Aurogy fast block times (messages appear confirmed within one block) and strong finality guarantees for financial transactions (GRANDPA finalizes chains of blocks, typically lagging the tip by 1-2 blocks).

Runtime upgradeability. The Substrate runtime is compiled to WebAssembly and stored on-chain. When a governance proposal to upgrade the runtime passes, validators execute the new Wasm blob without any manual software update. This means the Aurogy team can ship protocol improvements — including cryptographic algorithm upgrades — without coordinating a hard fork.

Light client operation. Clients run the smoldot light node, a Rust/Wasm implementation of a Substrate light client. smoldot participates in the chain's P2P network, verifies block headers against the GRANDPA finality proofs, and can verify state proofs without trusting any RPC server. This is a meaningful security improvement over most blockchain applications, which trust a third-party RPC provider for all chain state queries.

5.2 AURO Token

AURO is the native token of the Aurogy chain. It serves four distinct functions, each reinforcing the others:

Earn. Users who operate validator nodes earn AURO through block rewards. Users who relay messages via IPFS pinning infrastructure earn micro-rewards for their contribution to content availability. Running infrastructure is not required to use Aurogy, but it creates an economic incentive for users to contribute to the network's resilience.

Spend. Premium features — extended message history, higher-resolution video calls, custom group sizes beyond the free tier, and PSTN calling minutes — are purchased with AURO. The token gives premium features a clear, fair price discoverable by any user, without the opacity of subscription pricing.

Transfer. AURO is a payment medium. P2P transfers, NFC tap-to-pay, QR code payments, payment links, and merchant checkouts all settle in AURO on-chain. The token is the settlement layer for the entire Aurogy payment ecosystem.

Govern. AURO holders vote on protocol upgrades, parameter changes (block time, transfer fee levels, KYC tier thresholds), and treasury spending. A holder's voting weight is proportional to their staked AURO balance. Governance ensures the protocol can evolve without being controlled by a single party.

5.3 Custom Pallets

The Aurogy runtime includes seven custom pallets, each responsible for a distinct domain:

pallet-messaging. Stores MessagePointer records per recipient inbox. Each pointer contains: cid (64-byte IPFS CID), sender (AccountId), expiry (block number), and nonce (u64 replay prevention). The pallet enforces inbox capacity limits (MaxPendingMessages) and TTL-based expiry (MessageTTL). Critically, the pallet stores no message content — only the on-chain address of encrypted content stored off-chain on IPFS.

pallet-identity. Maps SHA-256 hashes of phone numbers to on-chain account IDs, and stores device public keys for SIM swap protection. The chain never holds a raw phone number — only its hash. Identity resolution (hash → account → phone number) requires the operator to hold the hash→phone mapping, which is kept off-chain and can only be disclosed under legal process.

pallet-groups. Manages group metadata (GroupInfo: admin, name hash, creation block), membership lists, and per-member group message inboxes. Group names are stored as hashes, matching the confidentiality model of the messaging pallet.

pallet-dex. Implements a constant-product automated market maker (AMM) with the invariant x * y = k, where x is the AURO reserve and y is the stablecoin reserve. The pallet handles liquidity provisioning (LP token minting via geometric mean for the first provider, proportional thereafter), liquidity removal (pro-rata reserve redemption), and swaps in both directions. The 0.3% fee is applied via the standard amount_in * 997 / 1000 approximation.

pallet-payments. Manages merchant accounts and payment intents (PaymentRequest). Merchants register on-chain with a hashed metadata blob. Payment requests are created with an amount, a recipient, and a block-height expiry. Payers fulfill requests by calling fulfill_payment, which executes the token transfer atomically with the state transition. The payment cannot be double-fulfilled because the status field transitions from Pending to Fulfilled or Cancelled in a single extrinsic.

pallet-compliance. Provides the compliance tooling required by regulated entities: account freezing (with reason hash and audit log), account unfreezing, court-ordered force transfers (requiring the source account to already be frozen), KYC tier management (three tiers: 0=Anonymous, 1=Basic, 2=Verified), daily transfer limit enforcement, and a monotonically-increasing compliance log counter. All compliance operations emit on-chain events that form an immutable audit trail.

pallet-template. A general-purpose extensible pallet used for rapidly deploying additional features before they graduate to their own dedicated pallets.

5.4 Zero-Gas Messaging

Messaging on Aurogy carries no fees. The network is designed gasless for communication — send_message, ack_message, and group messaging extrinsics are exempt from transaction fees at the runtime level. There is no gas cost to absorb or subsidize. Communication is free by architecture, not by subsidy. Token transfers, DEX operations, and payment requests carry micro-fees that sustain the network's financial layer.

This design choice is deliberate and important. If every message required a token fee, users would need to hold AURO before they could use Aurogy as a messenger. This creates a chicken-and-egg adoption problem and degrades the user experience compared to free alternatives. By separating the communication layer (free) from the financial layer (fee-bearing), Aurogy can compete on user experience with WhatsApp while offering a native token economy to users who want it.

5.5 Built-in DEX

The AMM DEX in pallet-dex serves several functions simultaneously:

Price discovery. The AURO/stablecoin pool provides a continuous, on-chain price signal for AURO without relying on a centralized exchange. This price is available to smart contracts, the compliance layer (for fiat-equivalent transaction limit calculation), and users.

Liquidity for payments. Merchants who price goods in fiat can receive AURO payments that are immediately swappable for stablecoin, eliminating their exposure to AURO price volatility at the point of sale.

Fee generation. The 0.3% swap fee accrues to LP token holders. A portion is directed to the treasury to fund ongoing development. LP token holders earn proportionally to their share of pool reserves.

Bootstrapping. The DEX allows early supporters who hold AURO to provide liquidity and earn fees, creating an economic incentive to hold and provide capital to the ecosystem before external exchange listings are established.

5.6 Governance

The Aurogy governance system uses a token-weighted referendum model. Proposals can originate from any AURO holder. Proposals that reach a threshold of community support enter a voting period. During voting, holders lock AURO to cast votes — the lock duration multiplies voting weight, aligning incentives toward long-term thinkers. Passed proposals are enacted via the Substrate runtime upgrade mechanism.

Governance-controlled parameters include: post-quantum algorithm selection (the hot-swap mechanism described in Section 4.8), minimum stake for validator participation, fee levels, message TTL, and treasury spending allocations.

6. Payment Ecosystem

6.1 P2P Transfers

The simplest payment on Aurogy is a direct AURO transfer within a conversation thread. Alice opens a chat with Bob, taps "Pay", enters an amount, and confirms. The transfer executes as a Substrate balance transfer extrinsic, with finality provided by GRANDPA within approximately 12 seconds. The transfer appears inline in the conversation thread, alongside messages and calls, creating a natural context for payments between contacts.

6.2 NFC and QR Payments

NFC payments use Android's Host Card Emulation (HCE) to broadcast a payment request from the payer's device and Core NFC on iOS to receive it. The physical proximity model is familiar from contactless card payments but settles in AURO rather than through a card network. A tap creates a deep link containing the recipient's account ID, the requested amount, and an optional reference, which is pre-filled into the payment confirmation screen.

QR payments follow the same scheme over a visual channel. Static QR codes encode a recipient address and an optional default amount. Dynamic QR codes include a specific amount and a one-time payment ID that maps to a PaymentRequest on-chain, enabling receipt generation. The QR deep link format is:

aurogy://pay?to={account_id}&amount={amount}&ref={payment_id}

This format is parseable by the Aurogy app on any platform, and can be embedded in websites, receipts, invoices, and printed materials.

6.3 Payment Links

Payment links are shareable URLs that encode the same payment parameters as dynamic QR codes. They can be sent over any channel — SMS, email, social media — and open directly to the Aurogy payment confirmation screen when tapped on a device with the Aurogy app installed. On devices without the app, the link resolves to a web page that prompts installation or allows payment via the web wallet.

6.4 Merchant SDK: Aurogy Pay

Aurogy Pay is the merchant payment infrastructure. It replaces the IVOISS Pay brand as the platform matures. Aurogy Pay consists of three components:

JavaScript widget. A drop-in payment button for web checkout flows. Merchants add a single <script> tag and configure their merchant ID. The widget renders a "Pay with Aurogy" button that generates a QR code for mobile payment or connects directly to a web wallet extension.

REST API. A hosted API that allows merchants to create payment intents, poll payment status, and receive webhooks on fulfillment. The API is built with Axum (Rust) and exposes:

POST /api/v1/payments        -- create payment intent
GET  /api/v1/payments/{id}   -- get payment status

Payment creation returns a payment_id, a qr_data deep link, and the payment status. The merchant backend polls or subscribes to webhooks to detect fulfillment.

Mobile SDK. An Android/iOS SDK that integrates the payment flow natively into merchant apps, with branded UI components and deep integration with the Aurogy wallet.

6.5 PAX Terminal Integration

For brick-and-mortar retailers, Aurogy provides a merchant APK for PAX payment terminals. PAX terminals run a hardened Android environment widely deployed by payment service providers globally. The Aurogy PAX APK runs natively on this hardware, allowing merchants to accept AURO payments at a physical point-of-sale without purchasing new hardware. The workflow mirrors traditional card-present transactions: the terminal displays a QR code or generates an NFC payment field; the customer pays from their Aurogy app; the terminal shows a confirmation screen and prints a receipt.

6.6 Fiat On-Ramp

Users who do not hold AURO can purchase it directly within the Aurogy app through integrations with MoonPay and Transak. These regulated on-ramp providers handle fiat payment processing, KYC/AML verification, and conversion. From the user's perspective, they enter a credit card number, pass an identity check once, and receive AURO to their in-app wallet within minutes. The on-ramp providers bear the regulatory burden of fiat handling; Aurogy provides the destination wallet infrastructure.

6.7 Banking Bridge API

The Banking Bridge is Aurogy's mechanism for integrating with traditional financial institutions without taking on banking licenses itself.

The design is deliberately asymmetric. Banks integrate with Aurogy; Aurogy does not become a bank. A participating bank connects to the Banking Bridge REST API and can offer their customers the ability to:

• Load AURO from their bank account (bank-to-AURO conversion at a fixed or market rate).
• Withdraw AURO to their bank account.
• Use Aurogy Pay at any Aurogy-connected merchant, with settlement back to their bank account.

The bank is responsible for all KYC/AML verification of their own customers. The bank holds whatever regulatory licenses are required in their jurisdiction. Aurogy provides the technical infrastructure — the blockchain, the settlement mechanism, the merchant network — and earns a technology fee on transactions.

This model has two critical advantages. First, Aurogy can operate globally without obtaining banking licenses in every jurisdiction — each participating bank provides local regulatory coverage for their own customers. Second, banks gain access to a crypto-native payment rail and a young, digitally-engaged user base without building blockchain infrastructure themselves.

7. Telecom Integration: SIP Bridge

7.1 Phone Number Registration and SIM Swap Protection

Aurogy uses phone numbers as user identifiers, matching the user experience of mainstream messengers. During registration, the user's phone number is verified via SMS OTP. Aurogy then stores the SHA-256 hash of the phone number (not the number itself) in pallet-identity, mapped to the user's on-chain account ID. The device's public key is stored alongside the mapping.

SIM swap protection is a critical security enhancement over SMS-based systems. Once a user's device key is registered on-chain, future authentication operations are validated against the device key — not against SMS delivery. An attacker who performs a SIM swap and intercepts SMS messages cannot access an existing Aurogy account because the account is bound to the device's cryptographic key, not to the SIM card. Account recovery requires a different flow (backup codes or trusted contacts) that cannot be completed by an SMS interceptor.

7.2 SIP TLS Gateway Architecture

The SIP bridge connects the Aurogy network to the global Public Switched Telephone Network (PSTN). The bridge consists of two components deployed in tandem:

Kamailio is an open-source, high-performance SIP proxy and server. In the Aurogy deployment, Kamailio handles:

• SIP signaling routing (REGISTER, INVITE, CANCEL, BYE).
• TLS enforcement for all SIP connections — unencrypted SIP is rejected.
• Load balancing across FreeSWITCH instances.
• Third-party carrier registration and trunk management.

# From sip/kamailio/kamailio.cfg
# Route INVITE to FreeSWITCH for call handling
if (is_method("INVITE")) {
    $du = "sip:freeswitch:5080";
    route(RELAY);
}

FreeSWITCH is an open-source telephony platform that handles media transcoding, RTP relay, codec negotiation, and PSTN interconnection. When a carrier dials a phone number registered to an Aurogy user, the call arrives at the SIP gateway, Kamailio routes it to FreeSWITCH, FreeSWITCH locates the target Aurogy user via the identity pallet, and the call is bridged to the user's app via WebRTC.

The full signal path for an inbound PSTN call:

Audio during the FreeSWITCH transcoding step passes through memory on the media server — this is the one point in the system where a SIP-bridged call is not end-to-end encrypted (the transcoding from PSTN codec to WebRTC codec requires the audio to be briefly decoded). This is an architectural constraint of PSTN interoperability, not an Aurogy design choice. P2P Aurogy-to-Aurogy calls are end-to-end encrypted and never pass through FreeSWITCH.

7.3 Carrier Termination Revenue

Third-party carriers pay Aurogy a per-minute fee to terminate calls to Aurogy users. This is the standard interconnect model used throughout the global telephone network. When a user on any carrier's network dials a phone number registered with Aurogy, the carrier's switch routes the call to the Aurogy SIP gateway and pays the published interconnect rate.

This creates a revenue stream that grows with user adoption: every new Aurogy user who registers a phone number adds that number to the Aurogy termination footprint. Carriers are motivated to establish interconnect agreements because their subscribers demand the ability to reach Aurogy users.

7.4 Future Telecom Features

The SIP bridge roadmap includes:

• Outbound PSTN calling. Aurogy users pay AURO per minute to dial any PSTN number. AURO is converted to pay the terminating carrier's rate.
• SMS gateway. Aurogy users receive SMS messages to their registered number delivered as Aurogy chat messages. Replies from Aurogy are delivered as SMS via an SMS aggregator.
• CLEC license. Obtaining a Competitive Local Exchange Carrier (CLEC) license in the United States would allow Aurogy to own number blocks directly, reducing termination costs and enabling direct DID number provisioning to users.

8. Trust and Safety

8.1 Design Philosophy

End-to-end encryption does not exempt a platform from responsibility for how it is used. The challenge is designing safety mechanisms that are effective against bad actors without creating surveillance infrastructure that undermines the privacy of the vast majority of law-abiding users.

Aurogy's approach is captured in a single principle: the operator is the bank but not the post office. The bank role implies financial oversight. The non-post-office role implies zero access to message content. Trust and safety mechanisms must operate within this constraint — they must not require the operator to read messages.

Aurogy achieves this through three non-content mechanisms: voluntary user reporting, client-side perceptual hashing, and behavioral metadata analysis.

8.2 User Reporting

When a user reports abusive content, they make a voluntary, explicit choice to share that specific content with Aurogy's Trust and Safety team. The reported messages are not decrypted by Aurogy — the reporter's client decrypts the messages (which the reporter can already read) and submits the plaintext along with the report.

The compliance API provides the report lifecycle management:

POST /api/v1/reports        -- submit a report
GET  /api/v1/reports        -- list reports (admin)
PATCH /api/v1/reports/{id}  -- update report status

Each report captures: reporter account, reported account, category (harassment, spam, CSAM, fraud, etc.), content, and the specific message IDs involved. The system never bypasses encryption — it relies on the reporter exercising their own decryption capability to share content they have already received.

8.3 Client-Side CSAM Detection

Child Sexual Abuse Material (CSAM) detection is performed on the device, before encryption, without any content leaving the device in plaintext. The Aurogy client integrates a perceptual hashing library that computes a compact hash of each image before it is encrypted and uploaded. These perceptual hashes are compared against databases maintained by the National Center for Missing and Exploited Children (NCMEC) and the Internet Watch Foundation (IWF).

If a hash matches a known CSAM entry, the message is blocked on the device before transmission. A report is generated and sent to Trust and Safety. Critically, the actual image never leaves the device in plaintext — only the perceptual hash is used for comparison, and the comparison happens locally.

This approach is architecturally compatible with end-to-end encryption because it does not require the operator to see the content. The detection happens at the one moment — before encryption — when content-aware decisions can be made without breaking the encryption model.

8.4 Behavioral Signal Detection

Some harmful patterns are detectable from metadata without reading content: a new account sending thousands of messages per hour is likely a spam operation; an account that triggers hundreds of user reports in a short period is likely abusive regardless of content. Aurogy monitors behavioral signals — message volume, report rates, account age, KYC tier, and network graph patterns — to identify accounts warranting investigation.

Behavioral signals feed into the compliance dashboard where human reviewers make final determinations. No automated action is taken on content-based inferences alone. The goal is to make human review efficient by surfacing high-risk accounts for investigation, not to build an automated content moderation system.

8.5 Compliance Dashboard

The compliance dashboard exposes the on-chain compliance pallet through a REST API, providing operators with:

• Account freeze. Immobilizes an account's token balances. The account can still receive messages (the messaging layer is separate from the compliance layer) but cannot send or receive token transfers. The freeze reason is stored as a hash on-chain (the plaintext reason is stored off-chain, accessible to authorized personnel).
• Account unfreeze. Restores transfer capability.
• Force transfer. Executes a court-ordered seizure of token balances from a frozen account to a specified destination (typically an escrow or law enforcement account). Requires the source to already be frozen and a court order hash to be provided.
• KYC tier enforcement. Assigns an account to Tier 0 (Anonymous), Tier 1 (Basic, identity-verified), or Tier 2 (Verified, full KYC). Transfer limits and feature access can be gated by tier.
• Daily transfer limits. Per-account daily transfer caps, enforceable by KYC tier policy.

Every compliance action is logged as an on-chain event, creating an immutable audit trail that can be produced to regulators on demand.

8.6 Transparency Reporting

Aurogy publishes semi-annual transparency reports disclosing aggregate statistics on: government data requests received, freeze/seize orders executed, CSAM reports filed with NCMEC, and user reports actioned. Individual cases are never disclosed without legal compulsion. The reports are signed by the Aurogy compliance officer and published on-chain as IPFS CIDs, making them tamper-evident.

9. Security Model

9.1 Operator Visibility Table

The following table documents precisely what Aurogy can and cannot see for each layer of the system.

9.2 Key Boundaries

There are four key material boundaries in the Aurogy system, each enforced by architecture rather than policy:

1. Message decryption keys are generated on user devices and never transmitted to Aurogy servers. The hybrid KEM and Double Ratchet mean that even historical session keys cannot be reconstructed from current state.
2. Media decryption keys are embedded within encrypted message bodies and follow the same key material boundary as message keys.
3. AURO signing keys are held in the user's in-app wallet. Aurogy's infrastructure cannot initiate token transfers on behalf of users. Compliance freeze/seize operations are on-chain extrinsics callable only from root origin (the compliance key held by the operator, not user keys).
4. Phone number plaintext is held by the user and by Aurogy's off-chain identity service. The on-chain identity pallet stores only hashes. Resolution of a hash to a phone number requires access to the off-chain identity service, which is subject to legal process but is architecturally separate from the chain.

10. Token Distribution and Economics

10.1 Supply and Distribution

Total supply: 1,000,000,000 AURO (one billion, fixed)

No additional AURO will ever be minted beyond the genesis allocation. The supply is permanently capped.

Ecosystem and Community (30%). The largest allocation, directed toward user acquisition, developer grants, community programs, and liquidity bootstrapping. This pool is spent by governance vote over multiple years. The size reflects the team's belief that Aurogy's success depends on community ownership.

Team (20%, 4-year linear vest with 1-year cliff). Team tokens vest linearly over 48 months, beginning after a 12-month cliff from the genesis date. No team tokens are liquid at launch. This aligns the team's economic incentives with the long-term health of the project.

Treasury (15%). Governed by on-chain governance and held for future protocol development, audits, regulatory compliance costs, and emergency reserves.

Staking Rewards (15%). Distributed to validator operators and message relay operators over a 10-year emissions schedule. The curve is front-loaded to incentivize early infrastructure participation.

Early Investors (10%). Subject to a 6-month lockup followed by 18-month linear vesting, ensuring investor alignment with medium-term outcomes.

Development Fund (10%). Controlled by the core development team for operational expenses — engineering, legal, and infrastructure costs — during the period before the project reaches fee-based sustainability.

10.2 Revenue Streams

Aurogy generates revenue from four sources, all denominated in AURO:

DEX fees (0.3%). Every swap in the AURO/stablecoin pool collects a 0.3% fee. A portion accrues to LP token holders; a portion goes to the treasury.

Payment gateway fees (1-2%). Merchant transactions via Aurogy Pay collect a 1% fee for basic merchant accounts and up to 2% for accounts requiring additional compliance overhead. This is competitive with card network rates (typically 1.5-3.5% including acquirer markup) and significantly below many crypto payment processors.

SIP termination fees. Per-minute fees collected from carriers who terminate calls to Aurogy users. Revenue scales linearly with registered user count and call volume.

Premium features. Extended message history, high-capacity groups, HD video, and outbound PSTN calling are available to users who hold and spend AURO. Premium feature revenue has the desirable property of being directly proportional to token demand — more premium users means more AURO burned or locked.

10.3 Deflationary Mechanics

A portion of fees collected in each category is permanently burned — removed from circulating supply:

• 25% of DEX swap fees are burned.
• 25% of payment gateway fees are burned.
• 25% of premium feature purchases are burned.

SIP termination revenue is collected in fiat (USD) by the telecom entity and used to repurchase AURO from the open market, which is then burned. This creates a buy-and-burn mechanism that links real-world telecom revenue to deflationary token pressure.

Over time, as usage grows, the burn rate can exceed the staking reward emission rate, making AURO net-deflationary. The exact crossover point depends on network adoption, but the model ensures that holders of AURO benefit from the platform's growth through supply reduction rather than requiring constant new investment flows to sustain price.

11. Roadmap

Aurogy has been developed in structured phases, each delivering a complete, production-usable capability before the next begins.

12. Technical Specifications

13. Team and Legal

Team

Aurogy is being developed by a team with backgrounds in telecommunications, cryptography, distributed systems, and financial technology. Detailed team biographies will be published alongside the public mainnet launch.

Advisors

Technical advisors include experienced practitioners in post-quantum cryptography, Substrate runtime development, and regulatory compliance for digital asset businesses.

Legal Disclaimer

This document is provided for informational purposes only and does not constitute an offer to sell, a solicitation of an offer to buy, or a recommendation for any security or financial instrument.

The AURO token is a utility token designed to power the Aurogy platform. It is not intended to constitute a security in any jurisdiction. Purchasers and holders of AURO should seek independent legal and financial advice regarding the regulatory treatment of digital assets in their jurisdiction before acquiring AURO tokens.

The characteristics of the AURO token described in this whitepaper are subject to change. The Aurogy team makes no representations or warranties regarding the future performance of the AURO token, the Aurogy platform, or the completeness or accuracy of the information contained in this document.

Participation in the Aurogy ecosystem, including the purchase or use of AURO tokens, involves risk, including the risk of complete loss of invested capital. The Aurogy platform is subject to technical risks, regulatory risks, and market risks that could materially affect its value and utility.

This whitepaper describes software that is under active development. Features described herein may not be available at the time of any given software release, and the final implementation may differ materially from the descriptions contained in this document.

14. Conclusion

The case for Aurogy rests on a simple observation: the people who most need private communication are often the same people who most need access to financial infrastructure. Journalists, dissidents, migrant workers sending remittances home, small merchants in emerging markets, individuals in countries with unstable currencies — these users are underserved by both the privacy-first messenger category and the payments-first super-app category.

Aurogy is not a compromise between privacy and functionality. It is a demonstration that the two are architecturally compatible. The cryptographic layer — with its hybrid X25519 + ML-KEM-768 key exchange, extended Double Ratchet with post-quantum ratchet steps, and AES-256-GCM message encryption — provides security guarantees that are stronger than any widely-deployed messenger today and will remain strong against quantum adversaries tomorrow. The financial layer — with its custom Substrate chain, AURO token, built-in DEX, merchant payment infrastructure, and on-chain compliance tooling — provides the programmability, transparency, and control that banks and regulators need to operate confidently in the digital asset space.

The SIP bridge is the bridge between these two worlds in the most literal sense: it connects cryptographically secured digital identity (a Substrate account, bound to a device key) to the global telephone network's human-recognizable address space (phone numbers), creating a single, unified communications identity that works across all channels.

Aurogy's competitive position is strongest precisely where other products are weakest: at the intersection of privacy, payments, and telecom. No existing messenger offers quantum-resistant encryption. No existing crypto-native messenger has achieved full WhatsApp feature parity. No existing messaging platform generates revenue from PSTN carrier termination fees. Aurogy occupies all three positions simultaneously.

The infrastructure is built. The encryption is deployed. The chain is running. The path from here is adoption — and adoption follows from demonstrating, in production, that private communication and a native financial layer are not just compatible but mutually reinforcing.

For technical inquiries, partnership proposals, Banking Bridge integration, or carrier interconnect discussions, contact the Aurogy team through the official channels listed at aurogy.io.

Aurogy Whitepaper v1.0 — April 2026
Document hash (SHA-256): to be published on-chain at mainnet genesis