# Φ Phinancer Hiper-DEX — White Paper

> A New Era for the Decentralized Financial Market

**Version 0.2** • March 2026

**Pedro Pustiglione** • Founder & CEO

[phinancer.com](https://phinancer.com)

---

## Table of Contents

1. [Executive Summary](#1-executive-summary)
2. [Introduction](#2-introduction)
3. [Current Problems in the Exchange Sector](#3-current-problems-in-the-exchange-sector)
4. [Ecosystem Overview](#4-ecosystem-overview)
5. [Multi-Asset System](#5-multi-asset-system)
6. [Certification System](#6-certification-system)
7. [Technical Architecture](#7-technical-architecture)
8. [Privacy and Anonymity Model](#8-privacy-and-anonymity-model)
9. [Economic Model and Tokenomics](#9-economic-model-and-tokenomics)
10. [Fee Structure](#10-fee-structure)
11. [Governance and Decentralization](#11-governance-and-decentralization)
12. [Applications and User Experience](#12-applications-and-user-experience)
13. [Security Model](#13-security-model)
14. [Development Roadmap](#14-development-roadmap)
15. [Team and Community](#15-team-and-community)
16. [Compliance and Regulation](#16-compliance-and-regulation)
17. [Glossary](#17-glossary)
18. [References](#18-references)

---

## 1. Executive Summary

The Φ Phinancer Hiper-DEX is a next-generation decentralized exchange infrastructure, built on a proprietary blockchain, that redefines how financial services are built, offered, and consumed in the crypto environment. Unlike a traditional exchange, it is a Hiper-DEX: a decentralized protocol that enables the creation of multiple exchanges, brokerages, investment agents, asset issuers, and tokenized service providers, all interconnected in a single global liquidity layer.

Combining staking, certifications, auditable smart contracts, and progressive community governance, the platform allows any participant — from a small agent to a large institution — to operate with security, flexibility, and recognition based on reputation and performance.

Its native token, HDEX, integrates governance, security, incentives, and access to strategic ecosystem features. All gas fees are paid exclusively in HDEX, with an internal auto-conversion service for ease of use. The economic model was designed to promote decentralization and sustainability, with a maximum supply of 10 billion tokens and a distribution structure that favors organic growth across six development phases.

Privacy is a fundamental and inviolable principle: all HDEX token transactions are anonymous by default, with blind validation by servers, and no master key for any entity — including the Foundation itself. The sender can optionally reveal a specific transaction's data for compliance purposes in jurisdictions that require transparency.

The Φ Phinancer Hiper-DEX aims to be the foundation of the decentralized financial infrastructure of the future — like a "Shopify for DeFi" — enabling new services to emerge in a pluggable and interoperable way, while ensuring users maintain absolute control over their assets and privacy.

## 2. Introduction

The Phinancer ecosystem is a revolution in the world of financial transactions, bringing infrastructure for the creation of an entire ecosystem of decentralized platforms designed to facilitate adoption, growth, and capillarity.

We introduce the concept of Hiper-DEX: a proprietary blockchain infrastructure that serves as the foundation for building fully decentralized yet interconnected financial systems, solving problems such as excessive centralization and lack of liquidity. This system allows exchanges built on the Hiper-DEX to have access to global liquidity even with a small customer base, stimulating the creation of countless new financial services. No matter how small, every participant will have access to the global market.

The Phinancer Hiper-DEX is the necessary connection for the crypto market to reach maximum capillarity and adoption. Including multiple assets (HDEX, stablecoins, commodity tokens), smart contracts, user flexibility, and a meritocratic structure, the platform is designed to be the most capillary financial tool in the world.

The blockchain will be built from scratch, applying the most efficient technologies available, using an existing programming language adapted to the project, ensuring total design freedom and maximum performance.

## 3. Current Problems in the Exchange Sector

The exchange market faces challenges that limit true large-scale adoption and user empowerment:

- **Centralized custody risk**: Users depend on third-party asset custody, exposing them to hacks, mismanagement, and fund freezes.

- **Lack of privacy and anonymity**: Most exchanges require invasive KYC. Φ Phinancer solves this by making anonymity mandatory by design for all on-chain transactions, with blind validation by network servers.

- **Centralized and opaque governance**: Rule and fee changes are made arbitrarily, without user consultation or transparency.

- **Low fiat integration**: Entry and exit from the crypto ecosystem remains complex and dependent on centralized gateways.

- **Lack of regulatory flexibility**: Users are treated uniformly, ignoring different contexts of use, countries, and operation types.

- **Local liquidity dependency**: Smaller exchanges cannot compete with major players for liquidity, hampering innovation and limiting access.

- **Lack of real decentralization incentives**: Many DEXs still concentrate power in central teams, limiting genuine community participation.

- **Difficulty scaling financial services**: There is no infrastructure for agents, issuers, and service providers to operate in an integrated manner within the ecosystem.

## 4. Ecosystem Overview

The Hiper-DEX functions as a complete infrastructure where multiple participants interact across complementary layers:

**Infrastructure Layer**: Servers (Processing Servers) that validate transactions and store blockchain data, ensuring network security and availability.

**Financial Services Layer**: Brokerages that create financial instruments, trading pairs, and commodity tokens; Insurers that offer policies via smart contracts; Fiat Gates that bridge the banking system and the crypto universe.

**Service Layer**: Bankers (Agents) who serve investors, guide operations, and acquire new clients. Every investor is mandatorily linked to an Agent — either from a partner Brokerage or from the Foundation's hybrid Agent (bot + human).

**Development Layer**: Authorized Developers who create smart contracts and solutions; Analysts who produce market content and analyses; third-party Platforms that build front-ends accessing the network via APIs.

**Governance Layer**: The Phinancer Foundation controls the initial phases with progressive decentralization toward a full DAO. HDEX holders participate in voting, and the Foundation maintains HDEX10 tokens (with 10x voting power) as a long-term protection mechanism.

All participants operate on a shared global liquidity layer: each AMM pool is unique per asset pair and accessible to all Brokerages simultaneously, ensuring that even the smallest Brokerage has access to global market liquidity.

## 5. Multi-Asset System

The Phinancer ecosystem operates with multiple assets, each with specific functions and privacy rules:

### 5.1 HDEX — Native Token

HDEX is the ecosystem's primary token, used for payment of all gas fees, staking for certifications, governance participation, and as the main medium of exchange. All HDEX transactions are anonymous by default, with maximum and inviolable privacy — no entity, including the Foundation, has the ability to trace transactions.

The sender of a transaction can optionally activate binary revelation, making the origin address, value, and destination address visible for that specific transaction. This option exists to enable legal growth in jurisdictions where total anonymity is prohibited by law. Revelation is binary: either everything is revealed or nothing, with no intermediate options.

### 5.2 HDEX10 — Premium Governance Token

HDEX10 is a special token class with permanent 10x voting power in all network votes. Initially, 1 billion HDEX10 are under Foundation control as a long-term protection and governance mechanism. HDEX10 tokens are fractional and maintain 10x power regardless of division, and can be traded on the market where they will naturally carry a premium due to the voting power they confer.

### 5.3 PHDSC — PH Dollar Stable Coin

A stablecoin with 1:1 backing in US dollars, issued exclusively by the Foundation and its specialized sub-structures (with their own legal entity). The Foundation custodies the collateral and earns revenue through financial investment of these resources. Proof of the 1:1 backing will be provided through periodic independent audits with published results. The model is replicable for other fiat currencies (PHBSC for Brazilian Real, PHESC for Euro, etc.), changing only the nomenclature and corresponding backing. The PHDSC will launch in the Spreading phase.

As a regulated asset, the PHDSC may have administrative control modules operated by the Foundation, including the ability to globally block specific wallets by court order. The PHDSC's privacy level is defined by the Foundation and may differ from HDEX to meet legal requirements.

### 5.4 PH Commodities — Commodity Tokens

Commodity-backed tokens issued by Brokerages that define the contract rules, including the asset's privacy level. The collateral is financial — the Brokerage locks sufficient capital in HDEX or stablecoin (whichever best fits) within the commodity's own smart contract, which contains all rules and guarantees autonomously and auditably. Each commodity token can be traded on any Brokerage in the network, not just the issuer, and the creating Brokerage receives a royalty on all brokerage fees for that contract on any Brokerage. The royalty is included within the network's 10% service fee cap, preventing abuse. The royalty value is freely set by the creator, and market adoption acts as a natural regulator — the lower the fee, the greater the adoption.

### 5.5 PHIPC — Inflation Proof Currency

A currency designed to be inflation-resistant. Details and implementation are planned for the Takeover/Legacy phases of the project.

### 5.6 sHDEX — Native Liquid Staking Token

sHDEX is the network-native liquid staking token issued when a holder delegates HDEX to a Server certification. Unique to Phinancer, sHDEX is **privacy-preserving** (issued to the delegator's stealth address via a Halo2 zero-knowledge proof — hiding both the Server identity and the delegator), enforces a **hard cap of 10% of total sHDEX per Server** (preemptively solving the Lido-style centralization problem seen in other staking ecosystems), and follows an **accruing model** (1 sHDEX starts equal to 1 HDEX and grows over time as staking rewards accumulate, avoiding the depeg drift observed in rebase-style LSTs like stETH). sHDEX can be traded on AMM pools, used as collateral, or held passively to accumulate yield. To exit staking entirely, the holder burns sHDEX after a 21-day cooldown period to receive HDEX back. The 10% concentration cap is governance-tunable by the Foundation and, post-Legacy phase, by the DAO.

## 6. Certification System

The Phinancer ecosystem operates with 8 types of certifications, obtained through HDEX staking. Investor is not a certification — it is the base state of any wallet created on the network. All certified clients are also investors.

### 6.1 General Certification Mechanics

**Activation**: The participant stakes the minimum value corresponding to the desired certification. After staking, there is a 12-hour confirmation period during which the request can be canceled. After 12 hours, the corresponding value enters a 30-day lockup.

**Stacking**: It is possible to accumulate multiple certifications on the same address, as long as total stake covers the value of all active certifications. There are no combination restrictions — a Brokerage can also be an Investor with its own crypto portfolio.

**Deactivation**: The participant requests deactivation of a specific certification. The corresponding value remains in lockup for 30 days, during which the request can be canceled. After 30 days, the value is unlocked and the certification is definitively deactivated.

**Staking without certification**: Clients can stake HDEX without choosing a certification, participating only in reward mechanisms. In this case, unstaking can be requested at any time without a lockup period. Non-certified stakers also have voting rights, provided they keep their tokens staked for at least 60 consecutive days, following the same rule applied to all voters.

**Immutability**: Certifications are an unquestionable right of the holder. Not even the Foundation can block or revoke a certification. The only control mechanism is through the evaluation and reputation system.

**Dynamic stake values**: Minimum stake values for each certification can be adjusted at any time to incentivize or balance the market. An automation algorithm will be developed to assist these adjustments. If the minimum value increases, already-certified participants maintain their certification without needing to add funds. If the value decreases, existing participants can withdraw the difference.

**KYC is optional at every certification tier — including the highest stake tiers.** The Phinancer protocol never requires KYC verification. Each certification holder (Server, Insurer, Brokerage, Gate, Platform, Agent, Analyst, Developer) chooses individually whether to perform KYC and what intensity (individual KYC, business KYB, beneficial-owner disclosure, AML check). Brokerages serving regulated clients typically opt to do KYB themselves and require KYC of their clients; Brokerages operating in jurisdictions or markets that allow anonymity do nothing. Phinancer provides the verification infrastructure (self-hosted PaddleOCR for document scanning, dlib-based face matching, WebRTC liveness check, with **zero retention of original documents** — only a SHA-256 hash is recorded on-chain to prove KYC was performed without exposing the document itself). **Legal responsibility to comply with local regulations is on the certification holder, not on the protocol or the Foundation.** This makes Phinancer the first L1 fundamentally permissionless about KYC even at infrastructure tiers — markets evaluate trust based on visible KYC/KYB badges combined with on-chain stake bond and slashing history.

### 6.2 Certification Table

| Certification | Initial Minimum Stake | Description |
| --- | --- | --- |
| **Brokerage (Broker)** | 1,000,000 HDEX | Creates financial instruments, trading pairs, and commodity tokens. Operates an exchange within the network and manages a network of Agents. Sets brokerage caps for their Agents within the network's maximum limit. Receives royalties on commodity tokens created when traded on other Brokerages. To request certification deactivation, the Brokerage must first terminate the contract with all its Agents and transfer its Commodity contracts to the Foundation. Royalties from existing contracts remain valid and continue being paid to the original contract creation address. New contracts point to the Foundation's Brokerage; if unavailable, one is randomly selected from the 50 most active Brokerages. |
| **Banker (Agent)** | 10,000 HDEX | Serves investors, guides operations, and acquires new clients. Exclusively linked to one Brokerage. Can suggest operations to clients through app notifications that function as pre-mounted smart contracts — the client receives the suggestion and accepts or rejects with a click, without the Agent ever having direct access to client funds. Suggestions are on-chain transactions whose gas fee is paid by the Agent as an operational cost of their work. If the Agent runs out of HDEX for gas, functionalities requiring on-chain transactions stop working until the balance is replenished. Initial limit of 10,000 simultaneous clients, with a target reduction to 1,000 to ensure service quality. |
| **Server** | 1,000,000 HDEX | Provides processing and storage infrastructure for the network. Validates transactions using cryptographic proofs (blind validation) and stores blockchain data. Each Server maintains the last 12 months of operations plus 1 additional random year assigned by the network, totaling a maximum of 24 months. Remuneration is proportional to work performed. The network defines minimum hardware specifications. |
| **Gate (Fiat)** | 50,000 HDEX | Fiat on/off-ramp operator. Can be an individual or a company, with no rule differences between them. Allowing individuals aims to facilitate operations in emerging countries with precarious banking systems. Linked to a Brokerage in the same model as the Agent. Maintains own reserves (separate from stake) of tokens offered, ideally covering 100% of client deposits at all times. Can charge fees at their discretion. Responsible for following or not following local regulations. |
| **Insurer** | 1,000,000 HDEX | Insurance companies operating on the network, creating policies via smart contracts at their own discretion. Can only create policies on matters they have control over and can verify — that is, policies whose claims can be verified without depending on inaccessible private data. Must lock sufficient resources in smart contracts as collateral for each contract, guaranteeing claim payments in a programmatic and auditable manner. Certification stake is separate from operational reserves. |
| **Authorized Developer** | 5,000 HDEX | **Category B (optional cert)** per `docs/decisions/20260501-platform-cert-software-distribution-gate.md`. Developers with a reputation and trust seal in the ecosystem. Have access to the Foundation team and exclusive events. Certification provides security and credibility to their clients. Target policy: once contract-deployment gates pass, contract submission should not require certification; current SR12 does not claim arbitrary public Move bytecode readiness. Certification differentiates through reputation + reputational signal. |
| **Analyst** | 10,000 HDEX | Financial market analysts who produce content, reports, and analyses. Can produce content outside the network displaying the certificate, and submit content distributed via system Apps. Responsibility for published content lies entirely with the Analyst — certification indicates only network participation and eligibility to receive ratings, it does not constitute endorsement by the Foundation or the network. Can charge for services through smart contracts (paid/free plans). Curation is market-driven through consumer ratings, with API available for integration on personal websites. |
| **Platform** | 25,000 HDEX | **Category B (optional cert)** per `docs/decisions/20260501-platform-cert-software-distribution-gate.md`. Server-side third-party front-ends that want access to a future private API tier (target: 99.9% SLA + mTLS + 10K req/s + exclusive endpoints after the relevant gates pass). "Consume Phinancer" should not require cert once public API gates open: the planned public API target is 100 req/s per IP plus self-hosted full nodes. Foundation may discretionary review high-risk applications (advisory, NOT mandatory protocol-level — preserves CLAUDE.md §7.9 KYC opt-in policy). Have autonomy to charge as they wish outside the network, but must follow ecosystem rules within it. |

### 6.3 Evaluation System

Evaluations are anonymous — only the number of evaluations and the consolidated final score are disclosed. Evaluations can be changed by the evaluator at any time.

**For Agents**: Only clients with at least 10,000 HDEX staked who have been served by the Agent for at least 30 days can evaluate. The Foundation may intervene in evaluations exclusively in situations of suspected fraud or to improve the reputation calculation model.

**For Analysts**: Ratings are given by content consumers, with less rigorous criteria as it is an informational service.

**Consequence of low ratings**: Very low ratings block connections with new clients and require a recycling course to unlock and reset the rating. The Foundation provides online materials and tests in an automated manner.

**Agent client limit**: The simultaneous client limit per Agent is defined and adjusted by the Foundation. If the limit is reduced, Agents who already have more clients than the new limit retain their excess clients (grandfathering), but cannot accept new clients until their count falls within the new limit.

### 6.4 Linking and Mobility

**Agents with Brokerages**: The Agent is exclusively linked to one Brokerage. To switch, they request the change with 30 days' notice (can cancel during the period). When linking to a new Brokerage, the Agent is on hold until acceptance by the new partner.

**Investors with Agents**: Every investor is linked to an Agent. If the wallet was created without an invitation, it is automatically associated with a Foundation Agent (bot or person with low/zero fees). The investor can switch Agents with a 7-day window (can cancel during the period). During the 7 days, the investor remains with the current Agent and everything functions normally. After the switch is finalized, pending suggestion smart contracts remain valid but brokerage fees transfer to the new Agent, and the former Agent loses the ability to send new suggestions. Leaving the Foundation for a Brokerage Agent also follows the 7-day rule.

**Gates with Brokerages**: The Gate is linked to a Brokerage in the same model as the Agent. For fiat-crypto transactions, they can operate directly through the Foundation's Brokerage if not partnered with another.

## 7. Technical Architecture

### 7.1 Proprietary Blockchain and Parallel Execution Architecture

The Phinancer Hiper-DEX operates on a proprietary L1 blockchain built in Rust (existing programming language adapted to the project, not a new language), with entirely proprietary network infrastructure.

The target mainnet architecture implements **parallel execution with shared state** ("Path III"), combining three technical layers:

1. **DAG-based consensus** (adapted from protocols such as Narwhal+Bullshark, Tusk, or Mysticeti): separates transaction dissemination from ordering, targeting high throughput and sub-1.5-second finality only after the required hard-finality evidence gates pass.
2. **Parallel execution via rotating committees of K Servers** (selected by VRF each epoch): each committee processes a subset of transactions in parallel with other committees.
3. **Globally-shared state**: a single commitment tree (Poseidon Merkle with periodic Halo2 recursive root) plus a global nullifier set (SMT attested by committees) preserves a **monolithic anonymity set** — every user contributes to every other user's anonymity, without fragmentation via shards or rollups.

**Horizontal scaling organically aligned with the 6 progression phases:** more Servers joining the network form more parallel committees, linearly increasing modeled TPS capacity. The Aurora phase (30 Servers) targets ~1,500-2,500 shielded TPS; Rising (100+ Servers) targets the ≥5,000 TPS floor; later phases target 30,000-60,000+ TPS as the ecosystem matures. These are architecture targets, not current public benchmark claims. The MVP milestone is defined by measured, auditable evidence of sustained TPS (the number is fixed by benchmark, never published before measurement), with the ≥5,000 TPS floor remaining the Rising-phase gate via parallel committees. Required per-Server hardware decreases with network growth (each Server handles a smaller fraction of total transactions as committees multiply) — a property of the routed-dissemination phase; in early phases, the per-Server hardware floor is datacenter-grade (~1 Gbps), published transparently in onboarding.

**Performance hard caps (non-negotiable mainnet targets, not current claims):**
- **≥5,000 sustained private-transaction TPS target** (every transaction passes through the full cryptographic stack: commitment + nullifier + Halo2 proof + stealth addresses + Dandelion++)
- **Transaction finality <1.5s target** (from mempool entry to finalized block)
- **Privacy by default** — every user transaction is shielded; transparent operations exist only where protocol mechanics require them (AMM pool prices, visible stake for BFT weighting)

Current public wording must treat TPS and finality numbers as gated targets until P9/P12 evidence and release review approve stronger claims.

Consensus is Proof-of-Stake with validation exclusively by certified Processing Servers (cert holders with 1M HDEX bond + 30-day lockup). The integrity of blind validation is guaranteed by the mathematical nature of zero-knowledge proofs: each proof generated by a user is verified by the assigned committee without access to the original transaction data, and periodically all Servers validate global consistency via recursive Halo2 proofs. Malicious Servers are penalized with slashing; exact redundancy and penalty parameters are defined during development (sprints SR3 and SR7).

### 7.2 Smart Contracts

Contract deployment is intended to be permissionless after the controlled MoveVM/deploy gates pass. Current SR12 does not claim arbitrary public Move bytecode readiness. Listing contracts on Brokerages for trading is a commercial decision of each Brokerage, separating the protocol layer (open target) from the business layer (curated). New financial instruments created by Brokerages are announced with details and open-source code for community review. The Foundation, with community assistance, authorizes or denies creation, and may establish automatic approval models for contracts that meet predefined standards.

### 7.3 Liquidity Model — Global AMM

In the Aurora phase, the system operates with an Automated Market Maker (AMM) as the primary liquidity model. Each AMM pool is unique per asset pair and global — all Brokerages access the same liquidity pool, without duplication. This ensures maximum market depth and the best price for investors.

AMM pools publicly display prices and order sizes, but without revealing transaction origins, maintaining participant privacy. New AMM pools can be created by any Brokerage, including the Foundation's Brokerage, without requiring prior announcement — creation is an immediate operation. The Brokerage that creates a new pool is responsible for providing initial liquidity, which enters a 30-day lockup to ensure minimum stability for the newly created pool. Any participant can be a liquidity provider (LP). The AMM is a network product with its own fee: operations performed via AMM charge a specific fee exclusively for LP remuneration, separate from the gas fee and outside the 10% service fee cap. This fee exists because the AMM has its own operational costs and is a market option, not a requirement — investors will have alternatives such as the traditional order book (without this fee). To protect against abrupt liquidity withdrawals, LP withdrawals exceeding 2% of the pool's total reserve volume cannot be made at once, requiring multiple scheduled withdrawals at different times. The exact parameters will be simulated and tested. The specific AMM model will be designed and extensively tested to meet ecosystem needs. If impermanent loss problems cannot be adequately mitigated, the system may migrate to a traditional order book.

In the Rising phase, a traditional order book is planned as an alternative, subject to technical feasibility considering security and performance within the network's privacy model.

### 7.4 Servers and Storage

Servers are a unified class combining transaction processing and blockchain data storage. Each Server stores the last 12 months of operations plus 1 additional random year assigned by the network, totaling a maximum of 24 months per Server. Historical data is stored in encrypted form, so the Server cannot identify which year the data corresponds to. Servers can communicate with each other to virtually reconstruct the complete history and make it available to the network when needed.

The network as a whole, through the number of Servers, ensures complete redundancy of all historical data. In case of insufficient Servers, available ones may store more than the standard 24 months. Very old data undergoes a "cooling" process, being divided into annual blocks and distributed across the network, with fewer copies to reduce costs, but always with redundancy. The network's total maintains all information, but not in a centralized manner.

Server remuneration is proportional to work performed (processing volume), incentivizing the development of more servers and ensuring fair distribution. Servers that go offline lose revenue for the corresponding period of inactivity.

### 7.5 Off-Chain Transactions

If the performance targets on the main network are achieved, off-chain transactions may not be necessary. If implemented, they must mandatorily follow the same privacy and security guarantees as the on-chain layer, using the most efficient mechanism available. The concept and implementation will be defined during development, prioritizing performance, security, and preservation of the privacy model.

### 7.6 Bridges with Other Networks

Communication with other blockchains will be implemented starting in the Rising phase, through bridges and interoperability protocols made available as open source to the market. The goal is to not hinder connection with other networks, but privacy outside the Phinancer network is not the ecosystem's responsibility — within the network, privacy is maintained, but when crossing to another network, the destination network's privacy rules apply.

### 7.7 Gas Fee Auto-Conversion

All gas fees are paid exclusively in HDEX. When a user wishes to make a transaction but doesn't have enough HDEX for the gas fee, the system automatically converts a portion of the asset being traded to HDEX at the current AMM market price. The operation is atomic: the gas fee for the conversion itself is automatically deducted from the conversion output, eliminating the problem of the user having zero HDEX to initiate the process. The privacy model hides the correlation between the conversion transaction and the main transaction, preventing observers from linking the two operations. The entire operation — gas conversion and main transaction — is treated preferably as a single atomic transaction, preventing the gas conversion from impacting the pool price before the main operation executes. Gas fees are proportional to the values moved, with a random component within defined ranges (e.g., ±30-50%) to preserve privacy — preventing observers from estimating a transaction's value by the gas paid. Internally, the EMA calculations use the base value (without noise) to accurately reflect real network demand; noise is applied only to the value effectively charged to the user. The average cost remains proportional (the network does not lose revenue), but the individual value of each transaction is protected. As protection against price manipulation in the pool, auto-conversion uses a standard deviation mechanism: if the current pair price in the AMM is outside an acceptable standard deviation from the recent average, the conversion is not executed and the user receives a low market liquidity warning, and must try again when the price stabilizes. For newly created pools without sufficient history to calculate average and standard deviation, this protection is disabled until enough data has been accumulated.

## 8. Privacy and Anonymity Model

Privacy is a fundamental and inviolable principle of the Hiper-DEX. The privacy model is modular per asset, allowing different levels of control depending on each token's nature.

### 8.1 HDEX — Maximum Privacy

For the HDEX token, privacy is absolute and non-negotiable:

**Anonymous by default**: All transactions are fully anonymous. No entity — not the Foundation, not regulators, not servers — can see sender, recipient, or value. Staking is also private: while minimum values for each certification are public, a wallet's total balance and stake composition remain anonymous. A wallet may hold much more in stake than the minimum required for its certifications, without this being visible to third parties.

**Blind validation**: Processing Servers validate transactions using cryptographic proofs without ever accessing transaction details. This eliminates the risk of information leakage by validators.

**No master key**: There is no master key allowing any entity to access transaction data. Not even the Foundation has special access.

**Voluntary revelation**: The sender of a transaction can optionally activate binary revelation, making the origin address, value, and destination address visible. Revelation is always binary (all or nothing) and limited to the specific transaction. This option exists to enable compliance in jurisdictions where total anonymity is prohibited by law. For broader verifications (such as insurer audits), full transaction history disclosure may be required, with each party defining the transparency requirements in their contracts.

### 8.2 Other Assets — Configurable Privacy

Assets such as the PHDSC (stablecoin) and PH Commodities may have configurable regulatory control modules without compromising the main asset's privacy. For the PHDSC, for example, the Foundation defines privacy parameters and may implement controls such as global blocking of specific wallets by court order. For PH Commodities, the asset creator defines privacy rules.

### 8.3 Cryptographic Mechanism

The specific cryptographic mechanism will be developed as a central research area in the Aurora phase. The goal is to create a proprietary model optimized for Phinancer's needs, inspired by the best elements of existing technologies such as stealth addresses (recipient protection), zk-STARKs (no trust ceremony, quantum resistance) and batch proving (performance), but adapted to achieve competitive throughput with blind validation. The double-spending prevention mechanism will also be specifically developed and tested for the adopted privacy model.

## 9. Economic Model and Tokenomics

### 9.1 Supply and Distribution

The total maximum supply is **10 billion HDEX tokens**, distributed as follows:

| Allocation | Percentage | Quantity | Description |
| --- | --- | --- | --- |
| **Phinancer Foundation** | 41% | 4,100,000,000 | Control, governance, development, and Foundation operations |
| **Capitalization (ICO)** | 24% | 2,400,000,000 | Market sales in six progressive rounds across phases |
| **Server Bonuses & Incentives** | 10% | 1,000,000,000 | Validator rewards, performance bonuses, early-phase subsidies |
| **Market Incentives** | 10% | 1,000,000,000 | Partner payments, bounties, airdrops, marketing, developers |
| **Aurora Bonus + Reserve** | 10% | 1,000,000,000 | Aurora stake bonus pool; surplus returns to Foundation |
| **Liquidity Reserve** | 5% | 500,000,000 | AMM liquidity injection and direct market sales |

Additionally, the ecosystem includes **HDEX10** — a governance-weight token with **10× voting power**, total supply of **1 billion HDEX10**, 100% allocated to the Foundation and released linearly over 10 years (daily). HDEX10 gives the Foundation the governance power needed to protect the ecosystem during the growth period, with gradual dilution enabling a smooth transition to community governance.

### 9.2 Capitalization by Phase (ICO)

The 24% ICO allocation (2.4B tokens) is sold in six progressive rounds with increasing prices, from the Aurora phase through the end of the Legacy phase. Sales are open to the global public.

| Phase | % of Supply | Tokens |
| --- | --- | --- |
| Aurora | 10% | 1,000,000,000 |
| Rising | 5% | 500,000,000 |
| Spreading | 2.5% | 250,000,000 |
| Firming | 2.5% | 250,000,000 |
| Takeover | 2.5% | 250,000,000 |
| Legacy | 1.5% | 150,000,000 |

In the Aurora phase, the 10% includes the seed (more flexible negotiation with strategic investors) and the initial ICO. Price and sale method for each round are defined by the Foundation. Fundraising preferably occurs after tokens are available on the mainnet. If the mainnet is not ready in time for initial funding, a token on the Solana network will be launched as a provisional fundraising mechanism, which will be converted 1:1 to official HDEX when the mainnet launches.

### 9.3 Server Bonuses & Incentives

The Server Bonuses & Incentives allocation (10% — 1B tokens) funds validator (Server) rewards, performance bonuses, and early-phase subsidies. This pool ensures that Servers are adequately compensated even before transaction fee volume reaches self-sustaining levels.

- **Block rewards**: Distributed to Servers as supplementary rewards during early phases when fee revenue alone is insufficient.
- **Performance bonuses**: Awarded based on uptime, correct attestation rate, and proposal success — incentivizing reliable infrastructure.
- **Decay schedule**: Foundation subsidy from this pool decays as on-chain fee volume grows, targeting self-sustaining fee economics by year 3–5.

Fee distribution from on-chain transaction fees follows a **60/40 split**: 60% to Servers (with the block proposer receiving 2× weight relative to attesters) and 40% to Stakers (delegators). No new tokens are ever minted — all validator economics are funded from existing supply and transaction fees.

### 9.4 Market Incentives by Phase

| Phase | % of Supply |
| --- | --- |
| Aurora | 2% |
| Rising | 2% |
| Spreading | 2% |
| Firming | 2% |
| Takeover | 2% |

Incentives are used at the Foundation's discretion for direct partner payments, bounties, airdrops, marketing, developers, and any other ecosystem development actions.

### 9.5 Aurora Bonus + Reserve

The Aurora Bonus + Reserve allocation (10% — 1B tokens) is dedicated to funding the Aurora phase stake bonus program (see Section 9.8). This pool caps the maximum payout for early-phase staking incentives. Any surplus tokens remaining after the Aurora bonus program concludes are returned to the Foundation for general ecosystem use.

### 9.6 Liquidity Reserve

The Liquidity Reserve (5% — 500M tokens) is held in a specific wallet controlled by the Foundation, which can inject into AMM pools or sell directly to the market to provide liquidity, at the Foundation's discretion.

### 9.7 Foundation Lockup

The Foundation's 41% (4.1B HDEX tokens) follows the following lockup schedule:

- **21% (2.1B)**: Released proportionally over 10 years, with daily releases in equal amounts (linearly).
- **20% (2.0B)**: Allocated for negotiation power and development team payment, released in 20 equal monthly installments.

The HDEX10 governance token (1B, separate from the 10B HDEX supply) is also released linearly over 10 years, proportionally each day.

The Foundation has autonomy to stake its tokens and participate in the network's reward mechanisms.

### 9.8 Stake Bonus — Aurora Phase

During the Aurora phase, investors who purchase HDEX and stake receive a bonus as an incentive for the ecosystem's initial growth. The bonus is exclusive to tokens acquired through purchase (does not apply to Foundation tokens or internal allocations) and is funded from the **Aurora Bonus + Reserve** allocation (10% of total supply — 1B HDEX):

- The bonus starts at **2% per month** in the first month.
- It decreases **linearly** until reaching **0% at the end of 36 months**.
- Payment is made **weekly** (day 7 of each week).
- The value is calculated on the **staked balance at the start of the previous week** (day 1), measured in HDEX.
- The bonus is paid only on tokens sold during the Aurora phase, limiting the total payout amount.
- There is no provision for stake bonuses in future phases. The goal is to attract participants at the ecosystem's inception.

### 9.9 Foundation Revenue Sources

The Foundation sustains itself through multiple revenue sources:

- **Stake rewards**: Participation in the network's reward mechanisms with its own tokens.
- **Brokerage fees**: The Foundation operates as a Brokerage with the lowest fees in the ecosystem and maintains its own Agents (including the hybrid bot+human Agent), receiving corresponding fees. The Foundation's Brokerage does not engage in active marketing — it is available for those who seek it, without aggressive competition with other Brokerages. Its role is to function as a lighthouse for the ecosystem: testing features, business models, and market structures, and sharing the learnings so other Brokerages can benefit.
- **Yield on PHDSC collateral**: The Foundation financially invests the resources serving as PHDSC backing, earning yield without charging a custody fee.

The focus is on creating sufficient revenue for constant and sustainable project expansion.

### 9.10 Supply Control

- Fixed maximum supply of 10 billion tokens, with no new token issuance and no burn mechanism.
- Incentive for extended staking through certifications and reward mechanisms, reducing actively circulating tokens.
- Certification-induced demand: each function requires staking proportional to system responsibility, creating constant demand pressure.
- Gradual reduction of stake incentives as the ecosystem matures.

## 10. Fee Structure

### 10.1 Service Fee Cap

The network defines a maximum cap on the sum of all service fees charged in a transaction (Brokerage fee + Agent fee + any other fees). The initial cap is **10%**, defined and adjustable by the Foundation. The system simply does not allow the sum of service fees to exceed the current cap.

**Gas fees are outside this cap** and are calculated separately.

### 10.2 Brokerage Cascade

The brokerage structure follows a hierarchical cascade model:

1. The **network (Foundation)** defines the maximum total cap (initially 10%).
2. The **Brokerage** sets its fee within the maximum cap.
3. The **Brokerage** defines the maximum cap that its Agents can charge.
4. The **Agent** sets their fee within the cap defined by their Brokerage.

There are no minimum values — both Brokerages and Agents are free to charge zero if they wish to gain market share through other means.

### 10.3 Gate Fees

Gates can charge fees for fiat on/off-ramp operations at their discretion, separate from brokerage fees. As a general rule, the current market does not charge for this type of transaction, but the option exists to incentivize service provision in specific locations and occasions.

### 10.4 Miscellaneous Fees

Fees for services outside the brokerage structure (such as Analyst services, third-party Platforms, etc.) are free, without a cap.

### 10.5 Gas Fee Model

The gas fee uses a three-layer model with Exponential Moving Averages (EMA) and a rate limiter:

- **60-day EMA**: Controls gas fee bands (maximum and minimum allowed values).
- **5-day EMA**: Calculates the target gas price within the bands based on recent demand.
- **Hourly rate limiter**: The effective gas fee cannot vary more than a defined maximum percentage per hour relative to the previous hour's value (e.g., 5%/hour). On the upside, the effective gas is the lesser of the EMA5 value and the previous hour's value × (1 + limit). On the downside, it is the greater of the EMA5 value and the previous hour's value × (1 − limit). Always bounded by the EMA60 bands. This mechanism prevents spam manipulation: even with sustained artificial demand, gas rises slowly, making the attack economically unfeasible — the accumulated cost of spam exceeds any potential benefit.

This structure allows the gas fee to organically adapt to network demand, avoiding extreme spikes, sharp drops, and manipulation. The goal is to keep costs equal to or lower than Solana's, without compromising the system's economic health — a healthy tokenomics must prevail.

The Foundation can override parameters when necessary. At network launch, gas fee values will be fixed until there is sufficient historical data for the moving averages to function properly. Exact parameters will be defined through simulations.

### 10.6 Gas Fee Distribution

The collected gas fee is split as follows (initial defaults — all values are **governance-tunable parameters**):

- **Base fee 60%** to Servers, distributed proportionally to work performed.
- **Base fee 40%** to network stakers (including sHDEX delegators), distributed proportionally to each participant's staked amount, with no distinction between certified and non-certified stakers. The Foundation also receives proportionally to stake made with its own tokens.
- **Priority tip 100%** to the Server that included the transaction, providing direct incentive for prioritization.

The model evolves toward EIP-1559-style auto-adjustment (base fee responding to per-block utilization) during the Spreading phase, replacing the EMA-only model described above. The Foundation can adjust the 60/40 split, the priority tip allocation, and all related parameters via on-chain governance proposals.

**Zero burn — architectural commitment.** Phinancer's economic design forbids burning fees, slashed stakes, or any other on-chain value. Every unit collected by the protocol flows back to network participants who do the work (Servers + Stakers). 90% of any slashed value flows directly to the 40% Stakers pool, rewarding honest stake for honest behavior. **Optional insurance** is offered by individual Insurer cert holders (traditional insurance model — each Insurer with its own capital pays indemnification from its own policies; opt-in delegator pays +1% commission as premium to the chosen Insurer). There is no centralized Foundation "Insurance Fund"; it's a decentralized insurance market. Burn would transfer value from "workers" to "passive holders", contradicting the Phinancer thesis that infrastructure contribution should be rewarded. Changing the no-burn commitment requires a hard fork, not a governance proposal.

The system as a whole is designed to be self-sustaining without new token issuance and without value destruction. Network revenue comes exclusively from fees (gas fees and service fees). If processing capacity decreases (fewer Servers), the auto-adjusting base fee naturally rises, making it more attractive for new Servers to join the ecosystem and creating an organic equilibrium mechanism.

## 11. Governance and Decentralization

### 11.1 Progressive Decentralization

Phinancer's governance follows a progressive decentralization model:

- **Early phases (Aurora to Spreading)**: The Foundation has unilateral decision-making power over most ecosystem parameters.
- **Middle phases (Firming to Takeover)**: Gradual opening to community voting as the community grows.
- **Final phase (Legacy)**: Strengthening of the voting system and planning for full decentralization toward a DAO.

Phases are a means of organizing project progress. The transition between phases is decided by the Foundation at its discretion, based on the overall progress of the ecosystem.

### 11.2 Three-Round Voting System

To ensure proposals are adequately evaluated without requiring unrealistic participation, the voting system operates in three progressive rounds. "Valid votes" in each round refers to votes actually cast, not the total possible votes in the network.

**Who can propose**: To submit a proposal, an active certification on the network is required.

Voting occurs **3 times per year**, in fixed sessions with a defined schedule:

**First round (7 days)**: Any proposal submitted by a certified participant enters the first round. To advance, the proposal needs support from **5% of valid votes** cast. This round functions as an initial filter to eliminate proposals without minimum support. After the first round, there is a **7-day gap** before the second round.

**Second round (7 days)**: Only proposals approved in the first round. To advance, the proposal needs **20% of valid votes** cast. This round validates that the proposal has substantial community support. After the second round, there is a **7-day gap** before the third round.

**Third round (14 days)**: Only proposals approved in the second round. For final approval, the proposal needs **50% + 1 of valid votes** cast. The vote always prevails.

Each complete voting session lasts **42 days** (7+7+7+7+14). Proposals are organized into subcategories for easier Foundation management.

**Voting power**: Each HDEX confers 1 vote. Each HDEX10 confers 10 votes. Only tokens staked for more than **60 days** have voting rights, preventing attacks via flash loans or opportunistic token accumulation to influence votes. As long as the Foundation holds the HDEX10 tokens, it will naturally have the primary vote, ensuring effective control during the ecosystem's initial phases. In the long term, power may be diluted in the community if and when the Foundation decides to sell some HDEX10.

**Emergency voting**: In case of critical vulnerabilities or situations requiring urgent decisions outside the regular schedule, the Foundation can convene an emergency vote with specific rules created for the emergency in question. Regardless of the rules defined, every emergency vote requires a minimum quorum of 50% + 1 of valid votes cast for approval.

### 11.3 Certification Immutability

Certifications are an unquestionable right of the holder. Not even the Foundation can block or revoke a certification. The only control mechanism is the evaluation system, which can result in blocking new clients and requiring recycling, but never in loss of the certification itself.

## 12. Applications and User Experience

### 12.1 Two Applications

The ecosystem features two distinct applications:

**Investor App**: Lightweight and intuitive interface, similar to a modern crypto wallet. The main page displays charts and market information, with a menu to create or open wallets. Designed for all investors (with or without certification). Available on mobile, desktop, and web.

**Certified App**: Professional interface with modules that appear based on the user's active certifications. Each certification unlocks specific features (brokerage tools, Agent management panel, Server dashboard, etc.). Designed for participants with active certifications. Available on mobile, desktop, and web.

### 12.2 MVP (Minimum Viable Product)

For the Aurora phase launch:
- **Investor App**: Mobile version as priority, with a complementary web version.
- **Certified App**: Desktop version as priority (greater security for professional operations), with a complementary web version.

### 12.3 Investor Onboarding Flow

The application functions as a crypto wallet on the main page, with charts and market information. In the menu, the investor can open or create a new wallet in two ways:

- **With invitation**: The wallet is created from an Agent or Brokerage invitation, automatically linked to them.
- **Without invitation**: The wallet is created without prior links and is automatically associated with a Foundation Brokerage and Agents, functioning as a basic service network (bot + human with low or zero fees).

A user can create as many wallets as desired, with no limit and no identity requirement. By default, wallets are anonymous. Identity linking to a wallet is optional and available for users in jurisdictions where total anonymity is prohibited by law. The Agent client limit is counted per connected wallets, not per individual persons.

### 12.4 Non-Custodial Wallet

The wallet is non-custodial — the user holds their own keys, which during use are saved locally on the device. The network has no access to keys at any time.

**Standard backup format: BIP-39 24-word mnemonic, universal across every Phinancer surface.** All wallets — Investor (regular and professional modes), Certified, Foundation Console, FROST cold keys — use 24 words (256-bit entropy, quantum-resistant under Grover's algorithm to 128-bit effective security). The 12-word option common in casual wallets is rejected even for the Investor App: Phinancer is designed for a multi-decade lifetime targeting mainnet 2027 and beyond, where post-quantum security must be baked-in from day one. The Foundation Console additionally requires a BIP-39 passphrase (the optional 25th word) for plausible-deniability and extra entropy when controlling tokenomics-level operations.

The full key derivation stack uses BIP-39 (mnemonic) + BIP-32 (hierarchical deterministic) + BIP-44 (path scheme) + BIP-85 (sub-mnemonics — one paper backup can derive multiple wallets for users holding multiple certifications). Encryption-at-rest applies Argon2id key derivation (≥ 64 MB memory cost, ≥ 3 iterations) followed by XChaCha20-Poly1305 authenticated encryption. The device backup, where supported, leverages native secure storage (Apple Secure Enclave, Android Keystore, Windows Hello TPM).

**Hardware wallet support is tiered to risk:** Investor App targets hardware wallet integration in MVP (Ledger via WebUSB on desktop and BLE on mobile, Trezor via USB on desktop). The Certified App **mandatorily requires a hardware wallet for the Server certification tier** (the 1M HDEX bond justifies hardware-key custody — YubiKey at minimum, Ledger preferred). Other certification tiers and the Foundation Console support hardware wallets as a strongly recommended option but never force the choice — FROST multisig committee accommodates per-member tooling preference.

### 12.5 Digital Inheritance and Recovery

Feature planned for the end of the Rising phase. The mechanism works as a configurable smart contract on the primary wallet:

- The wallet has a primary key and secondary (heir) keys.
- The user programs an inactivity period for the primary key, with a mandatory minimum of 90 days.
- Once the inactivity period is reached, the smart contract automatically sends assets to the heir wallets according to defined percentages.

**Mnemonic loss is recoverable only via Inheritance configuration.** Because Phinancer does not implement centralized social recovery (which would violate the privacy and self-custody principles documented in §8 and §12), and because the BIP-39 24-word mnemonic is the sole authoritative seed for every wallet (see §12.4), losing the paper backup without an active Inheritance configuration results in permanent loss of funds. The Investor App's onboarding flow consequently encourages every user to configure at least one heir wallet at creation time, with sensible defaults (heartbeat of 365 days, single primary heir). Users who explicitly decline must acknowledge "I accept that losing my keys means losing my funds" before continuing.
- The user defines the percentage of assets allocated to each heir key.
- This mechanism also functions as an access recovery system in case of primary key loss.
- Inactivity detection is accomplished through a mandatory heartbeat mechanism: the primary wallet periodically sends a message (weekly or monthly) to the inheritance smart contract, with a small gas fee cost. Sending the heartbeat is the sole responsibility of the holder — without it, the network has no way to know whether the client is active. The absence of these messages beyond the configured inactivity period triggers the automatic transfer. This model preserves privacy, as the heartbeat is an anonymous transaction like any other.
- To activate the inheritance feature, the smart contract requires a pre-locked HDEX reserve to cover the gas fee for the automatic transfer execution. Without this reserve, inheritance cannot be activated.
- Inheritance transfers not only assets but also active certifications, corresponding stake, and clients linked to those certifications. Heir wallets receive a full operational succession, enabling service continuity. Inheritance does not alter existing bindings of the heir wallet (e.g., if the heir is already an Agent at a Brokerage, they remain linked to it and receive the inherited certification separately, able to reorganize manually). In case of lockup conflicts (tokens in waiting period due to certification deactivation), inheritance prevails and assets are transferred in full.
- Correct configuration of heir wallets is the sole responsibility of the user. The network does not validate recipient identities.

## 13. Security Model

- **Reputation and evaluation system**: Every interaction affects participant reputation. Very low ratings block connections with new clients and require a recycling course at the linked Brokerage.

- **Community auditing**: Contracts, operations, and issuances undergo open community review. New financial instruments are announced with details and open-source code before approval.

- **Wallets with adaptive security**: Possible multi-signature support (a single wallet with multiple keys), subject to compatibility with the privacy model — if no mechanism that preserves anonymity is found, this feature may be excluded. Suspicious behavior alerts and digital inheritance mechanism as protection against access loss.

- **Blind validation**: Processing Servers validate transactions without ever accessing the data, eliminating the risk of information leakage by validators.

- **Privacy as protection**: The default anonymity of HDEX transactions protects against front-running and sandwich attacks, as no participant (including servers) can see orders before execution.

- **Smart contract security**: Contracts follow market standards, undergo public testing, and community review before being made available for trading.

- **Staking as commitment guarantee**: Mandatory staking for certifications ensures real economic commitment from participants, with a 30-day lockup that disincentivizes opportunistic behavior.

## 14. Development Roadmap

Each phase has an estimated duration of 18 to 36 months. The total project horizon is 9 to 18 years.

### Phase 1 — Aurora — Foundation and Structuring

- Proprietary blockchain development and testnet
- White Paper structuring and business model
- Ecosystem design and HDEX token architecture
- Seed fundraising and ICO start (after mainnet)
- MVP implementation with essential certifications: Servers, Brokerages, Agents, and Gates
- Privacy model and blind validation development
- MVP app launch: mobile (investor) + desktop (certified) + web

### Phase 2 — Rising — ICO and Solidification

- Continued ICO in rounds with increasing prices
- Customer acquisition techniques focused on high adoption
- Base structure solidification and acquisition technique refinement
- Implementation of all 8 ecosystem certifications
- Traditional order book addition (subject to technical feasibility)
- Bridge development with other blockchains (open source)
- Digital inheritance and wallet recovery system implementation

### Phase 3 — Spreading — Global Expansion

- PHDSC (PH Dollar Stable Coin) launch and stablecoin model
- Focus on acquiring new partners at a global level
- Effective blockchain ecosystem creation with solid capillarity
- PH Commodities token expansion

### Phase 4 — Firming — Strengthening

- Leverage and perpetual futures implementation
- Focus on end-client acquisition
- Consolidation and strengthening of the entire created base (Brokerages and Agents)

### Phase 5 — Takeover — Traditional Market Absorption

- PHIPC (Inflation Proof Currency) development
- Partnerships with traditional brokerages and traditional asset derivatives
- Period when traditional brokerages will be compelled to study and adopt the ecosystem

### Phase 6 — Legacy — Full Decentralization

- Final ICO round (1.5% of supply)
- Voting system strengthening
- Planning and execution of full decentralization toward DAO
- Progressive transfer of decision-making power to the community

## 15. Team and Community

- **Founder — Pedro Pustiglione**: With over 17 years of experience in the financial market, Pedro envisioned the Hiper-DEX as a response to structural limitations of traditional exchanges. He is responsible for the strategic vision, risk control methodology, and overall ecosystem architecture.

- **Technical Team**: Developers specialized in blockchain, smart contracts, cryptography, information security, and cross-network interoperability.

- **Product and Growth Team**: Focused on user experience, acquisition strategy, institutional partnerships, and new market development.

- **Collaborator Network**: Certified analysts, agents, and community leaders, incentivized with tokens, reputation, and certifications.

- **DAO Community**: Progressive decision-making power over development, resource allocation, and protocol adjustments through community voting.

Engagement initiatives: token-rewarded hackathons, mentorship programs, local ambassadorships, public forums, and incentives for educators and Bankers.

## 16. Compliance and Regulation

- **Structural protocol privacy**: All HDEX transactions are anonymous by default and protected by native cryptographic mechanisms. Anonymity is a permanent and inviolable infrastructure characteristic.

- **Modular privacy per asset**: Regulated assets such as the PHDSC may have specific control modules, including global wallet blocking by court order, without compromising the main asset's privacy.

- **Voluntary revelation**: The sender can choose to make a specific transaction's data visible for compliance purposes in jurisdictions that require transparency.

- **Fiat Gates as regulatory bridges**: Fiat-crypto operators are responsible for following local regulations in each jurisdiction. The network does not interfere with Gates' local regulatory practices.

- **Individual responsibility**: Each participant is responsible for following or not following local regulations in their jurisdiction. The network does not impose or supervise local regulatory compliance for the HDEX asset.

- **Preparation for future regulations**: For regulated assets, legal updates can be incorporated in a coordinated manner by the Foundation or, in the future, via DAO voting.

## 17. Glossary

| Term | Definition |
| --- | --- |
| **AMM** | Automated Market Maker — Automated liquidity mechanism enabling trades without needing a direct buyer/seller. |
| **Certification** | Representation of ecosystem roles, obtained through HDEX staking and maintained by reputation. |
| **DAO** | Decentralized Autonomous Organization governing the protocol through on-chain voting. |
| **DEX** | Decentralized exchange allowing asset trading without centralized intermediaries. |
| **EMA** | Exponential Moving Average — Used to calibrate gas fee parameters. |
| **Gas Fee** | Fee paid to process transactions on the network, always in HDEX. |
| **HDEX** | Native token of Φ Phinancer Hiper-DEX. Engine of governance, staking, incentives, and access. |
| **HDEX10** | Special token with permanent 10x voting power, used as a long-term governance mechanism. |
| **Hiper-DEX** | Protocol serving as infrastructure for multiple interconnected DEXs in a global liquidity layer. |
| **Fiat Gate** | Fiat-to-crypto conversion service operated in a decentralized manner. |
| **LP** | Liquidity Provider — Deposits assets in AMM pools and receives a portion of trading fees. |
| **Lockup** | Period during which tokens are locked and cannot be moved. |
| **Non-custodial** | Wallet model where the user holds their own private keys, without depending on third parties. |
| **PH Commodity** | Commodity-backed token issued by Brokerages with financial collateral. |
| **PHDSC** | PH Dollar Stable Coin — Stablecoin with 1:1 backing in US dollars, issued by the Foundation. |
| **PHIPC** | Inflation Proof Currency — Inflation-resistant currency planned for future phases. |
| **Smart Contract** | Self-executing digital contract with rules programmed directly on the blockchain. |
| **Staking** | Process of locking tokens as a commitment guarantee, security, and access to certifications. |
| **Stealth Address** | Unique address generated per transaction, preventing public traceability. |
| **Blind Validation** | Process where Processing Servers validate transactions through cryptographic proofs without accessing transaction data. |
| **zk-STARK** | Zero-knowledge Scalable Transparent Argument of Knowledge — Zero-knowledge proof without need for a trust ceremony. |

## 18. References

- Bitcoin White Paper — Satoshi Nakamoto (2008)
- Monero White Paper — Moneropedia / Research Lab
- Solana White Paper — Anatoly Yakovenko (2017)
- Ethereum White Paper — Vitalik Buterin (2013)
- Zcash Protocol Specification — Electric Coin Company
- StarkWare Documentation — StarkWare Industries
- Phinancer Internal Documentation

---

**Φ Phinancer Hiper-DEX** — White Paper v0.2 • March 2026 • [phinancer.com](https://phinancer.com)

> This document is internal and informational. A public version will be created later with sensitive items omitted. This document does not constitute an offer of securities.