Jowih Credits
The complete Jowih Credits framework — the constitutional foundations and the operating system for Africa's asset-backed bridge token.
Africa's Settlement Bridge Layer
Jowih Credits are established by Article LIX of the Foundation Constitution as a stable, asset-backed digital utility bridge token — not a speculative cryptocurrency, not legal tender, and not a security. They settle cross-border value instantly between national currencies through a partner-only execution model: the Foundation issues and holds the credit; partners handle all conversions. This page combines the constitutional article with the full Jowih Credits operating document.
Credits never enter the domestic economy: at the point of spending they convert instantly to local currency in the background. Merchants and billers always receive local currency. Credits are minted and burned in real time as value crosses borders.
Recital
Jowih Credits are established as a stable, asset-backed digital utility bridge token. They are not a speculative cryptocurrency. They do not involve mining, staking, interest, yield, or dividends.
Across Africa, cross-border trade and remittances are constrained by limited access to major reserve currencies. This constraint creates friction like delays, high costs, and reduced economic activity , not because of any failure in the global financial system, but because of the structural reality of currency availability.
Jowih Credits are designed to provide a neutral, independently governed bridge infrastructure through which participating states, financial institutions, and approved payment providers may facilitate cross-border transactions on an equitable and interoperable basis.
The system is intended to support greater connectivity between national currencies and payment systems while respecting the monetary, financial, and institutional frameworks of each participating state. National currencies remain central to domestic economic activity, while the JOWIH Credit infrastructure provides an additional bridge for eligible cross-border transactions.
Through Credit-Routed FX and interoperable payment infrastructure, the system seeks to improve the efficiency and circulation of available currency liquidity across participating markets, facilitate trade and payments, and reduce unnecessary friction arising from fragmented currency and payment systems.
Participation is founded upon cooperation, mutual benefit, equal treatment, and respect for the sovereignty and financial systems of participating states.
The Foundation's primary economic model is the Treasury Engine ; holding Credits as a stable, asset-backed store of value. The Foundation does not earn from transaction fees. Instead, it earns from the float generated by held Credits, which are invested in mission-aligned projects with all returns flowing to the Mission Fund. This positions the Foundation as a neutral infrastructure layer, not a competitor to partners.
Jowih Credits operate through a partner-only execution model. The Foundation issues and holds the credit. Partners handle ALL conversions. The Foundation does not operate any exchange, conversion, or execution service. This ensures the Foundation never competes with partners and remains purely the credit layer.
Credits exist solely in the bridge layer. They never enter the domestic economy. When Credits are used for domestic spending, partners convert them instantly to local currency in the background. This conversion is automatic, seamless, and invisible to the user. Partners handle the conversion at the point of spending.
Auto-Conversion is the default mode for all transactions. Holding Credits is optional. Credits are a bridge, not a currency.
Jowih Credits shall be issued and operated in compliance with the Mauritius VAITOS Act 2021, FATF Recommendation 15, and applicable host country laws. The Foundation shall obtain and maintain Class S, Class O, Class M, and Class R licenses from the Mauritius Financial Services Commission, or such consolidated license classes as the FSC may permit.
Jowih Credits are designed to accelerate the African Continental Free Trade Area by providing a stable, low-cost, instant settlement layer for intra-African trade. They complement, rather than compete with, existing foreign exchange markets and payment systems.
59.1 Definitions
(a) "Jowih Credit" means the Foundation-issued, asset-backed digital utility bridge token.
(b) Jowih Credits are not legal tender, not a currency, and not a security under the Mauritius Securities Act 2005.
(c) Jowih Credits confer no ownership, voting, profit, interest, yield, or investment rights in the Foundation or any affiliated entity.
(d) "Jowih Ecosystem" includes New Dawn City, the Jowih COS, Foundation-owned assets and projects, spin-off companies, and approved partners.
(e) "PSPS" means Payment Service Provider Systems, including mobile money operators (e.g., M-Pesa, MTN, Airtel), banks, fintech payment gateways (e.g., Flutterwave, Paystack), card networks (Mastercard, Visa), global fintech platforms (PayPal, Stripe), and other licensed payment processors the Foundation may partner with.
(f) "High-Liquid Reserves" means cash, gold bullion, short-term government securities, and such other highly liquid assets as the Combined Trusts Board may designate, with a target allocation of not less than thirty percent (30%) and not more than fifty percent (50%) of total backing.
(g) "Foundation Assets" means current and future revenue streams from the Ecosystem, Foundation-owned companies, real estate off Zone and within Zones, ADFA projects, and any other high-value assets approved by the Combined Trusts Board, with a target allocation of not less than fifty percent (50%) and not more than seventy percent (70%) of total backing.
Provided that High-Liquid Reserves and Foundation Assets shall at all times sum to one hundred percent (100%) of total backing.
(h) "Partner Channels" means end user channels operated by PSPSs, banks, card networks, and fintech platforms for individuals, SMEs, governments, corporations, and institutional investors.
(i) "Flow Engine" means the Foundation's transaction layer where partners handle high-frequency cross-border flows (remittances, SME trade, platform payments) and earn their own margins.
(j) "Treasury Engine" means the Foundation's value-holding layer where Credits are held in the Foundation Treasury, allowing governments, institutions, and multiplayers to hold value because it is stable and asset-backed. The Foundation earns from the float generated by held Credits.
(k) "Auto-Conversion Mode" means the default mode where Credits convert instantly at FX layer from one currency to another local currency or internal from credit to local currency for domestic spending, and to preferred currency for cross-border receipt. This is the system's default behavior.
(l) "Holding Mode" means the optional mode where users may choose to hold Jowih Credits in their wallets for future use.
59.2 Purpose
Jowih Credits shall function as:
(a) A stable bridge between African local currencies and foreign currencies, facilitating cross-border trade, remittances, and investment.
(b) A facilitator of low-cost, instant cross-border payments within Africa and globally, directly supporting the African Continental Free Trade Area (AfCFTA) by providing a reliable settlement layer for intra-African trade.
(c) A stable channel for global investors and diaspora to bring capital into Africa across all 54 countries easily increasing circulation of major currencies like USD, EUR, CNY to Africa.
(d) A complementary financial bridge infrastructure, that works alongside existing global and regional payment systems, offering an additional stable, fast, low-cost option for value transfer.
(e) A dual-engine model operating through partners who handle all conversions, while the Foundation focuses on the stable credit layer and treasury management, earning from the float generated by held Credits.
(f) The Foundation shall not earn from transaction fees. Its primary economic model is the Treasury Engine - holding Credits and investing the float in mission-aligned projects, with all returns flowing to the Mission Fund.
The Foundation shall actively promote the use of national currencies for all domestic obligations, salaries, stipends, and local transactions. Jowih Credits shall not replace or compete with national currencies for domestic use. Credits never enter the domestic economy. They convert instantly to local currency for domestic spending.
59.3 Regulatory Compliance
The Foundation shall:
(a) Obtain and maintain licenses from the Mauritius Financial Services Commission (FSC) under the VAITOS Act 2021 covering all its regulated activities, including:
(i) Class S (Virtual Asset Market Place) - License to operate the Foundation Exchange for matching orders and facilitating the exchange of Credits for fiat currency or other virtual assets;
(ii) Class O (Virtual Asset Wallet Services) - License to operate Jowih wallets, enabling the transfer of Credits between users;
(iii) Class M (Virtual Asset Broker-Dealer) - License required because the Foundation facilitates the exchange between fiat currency and Jowih Credits;
(iv) Class R (Virtual Asset Custodian) - License required for the safekeeping and administration of client virtual assets and/or instruments enabling control over such virtual assets.
Provided that the Foundation may apply for consolidated or combined license classes if the FSC permits such treatment, reducing regulatory duplication while maintaining full compliance.
(b) Comply with FATF Recommendation 15 (new technologies and virtual assets) and all applicable AML/CFT requirements under the Financial Intelligence and Anti-Money Laundering Act (FIAMLA) 2002 (Mauritius) and the FSC's AML/CFT Handbook.
(c) Maintain a physical office in Mauritius and ensure that business activities are directed and managed from Mauritius, as a matter of substance.
(d) Never list Jowih Credits on any internal or external public cryptocurrency exchange for speculative trading.
(e) Designate a senior executive or law firm, residing in Mauritius, responsible for regulatory compliance.
(f) Cooperate with host country regulators where the Foundation operates exchange services, including obtaining equivalent licenses as required.
(g) Maintain the minimum required unimpaired capital for each license class.
(h) Segregate client funds from operational funds and maintain them in trust accounts as required by the FSC.
(i) File annual audited financial statements with the FSC.
59.4 Reserve Backing
Jowih Credits shall be 100% asset-backed. The reserve shall be held in trust, subject to the Asset Lock (Article XXV) and quarterly audited. The reserve composition shall be:
(a) High-Liquid Reserves (30-50% of total backing)
Consisting of:
(i) Cash in major currencies;
(ii) Gold bullion;
(iii) Short-term government securities;
(iv) Such other highly liquid assets as the Combined Trusts Board and Steward President may designate.
(b) Foundation Assets (50-70% of total backing)
Consisting of:
(i) Current and future revenue streams and services;
(ii) Foundation-owned companies, Data Centers, R&D, and spin-off companies;
(iii) Real estate and New Dawn City properties;
(iv) ADFA projects: Foundation-owned or Joint projects (receivables and future cash flows);
(v) Such other high-value assets as the Combined Trusts Board and Steward President may designate.
(c) Allocation Adjustment
The Combined Trusts Board through the company responsible for Jowih Credits may adjust the allocation within the ranges specified in (a) and (b) based on market conditions and risk assessment, provided that:
(i) High-Liquid Reserves shall never fall below 30% of total backing;
(ii) Foundation Assets shall never exceed 70% of total backing;
(iii) The reserve remains over-collateralized at a minimum ratio of 100% of Credits in circulation at all times.
(d) Audit and Transparency
The IAG Departments shall audit the reserve quarterly. Audit results shall be published on the Public Dashboard (Article XXXV) within 30 days. Annual auditing may be done by the External Auditor Firm.
59.5 Jowih COS Hybrid Wallet and PSPS Partnership & Integrations
(a) The Jowih Wallet shall partner with or integrate user PSPS accounts (mobile money, bank accounts, card networks, fintech wallets) into a single interface for respective countries to provide payment services in the Jowih COS and other PSPS-specific services to a broader user base. PSPSs shall retain full ownership of their customer relationships and data.
(b) For local transactions within a country in the Jowih COS:
(i) The default payment method shall be the user's local currency via their chosen PSPS mini-wallets;
(ii) The Foundation through partners shall not force Credits for domestic transactions.
(iii) When a user selects pay with Credits for domestic spending, Credits convert instantly to local currency in the background through the partner.
(c) For cross-border and global transactions:
(i) The preferred payment method in the Jowih COS shall be Jowih Credits to facilitate faster cross-border payments;
(ii) Users may choose alternative local and international currencies too directly.
(d) The Foundation shall partner with PSPSs, banks, card networks, and fintech platforms to enable:
(i) Users to convert and spend Jowih Credits on bills, merchants, and external apps through existing partner infrastructure;
(ii) PSPSs, banks, card networks, and fintech platforms to integrate Jowih Credits Wallet APIs and earn fees, creating new additional revenue streams and settlements;
(iii) Partners handle the conversion of Credits to local currency at the point of domestic spending. This is their core role in the ecosystem.
(e) The Foundation's Jowih COS company shall never compete with existing or future PSPSs, banks, card networks, or fintech platforms. The Foundation shall partner with them, driving new customers and new revenue to PSPSs, banks, card networks, and fintech platforms while extending Credit utility. This does not limit the Foundation from owning a bank.
Therefore, the Jowih wallet shall never be redesigned in a way to do away with PSPSs, banks, card networks, and fintech platforms handling respective wallets they connect to the Jowih COS for user selections as primary wallets, as they will remain the default face of the Jowih Wallet and the backbone for transactions.
(f) The Foundation shall not operate any fiat on-ramp or off-ramp services in any market. The Foundation's role is limited to the bridge layer (issuance, holding, and transfer of Credits). All conversions - retail and wholesale - are handled exclusively by partners. Partners with capacity may handle wholesale conversions. Partners may also route flows to Tier 1 institutions at their discretion. This provision ensures partners remain the default face of the Jowih Wallet and the backbone for all conversions.
59.6 Operational Model
(a) The Foundation shall pay all salaries, stipends, and local obligations in the respective national currencies to boost local currency circulation.
(b) The Foundation may pay contracts, ADFA disbursements, government partnerships, and investments in Jowih Credits.
(c) Inside New Dawn City, residents and businesses may use local currency, but Credits are presumed for efficiency and stability. For domestic spending, Credits convert instantly to local currency in the background through partners.
(d) Outside the Jowih Ecosystem, individuals, governments, and companies may voluntarily convert national currency into Jowih Credits via Partner Channels.
(e) Dual-Mode Operation:
(i) Auto-Conversion Mode (Default): This is the default mode for all transactions. When a user sends funds from one currency to another, the system automatically converts to Jowih Credits for transfer and then to the recipient's chosen currency upon receipt. For domestic spending, Credits convert instantly to local currency in the background. This mode is designed for instant settlement, cross-border trade, remittances, bill payments, and everyday spending involving different currencies. Credits are minted and burned in real time. Reserve requirements are minimal.
(ii) Holding Mode (Optional): Users may choose to hold Jowih Credits in their wallets temporarily for six months. Credits are fully asset-backed and may be used for future payments, savings, or strategic purposes. The Foundation may utilize the float generated by held Credits for strategic investments, with all returns flowing to the Mission Fund or Treasury. Holding is optional, users are not required to hold Credits.
(f) User Choice and Flexibility:
(i) Auto-Conversion is the default mode for all users.
(ii) Holding Mode is optional - users may choose to hold Credits, but are not required to.
(iii) Users may switch between modes at any time.
(iv) No user is compelled to hold Credits.
(v) For domestic spending, Credits always convert instantly to local currency in the background, regardless of mode.
(g) Government and Partner Integration: The Foundation shall partner with PSPSs, banks, card networks, fintech platforms, and governments to enable seamless conversion between local currencies and Credits. Governments receive their tax share on all on-ramp and off-ramp transactions. PSPSs, banks, and fintech platforms earn fees on conversions and local transactions.
59.7 Fees, Government Tax Share, and Market Structure
The government tax share (both foreign governments overseas and local governments in Africa) recognizes that on-ramp and off-ramp transactions occur within each state's sovereign jurisdiction and contributes to the public revenue pool that funds development - a goal shared with the Foundation.
(a) Market Structure - Partner-Only Execution
Jowih Credits operates through a partner-only execution model:
(i) The Foundation does not operate any exchange or conversion service. Partners handle ALL conversions - retail and wholesale.
(ii) Wholesale Channel: Serves governments (treasuries), commercial banks, corporations, airports, airlines, institutional investors, and large partners with capacity. Partners set their own pricing based on the Foundation base rates.
(iii) Retail Channel: Serves individuals, SMEs, and everyday users through PSPSs (mobile money, banks, card networks, fintech platforms). Partners apply their margin on top of the Foundation base rates. There is no minimum transaction.
(iv) Partners as executioners do not hold Jowih Credits. They are conversion rails only. Their role is to convert Credits to local currency for domestic spending. But they can hold credits as clients in their partner wallet for their treasuries, investment and any other needs they have.
(v) Credits never enter the domestic economy. They are a bridge layer only. For domestic spending, Credits convert instantly to local currency through partners.
(b) Foundation Base Rates
(i) The Foundation does not charge any transaction fee on conversions. Partners set their own pricing based on the government tax base and their own margins.
(ii) The base rates for conversions are as follows:
(A) For wallet-to-wallet Jowih Credit transfers: 0% to 1% partner transaction fee. No government tax, as there is no realization event.
(B) For on-ramp and off-ramp conversions: 0% Foundation fee and 0.25% to 0.30% government tax, totaling 0.25% to 0.30% base.
(C) For auto-conversions involving local transaction using pay with credits method directly: 0% Foundation fee, 0.1% to 1% partner fee, and 0.1% to 0.30% government tax.
(iii) The base rates shall be published in the Operational Framework and may be adjusted by the Combined Trusts Board in accordance with the amendment requirements of this Article.
(c) Partner Margins
(i) Partners (PSPSs, banks, card networks, fintech platforms) may add a margin on top of the government tax base for conversions handled through their channels.
(ii) The maximum partner margin shall be 1.5% for on-ramp/off-ramp conversions and 0.1% to 1% for local transactions.
(iii) Partners may compete on margins. Partners earn the margin they add. Partners may decide to set tiers on transaction and apply different margins as per the market condition.
(d) Government Tax Remittance
(i) The government tax of 0.10%-0.30% on local transaction from credits direct or 0.25% to 0.30% on ramps is applied to the base rate.
(ii) The tax is withheld at the point of transaction by the partner.
(iii) The Foundation remits all government taxes to respective governments monthly, or immediately where infrastructure exists.
(iv) Partners are not responsible for tax remittance. The Foundation handles it.
(v) Governments receive auditable reports of all taxable transactions within their jurisdiction.
(e) Foundation Revenue Model
(i) The Foundation does not earn from transaction fees.
(ii) The Foundation's primary economic model is the Treasury Engine - holding Credits and investing the float generated by held Credits in mission-aligned projects.
(iii) All returns from float investments flow to the Mission Fund.
59.8 Holding and Conversion
(a) Jowih Credits earn no interest, yield, or dividends.
(b) Who Holds Credits:
(i) Jowih Credits are held in the Foundation Treasury as reserve backing and liquidity provision;
(ii) Individual users may hold Credits in their Jowih credit wallets for future use maximum six months;
(iii) Partners, Institutions, governments, and ADFA contractors may hold Credits too with agreements in case of extension;
(iv) Partners (PSPSs, banks, card networks, fintech platforms) connect to user's Jowih wallet through APIs. They are conversion rails only. Their role is to convert Credits to local currency for domestic spending.
(v) Holding Credits is optional. Auto-Conversion is the default.
(c) Recipients of Jowih Credits may hold them for a maximum of six (6) months. After six months, the holder is mandated to convert to local currency for domestic needs, with a grace period of one week for anyone who may have forgotten to do so.
(d) Premium Wallets dedicated between the Foundation and hospitals or Foundation and Country Pots under the AHF framework shall have a time limit of seven (7) days after the funds have been received.
(e) Conversion to local or foreign currency shall be available almost instantly through the Jowih Credits blockchain wallet in Partner Channels.
(f) The Foundation may extend the holding period for specific categories of holders (e.g., governments, commercial banks, institutional investors, ADFA contractors) by agreement, subject to anti-speculation safeguards.
(g) Jowih Credits are not an investment vehicle. The Foundation shall not market them as such.
59.9 AfCFTA and Continental Trade
Jowih Credits are specifically designed to accelerate the African Continental Free Trade Area (AfCFTA) by:
(a) Providing a stable, low-cost, instant settlement layer for intra-African trade.
(b) Enabling small and medium-sized enterprises (SMEs) to participate in cross-border trade much easier.
(c) Reducing the cost of cross-border payments and remittances from current levels to under 3%.
(d) Complementing the AfCFTA Payment and Settlement System by providing a digital bridge between the 54 national currencies of AfCFTA member states.
(e) Supporting the AU's Agenda 2063 goal of a fully integrated, prosperous, and peaceful Africa.
59.10 Data Sovereignty and Protection
(a) Cross-border settlement data shall be anonymized and aggregated.
(b) The Foundation shall not monetize or share individual transaction data without explicit user consent.
(c) Partnered PSPSs, banks, card networks, and fintech platforms retain full ownership of their customer data.
59.11 Credit Valuation Framework
59.11.1 Valuation Principle
Jowih Credits ("Credits") shall operate under a structured valuation framework designed to ensure:
- Stability in everyday use
- Global interoperability
- Long-term monetary resilience
The valuation framework shall distinguish between:
- Operational pricing reference, and
- Underlying reserve backing
59.11.2 Primary Reference (Normal Conditions)
Under normal market conditions, Credits shall be valued using a United States Dollar (USD) reference:
1 Jowih Credit = 1 USD equivalent (for pricing and transactional purposes).
This reference shall:
- Serve as a unit of account only
- Facilitate ease of trade, settlement, and adoption
- Not constitute a dependency on USD for underlying value
59.11.3 Independence from Currency Anchors
Notwithstanding the USD reference:
- Credits shall remain fully asset-backed in accordance with Article 59.4
- The reserve shall be diversified across currencies, commodities, and real assets
- No single currency shall define or limit the intrinsic value of Credits
59.11.4 Contingency Valuation Framework (Re-anchoring Mechanism)
To ensure continuity under conditions of monetary instability, the system shall incorporate a Contingency Valuation Framework.
Under qualifying conditions, the valuation of Credits may transition from the USD reference to a Basket Reference Unit (BRU).
59.11.5 Basket Reference Unit (BRU)
The Basket Reference Unit shall represent a diversified valuation standard, which may include but is not limited to:
(a) Percentages portion in diversified major currencies
(b) Percentage portion in Gold or equivalent precious metals
(c) Percentage portion in Asset Index, representing real-economy assets and productive value
The composition, methodology, and periodic adjustments of the BRU shall be determined by the Combined Trusts Board and Steward President, maintained in the Private Annex, and subject to audit and disclosure requirements.
59.11.6 Activation Conditions
The Contingency Valuation Framework may be activated upon the occurrence of defined market stress conditions, including but not limited to:
- Sustained instability or loss of reliability in USD valuation
- Severe disruption in foreign exchange markets
- Significant divergence among major reserve assets
- Systemic monetary or liquidity crises affecting pricing mechanisms
Such conditions shall be:
- Based on objective and verifiable indicators, and
- Evaluated using transparent and auditable data sources
59.11.7 Governance and Authorization
Activation of the BRU framework shall follow a structured governance process:
- Detection of qualifying conditions through system monitoring
- Review and recommendation by the Combined Trusts Board
- Final authorization by the Steward President
Emergency provisions may allow expedited activation where necessary to preserve system integrity.
59.11.8 Continuity and Non-Devaluation
Transition to the Basket Reference Unit shall:
- Constitute a change in valuation reference only
- Not result in loss of value for Credit holders
- Not affect balances, contracts, or obligations
All Credits shall continue to be fully backed and over-collateralized in accordance with Article 59.4.
59.11.9 Transparency and Disclosure
Upon activation:
- The BRU composition and methodology shall be publicly disclosed
- Valuation updates shall be communicated clearly to all stakeholders
- Ongoing reporting shall ensure transparency and confidence
59.11.10 Reversion to Primary Reference
The system may revert to USD-based valuation upon stabilization of market conditions, subject to the same governance, verification, and transparency standards.
59.12 FX Rate Integrity, Settlement Architecture & System Boundaries
59.12.1 Purpose
This Article establishes the principles governing:
(a) Foreign exchange (FX) rate integrity
(b) Transaction execution and rate protection
(c) Blockchain-based settlement
(d) System boundaries, controls, and security
(e) Alignment with global financial systems
The objective is to ensure stability, transparency, and non-disruptive integration with existing monetary and FX frameworks.
59.12.2 Real-Time Market Alignment
(a) All currency conversions within the system shall be executed using real-time market exchange rates sourced from verified liquidity providers.
(b) The system shall not:
- Create synthetic exchange rates
- Fix or administratively determine currency values
- Operate parallel or alternative pricing systems
(c) All pricing shall remain fully aligned with:
- Licensed financial institutions
- FX liquidity providers
- National and international currency markets
59.12.3 Transaction Rate Lock Mechanism
(a) Upon initiation of any transaction, the applicable FX rate shall be immediately locked.
(b) The locked rate shall remain valid for a defined execution window, not exceeding sixty (60) seconds unless otherwise specified by system parameters.
(c) Once locked:
- The transaction shall be executed at the locked rate
- Subsequent market fluctuations shall not affect the transaction outcome
(d) Where a transaction is not completed within the validity window:
- The quote shall expire automatically
- A new rate shall be fetched
- User reconfirmation shall be required
59.12.4 Handling of FX Rate Fluctuations
(a) FX rate changes shall apply only to newly initiated transactions.
(b) Transactions in progress shall remain protected under the rate lock mechanism.
(c) The system shall ensure that:
- Volatility is isolated from users during execution
- Pricing remains predictable and transparent
59.12.5 Internal FX Consistency and Integrity Controls
(a) The system shall operate a unified FX rate engine across all corridors.
(b) All conversion legs, including:
- Local Currency to Credit (Entry)
- Credit to Local Currency (Exit)
shall remain synchronized and consistent.
(c) The system shall prevent:
- Rate mismatches between transaction legs
- Timing-based arbitrage opportunities
- Financial losses to liquidity partners arising from inconsistencies
59.12.6 Blockchain Settlement Layer in Governance OS
(a) The system shall utilize blockchain infrastructure strictly as a settlement layer.
(b) Blockchain usage shall be limited to:
- Transaction finality
- Record integrity and immutability
- Reduction of counterparty risk
(c) The system shall not:
- Use blockchain for speculative pricing
- Derive exchange rates from blockchain markets
(d) All transactions shall achieve near-instant settlement finality, subject to network conditions.
59.12.7 System Boundaries and Operational Role
(a) The Foundation shall operate exclusively at the settlement and coordination layer.
(b) The Foundation shall not:
- Participate in live FX trading
- Act as a market maker
- Set or influence exchange rates
(c) All FX pricing and liquidity provision shall remain the responsibility of external licensed partners.
59.12.8 Wallet, Access and Closed-Loop Controls
(a) All system wallets shall be tied to verified on-ramp and off-ramp partners.
(b) The system shall operate as a closed-loop financial environment.
(c) The architecture shall prevent:
- Arbitrage through VPN or location spoofing
- Unauthorized access to regional pricing differences
- External bypass of the $200m limit FX under credits both in currency auto-conversion or wallet to wallet involving change in currency bases and regulatory controls
(d) Access and participation shall be subject to:
- Identity verification requirements
- Partner-level compliance enforcement
59.12.9 FX Market Compatibility
(a) The system shall operate within existing FX markets, not outside them. INcreasing currency circulation.
(b) Credit-Routed FX is designed to complement traditional FX by providing a faster, cheaper, and more accessible alternative for transactions under $200M.
(c) The system shall preserve the role of:
Major global currencies, including USD
Institutional liquidity providers
National monetary systems
(d) The system shall not interfere with:
Macro-level FX pricing
Central bank policy mechanisms
International financial stability
(e) It shall seek to enable faster, stable and cheaper transactions for the lower FX market where there is friction.
(f) Transactions exceeding $200M shall be routed through traditional FX markets and institutional liquidity channels.
59.12.10 Transaction Scope Limitation
(a) The system shall process transactions below a defined threshold of Two Hundred Million United States Dollars (USD 200,000,000) equivalent.
(b) Transactions exceeding this threshold shall be routed through:
- Traditional FX markets
- Institutional liquidity channels
(c) This limitation ensures:
- Preservation of macroeconomic stability
- Clear separation between operational layers
59.12.11 Economic and Systemic Impact
The architecture established under this Article shall:
(a) Accelerate intra-African currency movement
(b) Increase circulation of USD and major currencies within African markets
(c) Reduce friction in low-to-mid value cross-border transactions
(d) Enhance financial accessibility and efficiency
59.12.12 Principle of Non-Disruption
(a) The system shall function as an efficiency layer, not a replacement for existing financial systems.
(b) It shall:
- Reinforce global financial structures
- Maintain compatibility with international markets
- Avoid distortion of currency valuation mechanisms
59.13 Liquidity, Partner Roles & Spread Governance
59.13.1 Purpose
This Article establishes the framework governing:
(a) Liquidity provision within the system
(b) Roles and responsibilities of participating partners
(c) Spread application and margin distribution
(d) Risk allocation and sustainability of transaction flows
The objective is to ensure efficient liquidity access, fair partner participation, and stable system-wide economics.
59.13.2 Liquidity Provision Framework
(a) All transaction liquidity shall be provided by licensed and verified external partners, including:
- Financial institutions
- Payment service providers
- FX liquidity providers
(b) The system shall not act as a primary liquidity provider but shall:
- Coordinate access to partner liquidity
- Route transactions efficiently across available pools
(c) Liquidity shall be maintained across:
- Local currency corridors (e.g., NGN, KES, ZAR)
- Major global currencies (e.g., USD, EUR)
59.13.3 Role of Liquidity Partners
(a) Liquidity partners shall be responsible for:
- Providing executable FX rates
- Supporting on-ramp and off-ramp conversions
- Absorbing short-term FX exposure during transaction execution
(b) Partners shall operate under:
- Predefined service-level agreements (SLAs)
- Compliance with regulatory and licensing requirements
(c) Partners shall not:
- Manipulate pricing outside market-aligned ranges
- Exploit timing or system inefficiencies
59.13.4 Spread and Margin Structure
(a) Each transaction shall include a spread component, consisting of:
- Government tax (0.25% to 0.30% for on/off-ramp, 0.10% to 0.30% for local transactions)
- Partner margin, determined by liquidity providers
(b) The total transaction cost shall remain:
- Competitive with or lower than traditional cross-border alternatives
- Transparent and disclosed prior to transaction confirmation
(c) The Foundation does not charge any transaction fees.
59.13.5 Spread Governance Principles
(a) Spread application shall follow these principles:
- Transparency - all costs visible to users before execution
- Fairness - equitable distribution between partners and government
- Market alignment - spreads reflect real liquidity conditions
(b) A maximum spread threshold may be defined to:
- Prevent excessive pricing
- Protect end users
- Maintain competitiveness
(c) Partner margins shall remain flexible within controlled boundaries to:
- Encourage participation
- Reflect corridor-specific liquidity conditions
59.13.6 Internal Pricing Consistency
(a) The system shall enforce uniform pricing logic across all transaction legs.
(b) Entry and exit conversions shall be:
- Synchronized
- Derived from the same rate source and timing
(c) This prevents:
- Internal arbitrage
- Pricing discrepancies across corridors
- Unintended financial losses
59.13.7 Risk Allocation
(a) Short-term FX exposure arising from rate locking shall be borne by:
- Liquidity partners
- Supported by spread margins and execution speed
(b) The system shall minimize risk exposure through:
- Near-instant transaction settlement
- Efficient routing and netting mechanisms
(c) Users shall not bear intra-transaction FX risk once a rate is locked.
59.13.8 Incentive Alignment
(a) The system shall ensure that:
- Liquidity partners are economically incentivized to participate
- Margins remain sufficient to sustain liquidity provision
(b) Incentives shall promote:
- High availability of liquidity
- Competitive pricing
- Reliable execution across corridors
59.13.9 Liquidity Discipline and Limits
(a) Liquidity usage shall remain within defined operational limits, including:
- Transaction size thresholds (as defined in Article 59.12)
- Corridor-specific capacity constraints
(b) The system shall avoid:
- Over-reliance on single liquidity sources
- Concentration risk
(c) Diversified liquidity sourcing shall be maintained at all times.
59.13.10 Netting and Flow Optimization
(a) The system may implement internal netting mechanisms to:
- Offset opposing transaction flows
- Reduce external FX demand
(b) Netting shall:
- Improve efficiency
- Lower liquidity costs
- Reduce exposure for partners
(c) All netting operations shall remain consistent with:
- Market-aligned pricing
- Transparency and auditability requirements
59.13.11 Economic Impact
The framework established under this Article shall:
(a) Enable sustainable liquidity across African and global corridors
(b) Strengthen participation of local financial institutions
(c) Reduce transaction costs through competitive spreads
(d) Support scalable growth of cross-border financial activity
59.13.12 Interpretation
This Article shall be interpreted to ensure:
- Sustainable liquidity provision
- Fair and transparent pricing
- Protection of all ecosystem participants
- Long-term stability of the system
59.14 Core Article Status
This Article shall be interpreted to uphold:
- Transaction integrity
- Market alignment
- Partner protection
- System security
- Global financial compatibility
This Article LIX is designated as a Tier 1 Core Article under Article XIX.3.
No amendment may:
(a) Remove the asset-backing requirement, or change the transaction percentages for more profit;
(b) Introduce interest, yield, dividends, or speculative features;
(c) Alter the bridge-only, non-competing nature of Jowih Credits;
(d) Remove government revenue share on on-ramp and off-ramp conversions;
(e) Convert Jowih Credits into a security or investment vehicle;
(f) Eliminate IAG audit requirements;
(g) Permit listing on external speculative cryptocurrency exchanges;
(h) Reduce the reserve backing ratio below 100%;
(i) Force Credits for domestic transactions;
(j) Redesign Jowih Wallet in a way to do away with PSPs or banks as the default face;
(k) Allow partners as executioner to hold Credits as an asset rather than acting solely as conversion rails;
(l) Allow Credits to enter the domestic economy as a currency - Credits must always convert to local currency for domestic spending;
(m) Change Auto-Conversion from the default mode;
(n) Make Holding Credits mandatory - Holding must remain optional;
(o) Operate any fiat on-ramp or off-ramp service - the Foundation shall not operate any conversion service;
(p) Change the positioning of Jowih Credits from a complementary bridge that stimulates FX activity to a system that seeks to replace or compete with traditional FX markets;
(q) Pin credits backing to a single currency;
(r) Remove the need for BRU to value credits during crisis in the market;
(s) Remove the governance or triggers set herein.
59.15 Severability
If any provision of this Article is held invalid, the remaining provisions shall remain in full force and effect. The Foundation shall seek to achieve the purpose of this Article through all lawful means.
JOWIH CREDITS
CORE PRINCIPLE
"Credits are a bridge - not a currency. They never enter the domestic economy. Auto-Conversion is default. Holding is optional. Partners convert. Foundation holds the bridge. Credits may be invisible to the customer (Credit-Routed FX), held as a balance (Holding Mode), or transferred directly (Wallet Transfer) - depending on the transaction mode. But they are never a parallel domestic currency."
STRATEGIC POSITIONING
We specialize in the most active, daily, high-friction layer of global finance - and we make it move better. We create and aggregate high-frequency cross-border flows. Traditional FX settles what we create. Execution done by partners. Different roles. Same system.
The Dual-Engine Model
| Engine | What It Does | How Partners Earn | How Foundation Earns |
|---|---|---|---|
| Flow Engine | Partners handle transactions - remittances, SME trade, platform payments | Transaction fees (0% – 1.5%) | ❌ Does not earn from fees |
| Treasury Engine | Credits held in Foundation Treasury - governments, institutions, multiplayers hold because it's stable | Float value + asset backing | ✅ Earns from float investments |
| Wallet Transfers | Partners handle wallet transfers | 0% – 1% | ❌ Does not earn from fees |
Foundation Revenue Model: The Foundation does not earn from transaction fees. Its primary economic model is the Treasury Engine - holding Credits and investing the float generated by held Credits in mission-aligned projects, with all returns flowing to the Mission Fund.
Our Focus - Flow Creation
| What We Help Handle | What Tier 1 Partners Handle (larger FX market) |
|---|---|
| Remittances | Ultra-large sovereign flows |
| SME trade | Central bank-level liquidity |
| Cross-border payments | Trillion-scale settlements |
| Digital platform payments | Deep FX liquidity provisioning |
| Informal → formal flows | Complex derivatives and hedging |
The Jowih Credits and Traditional FX Market Scale Boundary
| Layer | Handled By | Typical Size | Frequency | Role |
|---|---|---|---|---|
| Ultra-Large / Sovereign | Tier 1 Partners - FX Market (Banks, FX, Hedge Funds) | $100M+ | Low | Settlement anchors |
| Wholesale | Large Partners (with capacity) | $1M - $200M (cap for Jowih Credits FX-classified settlements per transaction) | Medium | Wholesale execution |
| Retail / SME | Partner Channels | No minimum | High | Flow engine |
Clarification: The $200M cap applies only to FX-classified wallet transfers (different currency bases). Same-currency wallet transfers are uncapped. Transactions exceeding the cap may be split into multiple compliant sizes or routed to Tier 1 partners.
THE THREE JOWIH CREDIT WALLETS
| Wallet | Owner | Purpose |
|---|---|---|
| User Wallet | User | Holds user's Credits. Integrated into partner system but owned by user. |
| Partner Wallet | Partner | Holds partner's Credits (if they buy Credits for their own treasury, investment, or settlement). |
| Foundation Treasury | Foundation | Reserve backing. Liquidity provision. Dual-engine treasury layer. |
2. WHERE CREDITS ARE HELD
| Holder | Hold Credits? | Why / How |
|---|---|---|
| User | ✅ Yes | In their Jowih wallet (integrated into partner app or Super App PSPs) |
| Partner (as Rail) | ❌ No | They do NOT hold user Credits. They are an execution rail. |
| Partner (as Client) | ✅ Yes | Holds Credits in their own Jowih wallet after buying Credits |
| Institution/Corporate | ✅ Yes | Holds Credits in their Jowih wallet accounts after buying Credits |
| Foundation Treasury | ✅ Yes | Reserve backing. Liquidity provision. Stable store of value for governments, institutions, and multiplayers. |
Key Distinction:
Partner as Rail = Facilitates conversion. Does NOT hold Credits.
Partner as Client = Buys Credits for own use. HOLDS Credits in their own partner wallet.
3. TRANSACTION-MODE DISTINCTION
Jowih Credits may perform two distinct functions within the Jowih financial infrastructure:
| Mode | What Happens | Customer Sees Credits? |
|---|---|---|
| Credit-Routed FX | Credits operate as an underlying routing mechanism for currency conversion | ❌ No - customer sees currency → currency |
| Pay with Credits (Auto-Conversion) | Credits are used for payment and convert instantly to local currency | ✅ Yes - user selects "Pay with Credits" |
| Credit Wallet Transfer | Credits are directly held, transferred, or settled between wallets | ✅ Yes - Credits move between wallets |
| Holding Mode | Credits are held for future use | ✅ Yes - user holds Credits |
Core Principle: The use of Credits within the underlying infrastructure shall not, by itself, require a customer-facing transaction to be denominated or settled in Credits.
4. MARKET STRUCTURE - PARTNER-ONLY EXECUTION
4.1 Overview
Jowih Credits operates through a partner-only execution model. The Foundation issues and holds the credit. Partners handle ALL conversions.
| Tier | Channel | Users | Transaction Range | Who Handles |
|---|---|---|---|---|
| Retail | Partner Channels | Individuals, SMEs, everyday users | No minimum | Partners |
| Wholesale (Credits cap per FX transaction is $200M) | Large Partners | Governments, corporations, institutions | $1M - $200M | Partners |
| Ultra-Large (Traditional FX Market) | Tier 1 Partners | Banks, FX institutions | All amounts above $200M cap on Jowih Credits | Partners route to Tier 1 partners. Traditional FX Market. (Credits don't handle above this) |
The Foundation does not operate any exchange, conversion, or execution service. Partners handle all conversions.
4.2 Partner Flexibility
Partners are not restricted to a single tier. Large or hybrid partners may operate across both retail and wholesale channels. Partners may define their own operational thresholds and:
Execute transactions directly; or
Route flows to Tier 1 institutions based on capacity or strategy
4.3 Transaction Flow and Settlement Framework
The Jowih structure operates through a distributed partner network supported by a centralized settlement layer.
Participating partners - including institutional, wholesale, and hybrid operators - independently execute transactions based on their internal capabilities, external liquidity access, and operational models.
The Foundation does not directly intermediate or execute transactions. Instead, it provides the underlying settlement infrastructure that ensures system-wide consistency, reconciliation, and stability.
All transactions within the system are evaluated based on wallet currency state alignment, ensuring that any cross-currency movement of value is consistently identified and treated as an FX event regardless of transaction structure or routing path.
4.4 Partner Execution Model
Partners may process transactions through their own internal systems or in coordination with other network participants.
A. Internal Execution
Partners with sufficient external liquidity, infrastructure, and counterparty access may independently execute transactions within their own operational environment.
Under this model:
Transactions are processed entirely within the partner's internal system
The partner retains control over execution, pricing, and FX handling
Currency conversion (where applicable) is handled through the partner's own FX channels
No direct operational involvement from the Foundation is required during execution
The Foundation participates only at the settlement stage
B. Network-Enabled Execution
Where internal execution is not optimal, partners may coordinate with other participants or route transactions across the partner network.
Under this model:
Transactions are fulfilled through inter-partner collaboration
Execution responsibilities may be distributed across multiple entities
Partners maintain flexibility in sourcing external liquidity and counterparties
Cross-currency outcomes remain subject to FX classification based on wallet currency state mismatch
4.5 Partner Routing Framework
Partners may choose between two execution pathways:
1. Internal Execution:
Transactions are executed using the partner's own liquidity sources, banking relationships, or FX providers
Jowih Credits are used only for post-execution settlement recording
The partner retains full execution margin
2. Routed Execution
Transactions are forwarded to another partner or Tier 1 institution
Execution occurs externally within the network or traditional FX market
The originating partner earns a routing or facilitation margin
4.6 Mandatory System Rule
All transactions, regardless of execution path, must be recorded and reconciled through the Foundation's credit ledger. Final external settlement occurs in the applicable local or foreign currency through licensed execution partners.
This ensures:
A single, unified accounting layer
No bypass of system reconciliation
Consistent value representation across all participants
Preservation of system integrity without restricting execution flexibility
Additionally:
"Any transfer resulting in a currency difference between originating and receiving wallets is classified as an FX event, independent of execution path or transaction structure."
4.7 Division of Labor
| Layer | Foundation | Partners |
|---|---|---|
| Credit Issuance | ✅ | ❌ |
| Treasury / Holding | ✅ | ❌ |
| Retail Conversion | ❌ | ✅ |
| Wholesale Conversion | ❌ | ✅ |
| Routing to Tier 1 | ❌ | ✅ |
| Domestic Spending | ❌ | ✅ |
The Foundation does not compete with partners at any level. Partners handle all execution. The Foundation is the credit layer only.
4.8 Non-Competition Commitment
The Foundation shall not operate retail or wholesale fiat on-ramp or off-ramp services in any market where licensed partners are actively offering conversion services.
The Foundation's role is limited to:
The bridge layer (Jowih Credits issuance, holding, and transfer)
The stable credit layer (treasury, reserve backing)
All conversions - retail and wholesale - are handled exclusively by partners.
Partners with wholesale capacity may handle conversions at their discretion. Partners may also route flows to Tier 1 institutions at their discretion.
This commitment ensures partners remain the default face of the Jowih Wallet and the backbone for all conversions. The Foundation is not a competitor - it is an enabler.
PROPOSED FEE SCHEDULE
5.1 Overview
The Foundation does not charge any transaction fees. Partners set their own pricing based on the government tax base and their own margins.
| Transaction Type | Foundation Fee | Government Tax | Total Base | Partner Margin | Total User Cost |
|---|---|---|---|---|---|
| Wallet-to-Wallet Transfer | 0% | 0% | 0% | 0% – 1% | 0% – 1% |
| On/Off-Ramp (Standard) | 0% | 0.25% – 0.30% | 0.25% – 0.30% | 0% – 1.5% | 0.25% – 1.80% |
| On/Off-Ramp (B2B/High-Volume) | 0% | 0.05% – 0.15% | 0.05% – 0.15% | 0% – 1.5% | 0.05% – 1.65% |
| Local Transaction (Pay with Credits) | 0% | 0.05% – 0.30% | 0.05% – 0.30% | 0.1% – 1% | 0.15% – 1.30% |
Notes:
The Foundation does not charge any transaction fees.
Government tax is jurisdiction-aware and negotiable per country, per corridor, per segment.
B2B/High-Volume rates apply to transactions above $1M equivalent or partners processing high annual volumes, subject to agreement with host governments.
Partners set their own margins within the defined maximums.
5.2 Wallet-to-Wallet Transfers
| Channel | Fee | Government Tax | Total |
|---|---|---|---|
| Super App Native | 0% – 1% | 0% | 0% – 1% |
| Partner Wallet | 0% – 1% | 0% | 0% – 1% |
Notes:
No government tax as there is no realization event.
This is a pure transfer of Credits between wallets.
The Credits remain in the bridge layer.
Partners earn the fee they set.
5.3 On-Ramp and Off-Ramp - Africa
| Direction | Foundation Fee | Partner Margin | Government Tax | Total |
|---|---|---|---|---|
| Local → Credits | 0% | 0% – 1.5% | 0.25% – 0.30% | 0.25% – 1.80% |
| Credits → Local | 0% | 0% – 1.5% | 0.25% – 0.30% | 0.25% – 1.80% |
Examples:
| Scenario | Partner Margin | Government Tax | Total Cost |
|---|---|---|---|
| Partner (Low Margin) | 0.5% | 0.25% | 0.75% |
| Partner (Medium Margin) | 1.0% | 0.25% | 1.25% |
| Partner (High Margin) | 1.5% | 0.25% | 1.75% |
5.4 On-Ramp and Off-Ramp - Global
| Direction | Foundation Fee | Partner Margin | Government Tax | Total |
|---|---|---|---|---|
| Foreign → Credits | 0% | 0% – 1.5% | 0.25% – 0.30% | 0.25% – 1.80% |
| Credits → Foreign | 0% | 0% – 1.5% | 0.25% – 0.30% | 0.25% – 1.80% |
Examples:
| Scenario | Partner Margin | Government Tax | Total Cost |
|---|---|---|---|
| Partner (Low Margin) | 0.5% | 0.25% | 0.75% |
| Partner (Medium Margin) | 1.0% | 0.25% | 1.25% |
| Partner (High Margin) | 1.5% | 0.25% | 1.75% |
5.5 B2B/High-Volume On-Ramp and Off-Ramp
| Direction | Foundation Fee | Partner Margin | Government Tax | Total |
|---|---|---|---|---|
| Local → Credits | 0% | 0% – 1.5% | 0.05% – 0.15% | 0.05% – 1.65% |
| Credits → Local | 0% | 0% – 1.5% | 0.05% – 0.15% | 0.05% – 1.65% |
Note: B2B rates apply to transactions above $1M equivalent or for partners processing high annual volumes, subject to agreement with host governments.
5.6 Local Transactions Using Credits (Auto-Convert)
| Fee Component | Rate | Recipient |
|---|---|---|
| Foundation Fee | 0% | Foundation Treasury |
| Partner Processing | 0.1% – 1% | Partner Rail |
| Government Tax | 0.05% – 0.30% | Local Government |
| Total | 0.15% – 1.30% | - |
Critical Clarification:
"When a user selects Credits for a local transaction, Credits convert instantly to local currency in the background. Merchants and billers receive only local currency. Credits are never accepted directly by any merchant, biller, or service provider within the domestic economy. The user sees a simple 'Pay with Credits' option, but the settlement is always in local currency. This ensures Credits remain a bridge layer and never function as a parallel currency."
Notes:
This applies when a user pays a bill, buys groceries, or makes any local purchase using Credits.
Credits convert instantly to local currency in the background.
The user sees a simple payment - the conversion is invisible.
6. PARTNER MARGIN GUIDELINES
6.1 Overview
Partners may add a margin on top of the government tax base for conversions. This margin is how partners earn revenue from the Jowih Credits ecosystem.
Partners have flexibility to structure their margins across different transaction amounts, user tiers, or market conditions. This allows them to compete effectively, attract different user segments, and optimize their revenue.
6.2 Maximum Margin
The maximum partner margin is:
On-ramp/Off-ramp: 1.5% per transaction leg
Local Transactions: 0.1% – 1%
Wallet-to-Wallet Transfers: 0% – 1%
Partners may not exceed these maximums under any circumstance.
6.3 Margin Structuring - Flexibility
Partners may structure their margins in one or more of the following ways:
(a) Tiered by Transaction Amount:
| Transaction Amount | Partner Margin | Total User Cost |
|---|---|---|
| $0 – $100 | 1.0% | Base + 1.0% |
| $101 – $1,000 | 0.8% | Base + 0.8% |
| $1,001 – $10,000 | 0.5% | Base + 0.5% |
| $10,001+ | 0.3% | Base + 0.3% |
This example is illustrative. Partners may set their own tiers within the maximum.
(b) Tiered by User Type:
| User Type | Partner Margin | Total User Cost |
|---|---|---|
| Individual (Standard) | 1.0% | Base + 1.0% |
| Individual (High Volume) | 0.5% | Base + 0.5% |
| SME / Business | 0.4% | Base + 0.4% |
| Corporate | 0.3% | Base + 0.3% |
This example is illustrative. Partners may set their own user tiers within the maximum.
(c) Tiered by Market Conditions:
| Market Condition | Partner Margin | Total User Cost |
|---|---|---|
| Standard | 1.0% | Base + 1.0% |
| Promotional Period | 0.5% | Base + 0.5% |
| High Competition | 0.3% | Base + 0.3% |
| Peak Demand | 1.2% | Base + 1.2% |
This example is illustrative. Partners may set their own market-based margins within the maximum.
(d) Flat Margin:
| Partner Type | Partner Margin | Total User Cost |
|---|---|---|
| M-Pesa | 0.8% | Base + 0.8% |
| Bank | 0.6% | Base + 0.6% |
| PayPal | 0.7% | Base + 0.7% |
This example is illustrative. Partners may set their own flat margins within the maximum.
All tiered structures must be clearly documented and disclosed to users.
6.4 Margin Changes
Partners may adjust their margin structure at any time, subject to:
10 business days' notice to the Jowih Credit Company
5 business days' notice to users before any changes take effect
The new structure remains within the applicable maximums
6.5 Disclosure in agreement with host Governments
Partners must clearly display their margin to users before conversion. The display must include:
Government Tax Base
Partner Margin (and tier details if applicable)
Total Cost
6.6 Transparency Requirement
Partners must ensure that:
Users see the total cost before confirming
The breakdown of fees is clearly shown
Users can compare rates across partners
Users are notified of any changes to margins
7. DOMESTIC SPENDING - AUTO-CONVERSION
| Step | Action | Details |
|---|---|---|
| 1 | Select payment method | Choose "Pay with Credits" |
| 2 | Conversion | Credits convert instantly to local currency in the background |
| 3 | Settlement | Merchant receives local currency |
| 4 | Confirmation | User receives confirmation of payment |
Critical Clarification:
"Credits are never accepted directly by merchants, billers, or service providers. When a user selects 'Pay with Credits,' the Credits convert instantly to local currency in the background. The merchant, biller, or service provider receives only local currency. This ensures Credits remain a bridge layer and never function as a parallel currency within any domestic economy."
Note: The conversion is invisible to the user. They see a simple payment. Credits never enter the domestic economy.
8. HOLDING PERIOD
| Period | Action |
|---|---|
| 0 – 6 months | Normal holding |
| 6 months | Notification to convert |
| 6 months + 1 week | Grace period |
Institutional Extensions:
| Category | Extended Period | Conditions |
|---|---|---|
| Governments | Up to 24 months or as agreed | Development purposes |
| Banks and Financial Institutions | Up to 18 months or as agreed | Liquidity management |
| ADFA Contractors | Project duration + 3 months | Project-related payments |
| Institutional Investors | Up to 18 months | Subject to use case approval |
9. CREDIT-ROUTED FX - DEFINITION
Credit-Routed FX is the Foundation's FX routing mechanism through which Jowih Credits serve as the underlying routing unit between two currencies.
Under Credit-Routed FX, a currency conversion may be processed through the Jowih Credit infrastructure without requiring the customer to acquire or retain Jowih Credits as a visible balance.
The general routing structure is:
Currency A → Jowih Credit Routing Layer → Currency B
The customer-facing transaction may therefore begin and end in the respective local currencies, while Jowih Credits perform the underlying routing function within the system.
Credit-Routed FX is intended to provide an alternative to traditional FX execution for transactions within the applicable Jowih transaction ceiling ($200M per FX-classified transaction).
10. RESERVE MANAGEMENT PROCEDURES
10.1 Reserve Composition
| Reserve Type | Allocation | Assets |
|---|---|---|
| High-Liquid Reserves | 30% – 50% | Cash, gold, short-term government securities |
| Foundation Assets | 50% – 70% | Revenue streams, companies, real estate, ADFA projects |
10.2 Rebalancing
| Trigger | Action | Frequency |
|---|---|---|
| High-Liquid below 30% | Rebalance to 30% minimum | Quarterly or as needed |
| Foundation Assets above 70% | Rebalance to 70% maximum | Quarterly or as needed |
| Market conditions | Adjust allocation within range | As needed |
10.3 Valuation
| Asset Type | Valuation Method | Frequency |
|---|---|---|
| Cash | Actual balance | Daily |
| Gold | Market price | Daily |
| Government Securities available | Market price | Daily |
| Jowih Ecosystem Revenue Streams | Discounted cash flow | Quarterly |
| Jowih Group Companies | Market comparables | Quarterly |
| Real Estate / TND City | Appraisal | Annually |
| ADFA and CDEs Projects | Net present value | Quarterly |
10.4 Audit
| Audit Type | Frequency | Auditor |
|---|---|---|
| Internal Audit | Quarterly | IAG Departments |
| External Audit | Annually | External Auditor Firm |
| Publication | Within 30 days of audit without delay | Public Dashboard |
11. LIQUIDITY PROTOCOLS
11.1 Off-Ramp Liquidity Pools
The Foundation under its company maintains Off-Ramp Liquidity Pools in major African currencies and other major currencies to ensure instant conversion at all times.
| Illustrative Currency | Pool Size | Review Frequency |
|---|---|---|
| KES (Kenya) | Based on historical volume | Quarterly |
| NGN (Nigeria) | Based on historical volume | Quarterly |
| ZAR (South Africa) | Based on historical volume | Quarterly |
| GHS (Ghana) | Based on historical volume | Quarterly |
| XOF (West Africa) | Based on historical volume | Quarterly |
| XAF (Central Africa) | Based on historical volume | Quarterly |
| EGP (Egypt) | Based on historical volume | Quarterly |
| USD | Based on historical volume | Quarterly |
| EUR | Based on historical volume | Quarterly |
| CYN | Based on historical volume | Quarterly |
11.2 Settlement Guarantee Fund
The Foundation maintains a Settlement Guarantee Fund capitalized at 2% of average daily settlement volume.
| Element | Details |
|---|---|
| Purpose | Ensure finality of cross-border trade settlements |
| Capitalization | 2% of average daily settlement volume |
| Held In | High-Liquid Reserves |
| Audit | Subject to same audit requirements as main reserve |
11.3 Liquidity Guarantee
"The Foundation under its company guarantees liquidity for all conversions through a combination of: (i) High-Liquid Reserves maintained at a minimum of 30% of total backing; (ii) Off-Ramp Liquidity Pools in major African currencies and Foreign currencies; (iii) a Settlement Guarantee Fund capitalized at 2% of average daily settlement volume; and (iv) access to Mission Fund backstop for extraordinary demand scenarios. In stress scenarios, the Combined Trusts Board may temporarily adjust pool allocations or draw from the Settlement Guarantee Fund to maintain continuous conversion capability."
11.4 Emergency Liquidity
| Scenario | Action | Highest Authority |
|---|---|---|
| Liquidity shortage | Draw from Settlement Guarantee Fund | Combined Trusts Board |
| Market disruption | Temporary adjustment to pool sizes | Combined Trusts Board |
| Extraordinary demand | Additional allocation from Mission Fund | Combined Trusts Board |
12. GOVERNMENT TAX REMITTANCE
12.1 Overview
The Foundation collects and remits government taxes on all on-ramp and off-ramp conversions. The tax rate is flexible:
| Segment | Government Tax Range | Notes |
|---|---|---|
| Standard (Retail/SME) | 0.25% – 0.30% | Default rate |
| B2B / High-Volume | 0.05% – 0.15% | Subject to agreement with host governments |
| Local Transactions | 0.05% – 0.30% | Jurisdiction-aware |
Flexibility:
Governments may negotiate rates within the defined ranges.
B2B rates apply to transactions above $1M equivalent or for partners processing high annual volumes.
The Credits company Board shall maintain a schedule of approved rates in the Operational Framework subject to approval and recognition from Combined Trust board.
12.2 Tax Collection
| Transaction Type | Who Collects | How |
|---|---|---|
| All Conversions | Partner | Withheld at point of conversion |
12.3 Tax Remittance
| Element | Details |
|---|---|
| Frequency | Monthly |
| Method | Direct transfer to each government's designated account |
| Reporting | Auditable reports provided to each government |
| Currency | Credits converted to local currency at the time of remittance |
12.4 Remittance Schedule
| Period | Collection | Remittance | Deadline |
|---|---|---|---|
| January | Jan 1-31 | February | Last day of February |
| February | Feb 1-28/29 | March | Last day of March |
| March | Mar 1-31 | April | Last day of April |
| ... | ... | ... | ... |
| December | Dec 1-31 | January | Last day of January |
12.5 Reporting
| Report Content | Details |
|---|---|
| Transaction Summary | Number of conversions, total value |
| Tax Collected | Total tax by country |
| Remittance Details | Date, amount, method |
| Audit Trail | Transaction-level data for audit |
12.6 Governments Not Yet Active
For governments not yet integrated with the Foundation's remittance system, taxes shall be held in a dedicated escrow account and remitted upon integration.
13. PARTNER INTEGRATION STANDARDS
13.1 Technical Requirements
| Requirement | Details |
|---|---|
| API Integration | REST API with standard JSON payloads |
| Security | TLS 1.2+, API keys, signed requests |
| Authentication | OAuth 2.0 or equivalent |
| Rate Limiting | As agreed in partnership agreement |
| Uptime | Minimum 99.9% |
13.2 Integration Types
| Type | Description | Use Case |
|---|---|---|
| Full Integration | Complete API integration for conversion, settlement, reporting | Major partners (M-Pesa, banks, Mastercard) |
| Light Integration | Limited API integration for specific use cases | Smaller PSPs, niche fintechs |
| White-Label | Partner-branded interface on Foundation platform | Custom partner solutions |
13.3 Example API Endpoints
| Endpoint | Purpose |
|---|---|
| /v1/conversion/rate | Get current conversion rate |
| /v1/conversion/onramp | Convert local currency to Credits |
| /v1/conversion/offramp | Convert Credits to local currency |
| /v1/transfer | Transfer Credits between wallets |
| /v1/balance | Get wallet balance |
| /v1/report/tax | Submit tax transaction data |
13.4 Security Requirements
| Requirement | Details |
|---|---|
| Data Encryption | All sensitive data encrypted at rest and in transit |
| Access Control | Role-based access control for all systems |
| Audit Logging | Comprehensive audit logs for all transactions |
| Penetration Testing | Annual third-party security assessment |
| Incident Response | Documented incident response plan |
14. USER OPERATIONAL PROCEDURES
14.1 Wallet Operations
14.1.1 Creating a Wallet
| Step | Action | Details |
|---|---|---|
| 1 | Download Super App | Available on iOS and Android |
| 2 | Create account | Email or phone number verification |
| 3 | KYC verification | As required by regulatory compliance |
| 4 | Activate wallet | Instant activation |
| 5 | Choose mode | Auto-Conversion (default) or Holding (optional) or both and switch as needed |
14.1.2 Holding Mode
| Feature | Details |
|---|---|
| Purpose | Hold Credits for future use |
| Default | No - Auto-Conversion is default |
| Opt-In | Yes - users must choose to hold Credits |
| Maximum Period | 6 months (unless extended for institutions) |
| Security | Multi-factor authentication, transaction confirmation |
| Conversion | Convert to local currency at any time |
14.1.3 Auto-Conversion Mode
| Feature | Details |
|---|---|
| Purpose | Instant conversion for spending |
| Default | Yes - default mode for all users |
| Opt-Out | Users may choose Holding Mode instead |
| Conversion | Credits convert instantly to local currency for domestic spending |
| Spending | Users see simple payment - conversion is invisible |
14.1.4 Switching Modes
| Action | How | Effect |
|---|---|---|
| Switch to Holding | Select "Hold Credits" in wallet settings | Credits remain in wallet for future use |
| Switch to Auto-Conversion | Select "Auto-Convert" in wallet settings | Credits convert instantly for spending |
14.2 Conversion Procedures
14.2.1 On-Ramp (Local Currency → Credits)
| Step | Action | Details |
|---|---|---|
| 1 | Initiate conversion | Select "Buy Credits" in Super App PSP or external partner app |
| 2 | Enter amount | Enter amount in local currency |
| 3 | View rate | See government tax + partner margin |
| 4 | Confirm | Authorize the transaction |
| 5 | Complete | Credits are credited to wallet |
14.2.2 Off-Ramp (Credits → Local Currency)
| Step | Action | Details |
|---|---|---|
| 1 | Initiate conversion | Select "Sell Credits" in Super App PSP or external partner app |
| 2 | Enter amount | Enter amount in Credits |
| 3 | View rate | See government tax + partner margin |
| 4 | Confirm | Authorize the transaction |
| 5 | Complete | Local currency is credited to bank or mobile money account |
14.2.3 Domestic Spending (Credits → Local Currency for Spending)
| Step | Action | Details |
|---|---|---|
| 1 | Select payment method | Choose "Pay with Credits" |
| 2 | Conversion | Credits convert instantly to local currency in the background |
| 3 | Settlement | Merchant receives local currency |
| 4 | Confirmation | User receives confirmation of payment |
Critical Clarification:
"Credits are never accepted directly by merchants, billers, or service providers. When a user selects 'Pay with Credits,' the Credits convert instantly to local currency in the background. The merchant, biller, or service provider receives only local currency. This ensures Credits remain a bridge layer and never function as a parallel currency within any domestic economy."
Note: The conversion is invisible to the user. They see a simple payment.
14.3 Wallet-to-Wallet Transfers
| Step | Action | Details |
|---|---|---|
| 1 | Select wallet | Choose a recipient from contacts |
| 2 | Enter amount | Enter amount in Credits |
| 3 | View fee | See 0% – 1% transaction fee (partner-defined) |
| 4 | Confirm | Authorize the transfer |
| 5 | Complete | Credits are transferred instantly |
14.4 Holding Period Enforcement
| Period | Action | Details |
|---|---|---|
| 0-6 months | Normal holding | User may hold Credits |
| 6 months | Notification | User receives notification to convert |
| 6 months + 1 week | Grace period | One-week grace period for conversion |
15. AML/CFT COMPLIANCE
15.1 Responsibility Allocation
"Partners bear primary responsibility for KYC/AML compliance for their customers, including customer identification, verification, and ongoing monitoring. The Foundation provides oversight, monitoring, and reporting infrastructure, including transaction monitoring, sanctions screening, and suspicious activity reporting. The Foundation does not replace partner KYC obligations but ensures compliance with FATF Recommendation 15 and applicable host country laws."
15.2 KYC Requirements
| User Type | KYC Level | Requirements |
|---|---|---|
| Individual (Super App Native) | Level 1 | Name, phone number, ID verification |
| Individual (Partner) | Partner's KYC | As per partner's requirements |
| SME | Level 2 | Business registration, beneficial ownership |
| Wholesale | Level 3 | Full due diligence, source of funds |
| Institution | Level 3 | Full due diligence, regulatory approval |
16. DATA PRIVACY AND SOVEREIGNTY
16.1 Data Ownership
| Data Type | Owner | Purpose |
|---|---|---|
| Customer data | Partner | Partner's business use |
| Transaction data | Foundation | Settlement and reporting |
| Aggregated data | Foundation | Public reporting |
| Analytical data | Foundation | System improvement |
16.2 Data Sharing
| Data Shared | With Whom | Purpose |
|---|---|---|
| Aggregated transaction data | Public | Transparency where needed |
| Tax transaction data | Governments | Tax remittance |
| Anonymized settlement data | Partners | Reconciliation |
| NOT Shared | - | - |
| Individual transaction data | Not shared | Privacy protected |
| Customer personal data | Not shared | Partner owned |
16.3 Data Sovereignty
| Requirement | Details |
|---|---|
| Domestic data | Remains within host country jurisdiction |
| Cross-border data | Anonymized and aggregated |
| Data localization | All sensitive data stored in Africa |
17. NEUTRALITY CLAUSE
"The Foundation shall not favor any currency, jurisdiction, partner, or financial system. All currencies, jurisdictions, partners, and financial systems shall be treated equally and without preference, subject only to regulatory compliance and operational capability. The Foundation shall not engage in currency speculation, market manipulation, or any activity that could be construed as favoring one currency or jurisdiction over another. This neutrality is fundamental to the Foundation's role as a neutral bridge between currencies and systems."
18. DISPUTE RESOLUTION
18.1 User Disputes
| Step | Action | Timeline |
|---|---|---|
| 1 | User submits complaint | Within 30 days of transaction |
| 2 | Foundation investigates | 5-10 business days |
| 3 | Resolution provided | Within 20 business days |
18.2 Partner Disputes
| Step | Action | Timeline |
|---|---|---|
| 1 | Partner submits complaint | Within 30 days of incident |
| 2 | Foundation investigates | 10-15 business days |
| 3 | Escalation to Combined Trusts Board | If unresolved |
| 4 | Binding arbitration | If required |
18.3 Government Disputes
| Step | Action | Timeline |
|---|---|---|
| 1 | Government submits complaint | Within 60 days of incident |
| 2 | Foundation investigates | 15-30 business days |
| 3 | Binding international arbitration | If required |
19. REPORTING SCHEDULES
19.1 Public Dashboard
| Content | Frequency | Purpose |
|---|---|---|
| Reserve composition | Quarterly | Transparency |
| Reserve valuation | Quarterly | Transparency |
| Transaction volume | Monthly | Transparency |
| Tax collected | Monthly | Transparency |
| Tax remitted | Monthly | Transparency |
| Partner performance | Quarterly | Transparency |
| Audit reports | Quarterly | Transparency |
19.2 Government Reports
| Content | Frequency | Purpose |
|---|---|---|
| Tax collected within jurisdiction | Monthly | Compliance |
| Tax remitted within jurisdiction | Monthly | Compliance |
| Transaction summary | Monthly | Transparency |
| Audit trail | Quarterly | Compliance |
19.3 Partner Reports
| Content | Frequency | Purpose |
|---|---|---|
| Conversion volume | Monthly | Performance |
| Fee earned | Monthly | Performance |
| User activity | Monthly | Performance |
19.4 IAG Audit Reports
| Content | Frequency | Purpose |
|---|---|---|
| Reserve audit | Quarterly | Compliance |
| Transaction audit | Quarterly | Compliance |
| Tax remittance audit | Quarterly | Compliance |
| Annual audit | Annually | Comprehensive review |
20. AMENDMENT PROCEDURES
20.1 Amendment Process
| Step | Action | Timeline |
|---|---|---|
| 1 | Proposed amendment | - |
| 2 | Published on Public Dashboard | 30 days minimum |
| 3 | Stakeholder consultation | During notice period |
| 4 | Combined Trusts Board vote | After notice period |
| 5 | Implementation | Immediately after vote |
20.2 Conflict with Constitution
Any amendment that conflicts with Article LIX or any other provision of the Constitution shall be null and void.
CLOSING
Jowih Credits are a non-speculative, asset-backed, government-aligned, partner-friendly digital bridge - never entering the domestic economy, with Auto-Conversion as default, Holding as optional (6 months maximum), partners handling all conversions, the Foundation earning from the Treasury Engine (float) not transaction fees, and built on neutrality, transparency, and regulatory compliance.

