$GIFT Whitepaper

Companion evidence file: EVIDENCE-v1.2.md — anchors and traceability for every [E:...] reference used in this whitepaper.

Notice of supersedure

This whitepaper (version 1.2) is the current authoritative version of the $GIFT crypto-asset whitepaper. It was published on [PUBLICATION-DATE] and replaces and supersedes all versions of the $GIFT whitepaper with a prior date. Where any earlier version remains accessible online, or has been distributed through any channel, that earlier version should no longer be relied upon. Holders and prospective holders should read this in full before making any decision in respect of $GIFT.

The most current version of this whitepaper, together with any amendment notifications issued under Article 12 of Regulation (EU) 2023/1114 (MiCAR), is published by the issuer at https://compliance.utribe.cloud/whitepaper/.

⚠️ Risk warning

Investment in $GIFT may result in the full loss of capital invested. $GIFT is a contractual claim on physical gold held by a custodian. The value of $GIFT, and the ability to redeem it, is subject to counterparty, custody, regulatory, technological and market risks, which are described in §9 of this whitepaper. Past performance of physical gold is not indicative of future returns. Prospective holders should read this whitepaper in full and seek independent legal, tax and financial advice before acquiring $GIFT. $GIFT is not a deposit, is not covered by any deposit-guarantee scheme or investor-compensation scheme, and is not capital-protected.

Plain-language summary (retail-facing)

This summary should be read as an introduction to this whitepaper. A prospective holder should base any decision to acquire $GIFT on the whitepaper as a whole and not on this summary alone. The risk warning set out above and at the head of §9 applies in full and is in accordance with Article 6(5), while this summary is provided in compliance with Article 6(6) of Regulation (EU) 2023/1114 (MiCAR) and is intended to be accessible to retail readers.

What $GIFT is. $GIFT (Gold International Fungible Token) is a digital-asset token issued on a public blockchain. Each $GIFT token represents a contractual claim to one milligram of investment-grade physical gold. The physical gold is held in an allocated and segregated weight account at a third-party vault operated by Sequoyah Vaulting in Copenhagen, Denmark.

Who issues $GIFT in the European Union. Within the European Union, $GIFT is issued by Ubuntu Uhuru s.r.o., a Czech limited liability company that holds a Czech Virtual Asset Service Provider (VASP) trade licence and is registered in the Commercial Register of the Municipal Court in Prague under file number C 406075. Ubuntu Uhuru s.r.o. is part of the Ubuntu Tribe group, whose parent company is Ophir Ubuntu International (Mauritius). The registered offices and director(s) of record of each operative group entity are set out in §10.1.

What the offer looks like. The offer of $GIFT is a continuous public offer (it does not have a calendar end date). It is subject to a hard cap on aggregate outstanding value of five billion euro (EUR 5,000,000,000), in accordance with the issuer's Title II positioning under the European Union (EU) Markets in Crypto Asset Regulations (MiCAR) Article 16(2). The offer commenced on 1 April 2026 and is conducted through the issuer's onboarding flow after successful identity and source-of-funds verification.

How you buy and sell $GIFT. Holders acquire $GIFT directly from the issuer by exchanging fiat currency (EUR, USD or GBP) or supported stablecoins for $GIFT at a price of one milligram of gold per token. The price tracks the market spot price of physical gold. The issuer charges a transaction fee of approximately 1.618% on each purchase, which is displayed to the holder before the transaction is confirmed. Holders may redeem $GIFT against the issuer's reserve at any time; redemption against the issuer is free of charge. Standard blockchain network fees (commonly called "gas fees") apply to on-chain transfers.

The principal risks. The market price of physical gold is volatile and may fall. The value of $GIFT will move with the price of gold and prospective holders may receive an amount on redemption that is materially lower than the amount they paid. The issuer relies on third parties (custodian, technology providers, banking partners) and on the integrity of the underlying blockchain. Self-custody of $GIFT through a third-party wallet exposes the holder to loss of the tokens if the holder loses control of their private keys; the issuer cannot recover tokens lost by the holder in this way. $GIFT is not a deposit. It is not covered by any investor compensation scheme under Directive 97/9/EC. It is not covered by any deposit-guarantee scheme under Directive 2014/49/EU. You may lose the full value of your investment. The principal risks are set out at §9 of this whitepaper and at Part F of the issuer's white-paper notification to the home Member State competent authority [E:WP-GIFT-MICAR-FORM-2026-05].

Your statutory rights. Holders have a permanent right of redemption against the issuer at any time, on the basis described in §6. Other statutory rights that may apply to retail purchasers under MiCAR and applicable national law are described in §10 (Counterparty and Governance) and §6 (Settlement, Mint and Redemption); any limitations on those rights stated in the issuer's Terms and Conditions are also disclosed there. You should read §9 (Risks) and §10 (Counterparty and Governance) before deciding to acquire $GIFT.

Where to find more information. The full whitepaper, including the methodology for Proof-of-Reserves (§5), the smart-contract architecture (§7), the issuer's group structure (§10), the wind-down framework that protects holders if any operative entity ceases activity (§11), the forward-looking regulatory expansion (§12), and the evidence references (§13), should be read in full before making any decision to acquire $GIFT. Holders and prospective holders are encouraged to talk to your independent legal, tax, and financial advisor about $GIFT.

1. Executive Summary

$GIFT (Gold International Fungible Token) is a fully gold-backed digital token issued by licensed Ubuntu Tribe entities and audited by HT Digital Ltd. Each $GIFT represents a contractual claim, between the issuer and the holder, to one milligram of investment-grade gold held in allocated, segregated weight-account custody at Sequoyah Vaulting in Copenhagen, Denmark. The legal holder of the gold is Ophir Ubuntu International (the Mauritius-registered parent entity of the Ubuntu Tribe group); this entity holds the gold for the benefit of $GIFT token holders.

Supply is fully reserve-backed and verifiable. $GIFT is minted only on receipt of physical gold attested through Proof-of-Reserves (PoR); it is burned on redemption; there is no pre-mint and no inflationary supply mechanism (no new $GIFT is created without matching physical gold being added to the reserve). The on-chain circulating supply (Proof of Circulating Supply, PoCS) and the underlying physical-gold reserve (PoR) are independently attested by HT Digital Ltd. on a quarterly cadence; on-chain it is directly verifiable by any reader through public Polygon Mainnet endpoints (§5).

Pricing is transparent and externally-anchored. The price of $GIFT in fiat is the prevailing market price of gold (the gold spot price), converted at the moment of each transaction using a published methodology disclosed in full at §3.7. The peg ratio (1 $GIFT = 1 milligram of gold) is fixed by the smart contract and is not subject to operational discretion.

Holder protection is built in. Every $GIFT transaction made through the uTribe application is screened before it reaches the blockchain. The token is paired with an on-chain compliance registry that records each holder's verified identity, the results of sanctions and Politically Exposed Person screening, and the spending limits that match the holder's verification tier. Transactions that fail any of these checks are blocked at the application layer (§8). If any Group entity ceases activity in your jurisdiction, your claim on the gold is preserved — you may redeem against the issuer's reserve or your account may be migrated to another licensed Group entity (§11).

Issuance is operated through licensed Group entities in multiple jurisdictions. European Union access is operated through a Czech Virtual Asset Service Provider (VASP) [E:LIC-2026-003]; while the Group is anchored under its Financial Services Commission of Mauritius authorisation [E:LIC-2026-001]. Additional authorisations are progressing in the United Arab Emirates (VARA), Nigeria (SEC ARIP), Kenya (Capital Markets Authority), Ghana (Bank of Ghana / SEC Ghana), and Luxembourg (CSSF), each of which — on grant — extends the token holder's protections (a supervisory authority, a licensed local entity, a defined complaints pathway, a defined wind-down pathway) into the respective jurisdiction (§12).

Independent verification is published and reproducible. The full engineering reference for the on-chain Proof-of-Reserves and Proof-of-Circulating-Supply attestation, including the function inventory and a verification script that any auditor or holder may run independently, is published at https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit. The token contract address — 0xCfde7c43EDB3c9f71331AAc1003b099CE40c94ea on Polygon Mainnet (chain identifier 137) — is the canonical reference for any independent verification.

Cross-references: §2 Token Description; §3.7 Pricing methodology; §4 Reserves and Custody; §5 Proof of Reserves and Proof of Circulating Supply; §8 Compliance and KYC/AML; §10 Counterparty and Governance; §11 Wind-down, Migration, and Holder Protection; §12 Forward-Looking Regulatory Expansion. For the source of every claim in this document, see §13 Evidence Availability and Access.

2. Token Description

$GIFT is an ERC-20 token deployed on Polygon Mainnet (chain ID 137) [E:CHAIN]. The canonical contract is at 0xCfde7c43EDB3c9f71331AAc1003b099CE40c94ea [E:GIFT-CONTRACT]. ERC-20 metadata returned by the contract:

The display unit is the raw uint256 divided by 10^18.

Token economics at the contract level. $GIFT is minted only on receipt of physical gold attested in Proof-of-Reserves, and is burned on redemption. There is no pre-mint and no inflationary supply mechanism [E:GOLD-PER-TOKEN-RATIO]. The gold-per-token ratio is a contractual commitment between the issuer and the holder: one $GIFT represents one milligram of investment-grade gold [E:GOLD-PER-TOKEN-RATIO]. The ratio is enforced at the application and reserve-verification layer; it is not a property of the ERC-20 contract itself, and is not asserted on chain.

Compliance gating contract. A separate ComplianceRegistry contract at 0xfa0bf4c2dbfb147f13127dd99712db0ea2b5b415 holds per-wallet compliance state (whitelist flag, KYC tier, freeze flag, spend buckets) [E:COMPLIANCE-REGISTRY-CONTRACT] [E:KYC-STATE-FIELDS]. uTribe application-layer policy requires a Know-Your-Customer (KYC) approval prior to any wallet participating in $GIFT transactions [E:KYC-PARTICIPATION-FLOOR]. There is a ComplianceRegistry smart contract function that is the on-chain authority on per-wallet compliance status (§8). This allows any reader (including auditors, regulators, partners, or exchanges) to use the blockchain to determine if a specific wallet account address has passed KYC before interacting with it.

Cross-references: §3 Tokenomics; §5 Proof of Reserves; §7 Smart-Contract Architecture; §8 Compliance and KYC/AML; §10 Counterparty and Governance.

3. Tokenomics

3.1 Supply mechanics

$GIFT supply is fully dynamic and reserve-gated:

• Mint: a new $GIFT is created only upon receipt of physical gold into custody, verified through Proof-of-Reserves (§5) [E:GOLD-PER-TOKEN-RATIO] [E:RESERVE-COVERAGE-DYNAMIC]. The mint pipeline programmatically gates issuance on reserve verification: if minting would breach the minimum reserve-coverage floor, the platform refuses the mint [E:RESERVE-COVERAGE-DYNAMIC].
• Burn: $GIFT is burned on redemption against physical bullion (for qualifying tickets) or fiat-equivalent disbursement through integrated payment rails [E:REDEMPTION-FLOW].
• No pre-mint. No initial allocation, founder allocation, treasury reserve, or inflationary issuance mechanism exists at the contract level. Every unit of supply corresponds to physical gold attested at the moment of mint.
• Backing ratio. One $GIFT corresponds contractually to one milligram of investment-grade gold [E:GOLD-PER-TOKEN-RATIO].

3.2 Fee schedule

The current fee schedule, as in force on the date of this document, is:

All fees are disclosed to the user before each transaction is confirmed.

3.3 Fee allocation

Fee revenue funds operations, ecosystem development, reserve growth, and a ring-fenced community-impact carve-out [E:FEES-ALLOCATION]. The community-impact component is ring-fenced at 10% of transaction-fee revenue and is directed to education, mining-community programmes, and financial-inclusion initiatives [E:FEES-ALLOCATION].

3.4 Reserve-coverage dynamic

Every mint operation is gated by reserve verification confirming sufficient unallocated reserve balance before minting can proceed [E:RESERVE-COVERAGE-DYNAMIC]. The verification reads on-chain $GIFT supply directly (§5) and reconciles it against custodian-attested physical-gold balance. If issuance would breach the minimum coverage floor, the $GIFT platform refuses the mint [E:RESERVE-COVERAGE-DYNAMIC]. The reverse holds on burn: the corresponding reserve becomes available for redemption settlement.

3.5 Relevant operational parameters

3.6 Regulatory characterisation note

The regulatory characterisation of $GIFT differs by regime and is not uniform across all the jurisdictions in which Ubuntu Tribe operates. At the Group level, $GIFT is technically architected as an Asset-Referenced Token (ART) under MiCA — a crypto-asset that purports to maintain stable value by referencing a commodity (in this case, allocated physical gold). The final regulatory characterisation under each regime — including whether $GIFT falls within asset-referenced token, electronic money token, commodity-referenced instrument, security token, or another category — is subject to the determination of the competent supervisory authority in that regime.

Where this document refers to $GIFT being engineered to satisfy a particular regulatory framework, that engineering position is not an assertion of regulatory approval. Approvals are stated only where actively held licences are in evidence (§10, §12 Forward-Looking Regulatory Expansion).

The per-regime expected characterisation, the supervising authority, the responsible Group entity, and the operational status of each jurisdiction are set out by jurisdiction in Appendix D §D.8 (Regulatory characterisation per jurisdiction): §D.8.1 European Union [E:LIC-2026-003] [E:LIC-2026-011] [FORWARD-LOOKING for LIC-2026-011], §D.8.2 United Arab Emirates [E:LIC-2026-004] [FORWARD-LOOKING], §D.8.3 Nigeria [E:LIC-2026-007] [FORWARD-LOOKING], §D.8.4 Luxembourg [E:LIC-2026-012] [FORWARD-LOOKING], and §D.8.5 Other jurisdictions.

3.7 Pricing methodology [E:PRICING-METHODOLOGY]

The price at which $GIFT is offered to holders is a methodology-based price, derived from the market spot price of physical gold, and is not a fixed nominal issue price.

3.7.1 The peg

The contractual claim represented by one $GIFT is fixed at one milligram of investment-grade physical gold (see §3.1 and §4). The fiat-equivalent purchase price for one $GIFT at any given moment is therefore a function of (a) the prevailing market spot price of one milligram of investment-grade gold, expressed in the holder's settlement currency, plus (b) the transaction fees described at §3.2 and §3.7.3 below.

The peg ratio (1 token = 1 mg of gold) is fixed by the smart contract and is not subject to operational discretion; the price expressed in fiat (the issue price for a given subscription) is derived at the moment of the transaction and varies with the gold market.

3.7.2 Reference gold spot price

The issuer derives the operational issue price for each subscription from the market spot price of physical gold published by external market-data providers. The issuer's gold-price reference uses pricing based on multiple sources (FOREX, SAXO, OANDA, and IDC Exchanges), along with the Chainlink XAU/USD aggregator on Polygon Mainnet at 0x0C466540B2ee1a31b441671eac0ca886e051E410 as fallback. The Chainlink reference is a gold-price oracle for fiat-equivalent valuation.

The issuer's controls include the use of more than one independent pricing source and a documented price-tolerance band; if the divergence between sources exceeds the tolerance band, or if all sources becomes unavailable or stale, the issuer pauses primary-market quoting until the issue is resolved.

At the moment of transaction confirmation by the holder, the holder is presented with the fiat-equivalent purchase price derived from the then-current spot reading and the fee schedule. The price is binding on the issuer for the price-validity window after the holder confirms.

The issuer does not assert in this whitepaper that the operational pricing-source configuration as in force at the time of any individual transaction will be identical to the configuration in force at the time of this whitepaper's publication; the configuration may change over time in response to source availability, market conditions, and supervisory expectations. Material changes are addressed by amendment under MiCAR Article 12 (see §13 of this whitepaper).

3.7.3 Currency conversion at settlement

Where the holder's settlement currency differs from the denomination currency of the spot-price source (for example, the holder settles in EUR but the spot is quoted in USD), the issuer applies the rate published by the issuer's fiat-conversion partner at the moment of the transaction. The applicable rate is displayed to the holder, together with any spread or fee for the currency conversion, before transaction confirmation. The methodology is consistent with the foreign-exchange risk noted at §9 row 10.

3.7.4 Pricing on redemption

On redemption against the issuer, the holder receives either physical bullion (for qualifying tickets) or a fiat-equivalent disbursement through an integrated payment rail. The fiat-equivalent disbursement is calculated by the same spot-price methodology described at §3.7.2 (subject to the redemption-queue mechanics at §6), at the moment the redemption is processed, less any rail-specific costs imposed by the issuer's fiat-partner panel (which are disclosed before redemption confirmation). The statutory redemption right exercised against the issuer is free of issuer-side charge.

3.8 Total number of crypto-assets to be issued [E:SUPPLY-MODEL]

3.8.1 Elastic-supply, reserve-gated model

The $GIFT token does not have a pre-determined fixed maximum supply at the smart-contract level. Supply is elastic, reserve-gated, and deflationary on redemption. The supply mechanics are:

• Mint. A new $GIFT is created only upon receipt of physical gold into custody, verified through Proof-of-Reserves (§5). The mint pipeline programmatically gates issuance on reserve verification: if minting would breach the minimum reserve-coverage floor, the platform refuses the mint.
• Burn on redemption. $GIFT is burned on redemption against physical bullion (for qualifying tickets) or fiat-equivalent disbursement through integrated payment rails.
• Burn for reserve reconciliation. Where the underlying reserve is reduced by custodian fees, the issuer is able, under its documented Burn Process, to burn an equivalent number of $GIFT to maintain the 1 $GIFT = 1 mg gold peg.
• No pre-mint or inflationary issuance. No founder allocation, treasury reserve, or scheduled inflation exists at the smart-contract level. Every unit of supply in circulation corresponds to physical gold attested at the moment of mint.

3.8.2 EU public-offer perimeter and the EUR 5,000,000,000 cap

The EU public offer of $GIFT through Ubuntu Uhuru s.r.o. (Czech VASP LIC-2026-003) commenced 1 April 2026. The offer is structured as a continuous public offer under Article 4 of Regulation (EU) 2023/1114 and is subject to the Article 16(2) exemption threshold: the aggregate outstanding value of $GIFT issued under the EU public offer shall not exceed EUR 5,000,000,000 at any time.

The EUR 5,000,000,000 cap applies to the EU public-offer perimeter only. $GIFT issued under non-EU operative perimeters (including Ophir Ubuntu International under Mauritius FSC authorisation, and other Group operative entities under their respective non-EU authorisations) and $GIFT minted to the issuer's group treasury are not within the EU public-offer perimeter, are not offered to the EU public, and are not counted against the EU offer cap.

Where this whitepaper refers to a "current supply" figure (§3.8.3 below), the figure is the on-chain totalSupply() of the $GIFT ERC-20 contract on Polygon Mainnet aggregated across all operative perimeters. The proportion of that supply that is held under the EU public offer is materially smaller than totalSupply() and is the subject of the issuer's separate Proof of Circulating Supply attestation (§5).

3.8.3 Live supply figure at publication

3.8.4 Attestation

The issuer's external auditor (HT Digital Ltd.) attests on a quarterly basis to both the Proof of Reserves (PoR — the amount of physical gold held in allocated custody at the issuer's custodian) and the Proof of Circulating Supply (PoCS — the subset of totalSupply() held by external holders versus the issuer's treasury). The dual PoR + PoCS attestation framework is the agreed scope for the issuer's March 2026 audit and, commencing June 2026, quarterly audits expand to a SOC 2 Type II covering the issuer's token-management processes (issue, redeem, burn, custody, KYC) in addition to reserve and circulating-supply attestation.

3.9 Intended use of proceeds [E:USE-OF-PROCEEDS]

Allocation of funds from issuance. The gross proceeds raised from the public offer of $GIFT are allocated strictly to the acquisition and maintenance of the reserve assets. Because $GIFT is a digital-asset where 1 token is equivalent to 1 milligram of investment-grade gold, the funds corresponding to the nominal value of the issued tokens are used to purchase physical gold to ensure 100% backing of the circulating supply.

Reserve management. The allocation ensures that the digital tokens remain fully collateralised by physical-gold reserves at all times. These reserve assets are legally and technically segregated from the issuer's own assets and are not accessible to the issuer's creditors. The custody, allocation, and attestation of the reserve are described at §4 (Reserves and Custody) and §5 (Proof of Reserves).

Operational costs and fees. The costs associated with the operation of the project (including technological infrastructure, legal compliance, marketing, and staff) are not deducted from the reserve assets. Operational costs are covered by:

1. The issuer's own funds. The issuer maintains prudential guarantees and capital reserves to cover operational volatility, in accordance with the capital requirements applicable to the issuer under its licence.
2. Transaction fees. The issuer charges the transaction fees described at §3.2 and §3.7. Transaction-fee revenue supports operational sustainability.

Cross-references: §4 Reserves and Custody; §5 Proof of Reserves; §6 Settlement, Mint and Redemption; §11 Wind-down, Migration, and Holder Protection; §12 Forward-Looking Regulatory Expansion.

4. Reserves and Custody

$GIFT is fully backed by physical gold held in allocated, segregated custody at Sequoyah Vaulting in Copenhagen, Denmark, and independently attested by HT Digital Ltd.

Sequoyah Vaulting is the safe-custody and precious-metals vaulting arm of Sequoyah Wealth Management (part of the Sequoyah Group, founded in 2001 and headquartered at Østerbrogade 137, DK-2100 Copenhagen, Kingdom of Denmark). It operates a private underground vault facility in Copenhagen and is registered with the Danish Financial Supervisory Authority (Finanstilsynet) under Danish anti-money-laundering legislation, supervised by the Danish Financial Control Authorities, and inspected by leading Danish insurance underwriters covering the facility [E:CUSTODIAN] [E:SEQUOYAH-WEBSITE-2026-06-04]. The Issuer Group's gold is held in an allocated and segregated weight account, identified to Ophir Ubuntu International (the legal holder of the reserve, for the benefit of $GIFT holders) and segregated from both Sequoyah's house book and other clients' holdings. The custodian's Danish CVR number (38 83 87 84) and registered office address are recorded in the custody-holding table at §4.1; the specific Finanstilsynet supervisory identifier and the named insurance underwriters are not embedded in this whitepaper and are available to regulators, auditors, and qualifying counterparties upon request [E:CUSTODY-DISCLOSURE]. The custody arrangement is the subject of the in-vault physical-count work documented in the Issuer's Proof-of-Reserves evidence chain [E:CROWE-ISRS-4400-2026-03] [E:CUSTODY-HOLDING].

Independent external attestation is provided by HT Digital Ltd. (registered number 15205809), a London-based chartered-accountancy and registered-auditor firm operating within a group of London-based chartered-accountancy practices that has been providing professional accountancy services for over eighty years. HT Digital Ltd. provides the on-chain Proof-of-Reserves and Proof-of-Circulating-Supply attestation framework for $GIFT (see §5), including independent verification of the physical bullion held at Sequoyah Vaulting in Copenhagen. For the 16 March 2026 attestation window, the in-vault physical-count procedures were carried out at Hellerup, Denmark, by Crowe Statsautoriseret Revisionsinteressentskab v.m.b.a. (a Danish State Authorised Public Accountant firm, CVR 33 25 68 76) [E:CROWE-ISRS-4400-2026-03].

4.1 Custody arrangement

The physical gold backing $GIFT is held under a single active custody holding (HOLD-GIFT-SEQ-CPH-AU-001) characterised as follows [E:CUSTODY-HOLDING]:

The custody arrangement is allocated and segregated. The bullion is identified to the legal holder for the benefit of token holders; it is not commingled with the custodian's house book or with general operator assets [E:CUSTODY-HOLDING] [E:CUSTODY-ROLES].

4.2 Custodian roles

Three distinct custody roles attach to the holding [E:CUSTODY-ROLES]:

4.3 Balance disclosure

Per the audience disclosure policy [E:CUSTODY-DISCLOSURE]:

• Custodian identity, vault location, legal-holder identity, asset type and form, and applicable custodian certifications are disclosed (see §4.1).
• Balance quantities, balance valuations, account identifiers, banking details, custody-chain history, and transport-partner specifics are not disclosed in this document. See live Proof-of-Reserves page or latest HT Digital Ltd. attestation for balance figures [E:CUSTODY-DISCLOSURE] [E:BALANCE-LATEST-CADENCE].

4.4 Transport and physical redemption

Physical-redemption shipments are handled through regulated armoured-transport providers, contracted per shipment under standard precious-metals carriage terms [E:TRANSPORT]. Per-shipment counterparty specifics are not disclosed in this document; counterparty diligence is shared under engagement NDA on request.

4.5 Audit cadence and reproduction

HT Digital Ltd. independently reproduces both the on-chain reserve read (totalSupply()) and the on-chain compliance-state reads against the public Polygon Mainnet chain; HT Digital Ltd. independently reconciles the on-chain $GIFT supply, after application of the contractual gold-per-token ratio, to the custodian-attested physical-gold balance. The reproduction procedure is documented in the auditor-grade methodology reference [E:HT-DOC-AUDITOR-REFERENCE] [E:HT-DOC-KYC-PROCEDURE] [E:HT-DELIVERY]:

The published cadence of HT Digital Ltd.'s external attestation is quarterly [FORWARD-LOOKING] [E:HT-AUDIT-CADENCE].

Cross-references: §5 Proof of Reserves; §10 Counterparty and Governance.

5. Proof of Reserves and Proof of Circulating Supply

The $GIFT attestation framework comprises three complementary verifications, each independent of the others: (i) Proof of Reserves (PoR) — verification that the physical-gold reserve held at the custodian is sufficient to back the on-chain supply, performed by HT Digital Ltd. through independent inspection of the bullion at Sequoyah Vaulting; (ii) Proof of Circulating Supply (PoCS) — verification of the on-chain supply itself, performed through deterministic, read-only operations against the Polygon Mainnet eth_call interface and independently attested by HT Digital Ltd.; and (iii) reconciliation — the cross-check that the independently verified physical balance matches or exceeds the independently verified on-chain supply, performed by HT Digital Ltd. as the appointed Group auditor.

The on-chain side is directly verifiable by any reader through public Polygon JSON-RPC endpoints, with no oracle dependency. The physical side is verified through HT Digital Ltd.'s independent inspection of the bullion at Sequoyah Vaulting in Copenhagen and is not relayed from a custodian-prepared statement. The full engineering reference, including a public verification script, is published at https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit [E:PUBLIC-ENGINEERING-REF] [E:HT-PUBLIC-COMPANION].

5.1 On-chain verification (the supply side) — Proof of Circulating Supply

The on-chain side of the attestation is the Proof of Circulating Supply (PoCS). It consists of deterministic, read-only eth_call operations against contracts deployed on Polygon Mainnet (chain ID 137) [E:CHAIN] [E:GIFT-SUPPLY-METHOD]. Two contracts are read:

The ComplianceRegistry contract was deployed on April 20 2026, consolidating two predecessor V1 contracts (the V1 KYC Registry and the V1 Whitelist Registry) that performed the equivalent compliance-gating function prior to that date; the predecessor V1 architecture and the migration to ComplianceRegistry are documented in TECH-POR-AUDITOR-002 for audits whose attestation window precedes 2026-04-20 [E:HT-DOC-AUDITOR-REFERENCE].

The supply read is:

eth_call → totalSupply()  uint256

Decoded with decimals() = 18, the return is the total $GIFT supply in display units [E:GIFT-DECIMALS] [E:GIFT-SUPPLY-METHOD].

5.2 Independent-RPC cross-check

The supply-read is reproducible across multiple independent public JSON-RPC endpoints. The following endpoints have been confirmed to serve the read; anyone may use any equivalent Polygon Mainnet archive RPC:

Endpoint availability is provider-dependent and may change over time. The substantive verification is that the same raw totalSupply() value is returned at the same block height by any compliant Polygon Mainnet node; anyone that wishes to eliminate third-party-RPC dependency entirely may run a Polygon full-archive node locally and read directly. Cross-RPC consistency at a fixed block height is the cryptographic verification.

5.3 KYC-state reconciliation (the policy side)

In parallel with the supply-side verification described in §5.1 and §5.2, every wallet that holds $GIFT is checked, on the blockchain itself, against three Know-Your-Customer (KYC) requirements:

• The wallet has been admitted to the compliance whitelist.
• The wallet has reached the minimum KYC tier required to transact in $GIFT.
• The wallet is not subject to an administrative freeze (sanctions, suspicious-activity hold, or customer request).

A single read of the ComplianceRegistry smart contract returns all three statuses for any wallet address. The check is read-only — it does not move tokens and does not change any state — so any reader (including a regulator or an auditor) can perform it independently of uTribe and of the custodian.

For each wallet that uTribe records as KYC-verified in its off-chain customer database, the on-chain status must satisfy all three requirements at the same time, and the wallet must be eligible to transact at the participation tier. Any deviation is recorded before the verification run is reported as clean [E:HT-DOC-KYC-PROCEDURE].

During reference run (2026-05-21, Polygon Mainnet blockchain head block 87,236,996): a sample of 109 wallets were verified; 109 of 109 matched the expected profile; zero deviations [E:HT-DOC-KYC-PROCEDURE]. The same procedure is repeated by HT Digital Ltd. as the independent attestor.

The engineering-level field reference (contract field names, data types, exact on-chain return values, and the parameterised canTransact(address, amountUSD, minLevel) simulation call) is provided in Appendix C for technical readers and auditors.

5.4 Physical-side verification and reconciliation — Proof of Reserves

The physical-side work performed by HT Digital Ltd. is the Proof of Reserves (PoR) and has two independent components [E:GOLD-PER-TOKEN-RATIO] [E:CUSTODY-HOLDING] [E:HT-DOC-AUDITOR-REFERENCE]:

1. Independent verification of the physical gold itself. HT Digital Ltd. does not merely take Sequoyah Vaulting's signed weight-account statement at face value. HT Digital Ltd. independently inspects the physical bullion held at Sequoyah Vaulting (Copenhagen) on a contracted cadence, confirms the weight of the holding by direct measurement, and confirms that the inspected bars are segregated for and allocated to the legal holder (Ophir Ubuntu International) for the benefit of $GIFT holders. This is an independent physical attestation by the auditor, not a relayed claim from the custodian.

2. Reconciliation of the verified physical balance to on-chain supply. HT Digital Ltd. then reconciles the independently verified physical-gold balance to the on-chain totalSupply() of $GIFT, after applying the contractual gold-per-token ratio (one $GIFT = one milligram of investment-grade gold). The substantive Proof-of-Reserves outcome is that the on-chain $GIFT supply does not exceed the independently verified, allocated, segregated physical reserves.

The combination of (1) and (2) is what distinguishes an Enterprise-grade Proof of Reserves from a self-attested reserve claim: an independent auditor has seen and weighed the gold, not merely accepted a written statement that it exists.

5.5 Independent reproduction

Anyone can reproduce the supply-side verification independently of Ubuntu Tribe and independently of HT Digital Ltd. The materials required are public:

1. The two contract addresses in §5.1.
2. A Polygon Mainnet JSON-RPC endpoint (QuikNode public, Alchemy, or any equivalent compliant archive-capable endpoint; a self-hosted Polygon full-archive node may also be used).
3. The verification script verify_kyc.py and the supporting engineering reference at https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit [E:PUBLIC-ENGINEERING-REF] [E:HT-PUBLIC-COMPANION].

A change in totalSupply() between two reads at different chain heads is interpreted as follows [E:HT-DOC-AUDITOR-REFERENCE]:

5.6 What the Proof-of-Reserves and Proof-of-Circulating-Supply attestation is not

The PoR, PoCS, and reconciliation framework does not depend on a third-party price oracle, a third-party reserve oracle, or any centralised data feed. The PoCS is verified through deterministic public-RPC reads. The PoR is verified through HT Digital Ltd.'s independent inspection of the physical bullion at Sequoyah Vaulting and is not relayed from a custodian-prepared statement. The reconciliation between the independently verified physical balance and the independently verified on-chain supply is performed by HT Digital Ltd. as the appointed Group auditor. RPC-availability risk on the PoCS side is mitigated by the existence of multiple independent public and enterprise-SLA quality endpoints (§9).

Cross-references: §2 Token Description; §3 Tokenomics (reserve-coverage dynamic); §4 Reserves and Custody; §7 Smart-Contract Architecture; §9 Risk Factors.

6. Settlement, Mint and Redemption

6.1 Mint flow

1. Customers onboard through the relevant licensed Ubuntu Tribe entity (e.g. Ubuntu Uhuru s.r.o. for European Economic Area (EEA) access [E:LIC-2026-003]); KYC tier reached must satisfy the participation floor (kycLevel ≥ 1 to transact, kycLevel ≥ 2 for any single transaction of USD $1,000 or more; institutional investors are typically onboarded at kycLevel = 3). The KYC tier is recorded in the on-chain ComplianceRegistry [E:KYC-PARTICIPATION-FLOOR].
2. A customer funds the purchase in a supported rail — fiat (where supported), stablecoin (USDC, USDT, etc.), or native crypto (POL) [E:SETTLEMENT-PARAMETERS] [E:GAS-ADVANCE].
3. Reserve verification confirms sufficient unallocated reserve balance ahead of mint [E:RESERVE-COVERAGE-DYNAMIC].
4. The gold-issuance premium ("buy-in") of up to 5% is applied at the point of mint [E:FEES-BUY-IN].
5. $GIFT is minted to the customers whitelisted Polygon address against the corresponding physical-gold reserve increase. The customer holds $GIFT in a self-custodial wallet on Polygon Mainnet.

6.2 Redemption flow

1. A customer can submit a redemption request through the issuer counterparty via the $GIFT app (https://gift.utribe.app/).
2. Proof-of-Reserves verification is performed against the request volume [E:REDEMPTION-FLOW].
3. The customer's $GIFT is burned on chain, reducing totalSupply() by the redeemed amount.
4. Disbursement is made either as physical bullion delivery (for qualifying tickets, via regulated armoured-transport providers [E:TRANSPORT]) or as fiat-equivalent disbursement through an integrated payment-services-provider rail [E:REDEMPTION-FLOW].

6.3 Operational parameters disclosed at Liquidity Provider (LP) onboarding

The following parameters are LP-specific and are agreed at onboarding rather than asserted in this document at fixed values:

LPs should treat these parameters as part of the bilateral onboarding documentation rather than as fixed terms in the standard $GIFT documentation.

6.4 Subscription period and offer conditions [E:OFFER-PERIOD]

The public offer of $GIFT is structured as a continuous offer with no fixed end date, subject to the regulatory cap described at §3.8 and below.

The issuer's offer is a continuous public offer (i.e. it has no calendar end date), but its aggregate value is capped at EUR 5,000,000,000 outstanding in the EU. The offer will terminate, on a value basis, when the aggregate outstanding value of $GIFT reaches that cap. Further offering capacity beyond the cap is subject to the additional regulatory steps described at §12 (Forward-Looking Regulatory Expansion).

Adjustments to the start date, the cap, or the conditions of participation will be made by amendment to this whitepaper in accordance with MiCAR Article 12 (whitepaper amendments) and re-notified to the home Member State competent authority where applicable.

Cross-references: §3 Tokenomics; §4 Reserves and Custody; §5 Proof of Reserves; §8 Compliance and KYC/AML; §9 Risk Factors.

7. Smart-Contract Architecture

7.1 Deployed contracts

Both contracts are deployed on Polygon Mainnet (chain ID 137) [E:CHAIN]. The token contract responds to standard ERC-20 view calls; eth_getCode against each address returns non-empty bytecode [E:GIFT-SUPPLY-METHOD] [E:COMPLIANCE-REGISTRY-CONTRACT].

7.2 Upgrade model and access control

The contracts implement a Universal Upgradeable Proxy Standard (UUPS, ERC-1822) upgradeable proxy pattern with AccessControl-based role management and pausable behaviour for incident response. Function-dispatch evidence on the legacy V1 contract included selectors consistent with this pattern (upgradeToAndCall, proxiableUUID, hasRole, DEFAULT_ADMIN_ROLE, paused) [E:HT-DOC-AUDITOR-REFERENCE]. Upgrade authority is held by a multi-signature controller subject to a mandatory time-lock; this controller is the only address authorised to execute proxy upgrades, and the time-lock is the in-protocol observation window between an upgrade proposal and its execution.

The ComplianceRegistry exposes the role accessors (hasRole(bytes32, address), getRoleAdmin(bytes32)) standard to AccessControl-based contracts, supporting the segregation of duties between policy-update administrators and reading/auditing operators [E:HT-DOC-KYC-PROCEDURE].

7.3 Public engineering reference

The canonical engineering reference — function inventory, calldata layout, return decoding, event signatures, and the verification script — is published at:

https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit

The repository is public and is the engineering source of truth for on-chain interaction with the $GIFT contracts [E:PUBLIC-ENGINEERING-REF] [E:HT-PUBLIC-COMPANION].

7.4 Consensus mechanism — environmental and climate impacts

7.4.1 Scope of this disclosure

This section addresses the principal adverse environmental and climate impacts associated with the consensus mechanism used by the blockchain on which $GIFT is issued. It is provided as an accredited investor-grade summary of currently available public information about the Polygon Mainnet consensus mechanism (chain identifier 137) [E:CHAIN]. The data points are drawn from publicly available sources cited below.

This section is information of the kind required by Article 6 of Regulation (EU) 2023/1114 (MiCAR) for crypto-assets that may be offered to the public in the European Union. Concrete quantitative fields and the precise structured-data format will be aligned with the final regulatory technical standards / implementing technical standards (RTS/ITS) once published by the European Securities and Markets Authority and the European Banking Authority.

7.4.2 Consensus mechanism

$GIFT is issued on Polygon Mainnet (chain identifier 137). Polygon Mainnet operates a delegated Proof-of-Stake (dPoS) consensus mechanism with two co-operating layers:

The consensus mechanism is not Proof-of-Work; block production does not perform computational puzzle-solving and is not designed to consume energy as a function of competitive hashing. Energy and emissions therefore scale primarily with the number of active validators and their infrastructure footprint, not with transaction throughput on the network.

7.4.3 Energy consumption and greenhouse-gas emissions — chain perimeter

The quantitative anchor for this disclosure is the Update Report — The Energy Efficiency and Carbon Footprint of the Polygon Blockchain published in October 2022 by the Crypto Carbon Ratings Institute (CCRI), commissioned by Polygon Technology [S1]. CCRI's earlier September 2022 baseline report [S2] is the source of the underlying Polygon PoS layer-2 figures; the October 2022 Update Report refines the post-Ethereum-Merge layer-1 allocation following Ethereum's transition to Proof-of-Stake on 15 September 2022.

Fields below correspond to those expected under the MiCAR regulatory technical standards (RTS) / implementing technical standards (ITS) for consensus-mechanism environmental disclosures. Where a field is not directly reported in the cited sources, the entry reads [NOT YET PUBLISHED]. Figures are stated as published; uTribe has not independently verified them.

The June 2022 retirement figure relates to the network's cumulative greenhouse-gas footprint up to that date, principally attributable to the pre-Merge Ethereum-layer-1 allocation. It is presented here as a historical disclosure and does not constitute a representation that current-state Polygon Mainnet emissions are subject to ongoing offsetting. The network's current-state emissions are stated separately above and are reported without an applied offset.

7.4.4 Issuer-level environmental and climate impacts

In addition to the chain-perimeter disclosure above, MiCAR Article 6 and the ESMA draft regulatory technical standards on Article 6(11) call for an issuer-level disclosure of environmental and climate impacts associated with the issuer's own operations supporting the crypto-asset offering. The issuer of $GIFT for the European Union perimeter is Ubuntu Uhuru s.r.o. (Czech VASP LIC-2026-003, LEI 894500B0BCJDDPCC5346). This sub-section sets out the corresponding issuer-level information. The fields below mirror the structure of the Article 6 / Annex environmental fields as set out in the issuer's white-paper notification to the Česká národní banka [E:WP-GIFT-MICAR-FORM-2026-05].

General information (issuer perimeter). Issuer legal name: Ubuntu Uhuru s.r.o. Issuer LEI: 894500B0BCJDDPCC5346. Crypto-asset name: $GIFT. The reference period for this disclosure corresponds to the period stated in the issuer's white-paper notification to the home Member State competent authority [E:WP-GIFT-MICAR-FORM-2026-05].

Mandatory key indicator — energy consumption (issuer perimeter). Ubuntu Uhuru s.r.o. operates a fully cloud-hosted infrastructure model and does not own or operate data centres or DLT consensus nodes. Direct historical energy-consumption figures for the issuer's operations were not available at the time of this whitepaper; a baseline measurement will be established under the framework described at §7.4.5 below, and any material updates will be reflected in subsequent whitepaper versions consistent with MiCAR Article 12.

Renewable energy share (issuer perimeter). The issuer's cloud infrastructure is procured from a third-party cloud-service provider operating within the European Economic Area. The cloud provider publishes its own renewable-energy commitments; the issuer relies on those provider-level statements rather than on energy attribute certificates held directly by the issuer. The provider, the contracted region, and the underlying renewable-energy methodology are stated in the issuer's white-paper notification to the home Member State competent authority [E:WP-GIFT-MICAR-FORM-2026-05] and are not independently restated here to avoid divergence between the two documents.

Greenhouse-gas emissions (issuer perimeter). Reported following the GHG Protocol Corporate Accounting and Reporting Standard.

Electrical and electronic equipment waste (issuer perimeter). The issuer maintains a fully cloud-hosted infrastructure model and does not directly procure, operate, or dispose of physical server hardware. Direct waste of electrical and electronic equipment (WEEE) arising from the issuer's DLT-related operations is 0 kg.

7.4.5 Methodology disclosure

The chain-perimeter greenhouse-gas figures at §7.4.3 are derived from CCRI's methodology as published in [S1] and [S2]: a bottom-up approach surveying validator hardware requirements, modelling per-node power draw, multiplying by the active validator count, and applying grid-region carbon factors. The Ethereum-layer-1 allocation uses a hybrid transaction-plus-holdings allocation methodology developed by CCRI and South Pole. The peer-reviewed systematic literature review on blockchain energy efficiency by Zimba et al. (2025) [S4] confirms the standard methodology for delegated Proof-of-Stake networks.

The issuer-perimeter figures at §7.4.4 are reported under the GHG Protocol Corporate Accounting and Reporting Standard. Issuer Scope 1 is reported directly from the issuer's own operational footprint. Issuer Scope 2 is reported using cloud-provider usage metrics. Issuer Scope 3 in respect of DLT-network emissions is derived proportionally from the chain-perimeter figures.

Neither the chain-perimeter figures nor the issuer-perimeter figures are the result of an independent environmental assessment commissioned in respect of $GIFT. The chain-perimeter figures are taken from [S1] and [S2], which were commissioned by Polygon Technology. The issuer-perimeter figures derive from the issuer's own operational data and from the cloud-service provider's published metrics.

7.4.6 Sources

• [S1] Crypto Carbon Ratings Institute (CCRI), Update Report — The Energy Efficiency and Carbon Footprint of the Polygon Blockchain, October 2022 (REF-CCRI-POLYGON-002).
• [S2] CCRI, The Energy Efficiency and Carbon Footprint of the Polygon Blockchain (baseline), September 2022.
• [S3] Polygon Labs, Polygon Reaches First Sustainability Milestone by Achieving Network Carbon Neutrality, 21 June 2022.
• [S4] Zimba et al., systematic literature review on blockchain energy efficiency, Discover Analytics 2025, DOI 10.1007/s44257-025-00041-6 (REF-ZIMBA-BLOCKCHAIN-ENERGY-SLR-001).
• [S5] Polygon Labs published validator-set documentation.

7.4.7 Limitations

1. The figures at §7.4.3 are taken from a commissioned third-party assessment of the Polygon network's environmental impact, not from a measurement specific to the volume of $GIFT activity on the network.
2. The Polygon network's validator-set composition and geographic distribution may have changed since the 2022 reference period; the figures are presented for orientation, not as point-in-time-accurate at the date of this whitepaper.
3. The §7.4.3 chain-perimeter figures do not include a market-based renewable-energy claim: no published inventory of validator-held energy attribute certificates (such as Renewable Energy Certificates or Guarantees of Origin) was identified in the source review for the Polygon validator set. Any renewable-energy statements at the issuer perimeter (§7.4.4) reflect statements published by the issuer's cloud-service provider rather than energy attribute certificates held directly by the issuer and are presented on that basis.
4. Pre-Merge per-transaction figures published in 2022 that relied on the then-Proof-of-Work Ethereum layer-1 are not representative of the current state of Polygon Mainnet and are not relied upon in this disclosure.

Material changes to this disclosure — including changes to the consensus mechanism, the issuer's cloud-infrastructure footprint, the validator-set composition, geographic distribution, grid-emissions factors, or the underlying environmental methodology — will trigger an updated whitepaper notification to the home Member State competent authority under Article 12 of Regulation (EU) 2023/1114 and re-publication of the updated whitepaper in the prescribed format. The disclosure will also be updated to track the final regulatory technical standards and implementing technical standards adopted by the European Securities and Markets Authority and the European Banking Authority once published.

Cross-references: §2 Token Description; §5 Proof of Reserves; §8 Compliance and KYC/AML.

8. Compliance and KYC/AML

$GIFT is engineered as an ERC-20 token with integrated KYC and anti-money-laundering (AML) controls that operate alongside the token's standard transfer mechanics. Where a typical ERC-20 token treats every wallet as anonymous and every transfer as permissionless, $GIFT is paired with an on-chain ComplianceRegistry contract that records each holder's KYC status, sanctions and Politically Exposed Person (PEP) screening result, and transaction-size eligibility. Every $GIFT transaction routed through the uTribe application — purchase, send, swap, or redemption — is checked against this compliance state in real time before it is submitted to the blockchain. Wallets that are not KYC-verified or that fail sanctions screening are blocked at the application layer. This design gives $GIFT the global interoperability of an ERC-20 token together with the supervisory hooks that a regulated digital-asset issuer requires.

8.1 On-chain compliance authority

The ComplianceRegistry contract at 0xfa0bf4c2dbfb147f13127dd99712db0ea2b5b415 is the on-chain authority on per-wallet compliance state [E:COMPLIANCE-REGISTRY-CONTRACT] [E:KYC-STATE-FIELDS]. Each wallet carries the whitelisted, kycLevel, and frozen flags described in §5.3. uTribe application-layer policy requires KYC for $GIFT participation [E:KYC-PARTICIPATION-FLOOR]. Off-chain customer-database state is periodically reconciled to on-chain ComplianceRegistry state; the reconciliation procedure is published as the auditor-grade [E:HT-DOC-KYC-PROCEDURE].

8.2 KYC tiering

The on-chain kycLevel field is an integer in the range 0–3 [E:KYC-STATE-FIELDS]. The four implemented tiers gate transaction capability as follows [E:KYC-PARTICIPATION-FLOOR]:

The kycLevel floor for $GIFT transaction participation through the uTribe application is kycLevel ≥ 1. The ComplianceRegistry contract publishes each wallet's compliance state, including the spend-bucket fields (dailySpent / monthlySpent / yearlySpent) and the canTransact(address, amountUSD, minLevel) read [E:COMPLIANCE-REGISTRY-CONTRACT]. Enforcement of the per-tier transaction-size limit, sanctions screening, and PEP screening for every $GIFT transaction is performed at the application layer. The uTribe front-end and back-end read the ComplianceRegistry state in real time and refuse any transaction that does not satisfy the active KYC tier, the active per-period spend-bucket limits, or the active sanctions and PEP posture before submitting it on-chain. This same compliance-state read is exposed to regulated counterparties through documented integration patterns, so that compliant partners can apply the equivalent checks at their own application layer when handling $GIFT on behalf of their customers.

The architectural USD-denominated 0–3 model above is the default on-chain compliance-state representation for every operative perimeter. Customer-class mapping (retail / qualified investor / institutional), the applicable per-period thresholds, and the underlying regulatory citations differ by jurisdiction and are set out by jurisdiction in Appendix D §D.6 (KYC tier matrix and material-change notification — jurisdiction matrix): §D.6.1 European Union (including the Czech home perimeter through Ubuntu Uhuru s.r.o. as the operative entity) [E:LIC-2026-003], §D.6.2 Nigeria [E:LIC-2026-007] [FORWARD-LOOKING], and the §D.6 chapeau for jurisdictions where licence applications are progressing but counsel-confirmed source documentation is pending. The term qualified investor is used throughout this whitepaper generically; jurisdiction-specific equivalents (including accredited investor in the United States, high net-worth individual in Nigeria, professional client under MiFID II, qualified institutional buyer under SEC Rule 144A, and other regional terms) are defined in Appendix B and translated to the holder's jurisdiction at onboarding in the customer Terms and Conditions, where they are updated in line with the relevant supervisor's prescribed levels from time to time. Customer-facing monetary thresholds expressed in the holder's local currency (including any Naira retail and high-net-worth caps where set by the Securities and Exchange Commission, Nigeria) are likewise disclosed in the customer Terms and Conditions at onboarding.

8.3 Sanctions and PEP screening

All wallets and counterparties are screened against the Office of Foreign Assets Control (OFAC, United States), European Union, United Nations, and Her Majesty's Treasury (HM Treasury, United Kingdom) consolidated sanctions lists at onboarding and on an ongoing basis. Politically Exposed Person (PEP) and adverse-media screening is applied at onboarding and on a continuous-monitoring basis. Jurisdiction-specific overlays and supervisory authorities for each operative perimeter are set out in Appendix D §D.1 (Sanctions screening — jurisdiction matrix).

The detailed control-implementation references — including the vendor stack, screening cadence, and Suspicious Activity Report (SAR) submission workflow — are recorded in the operational compliance documentation maintained by the Money Laundering Reporting Officer (MLRO) under the relevant licensed jurisdiction. Identity and regulatory status of region-specific screening providers are available under non-disclosure agreement (NDA) on written request per §13.5.

8.4 Travel Rule

The Financial Action Task Force (FATF) Recommendation 16 — the "Travel Rule" — requires virtual-asset service providers to obtain, verify, retain, and transmit originator and beneficiary information for qualifying transfers of virtual assets. uTribe applies the Travel Rule to in-scope $GIFT transfers across every jurisdiction in which a Group entity is licensed or has filed for licensing, and engages with regulated counterparties using compliant Travel-Rule interoperability protocols.

The applicable monetary threshold, the supervising authority, the responsible Group entity, and the operational status of each licensed jurisdiction are set out by jurisdiction in Appendix D §D.4 (Travel Rule — jurisdiction matrix): §D.4.1 European Union [E:LIC-2026-003], §D.4.2 United Arab Emirates [E:LIC-2026-004] [FORWARD-LOOKING], §D.4.3 Nigeria [E:LIC-2026-007] [FORWARD-LOOKING], and §D.4.4 Other jurisdictions (FATF baseline). Jurisdictional implementations reflect, at minimum, the FATF Recommendation 16 USD/EUR 1,000 baseline; where the supervising authority has prescribed a stricter threshold or operational requirement, the stricter applies in that jurisdiction.

8.5 Record retention

On-chain $GIFT transactions are recorded immutably on the Polygon public chain. Off-chain records held by the issuer — KYC files, internal compliance records, transaction-monitoring logs, and Travel Rule originator / beneficiary information — are retained for a minimum of seven years from the end of the customer relationship, with HMAC-chained tamper-evident audit trails, in line with FATF and applicable AML directive obligations.

Cross-references: §2 Token Description; §5 Proof of Reserves; §10 Counterparty and Governance.

9. Risk Factors

⚠️ Risk warning

Investment in $GIFT may result in the full loss of capital invested. $GIFT is a contractual claim on physical gold held by a custodian. The value of $GIFT, and the ability to redeem it, is subject to counterparty, custody, regulatory, technological and market risks, which are described in §9 of this whitepaper. Past performance of physical gold is not indicative of future returns. Prospective holders should read this whitepaper in full and seek independent legal, tax and financial advice before acquiring $GIFT. $GIFT is not a deposit, is not covered by any deposit-guarantee scheme or investor-compensation scheme, and is not capital-protected.

The risks set out below correspond to those that, in the issuer's assessment, are the principal risks that may affect the issuer, the crypto-asset, the underlying technology, and the broader project. The categorisation in the table follows the issuer's structure and is aligned with the MiCAR Annex risk-disclosure categories and the issuer's regulator-facing risk disclosure at Part F of the issuer's white-paper notification to the home Member State competent authority [E:WP-GIFT-MICAR-FORM-2026-05]. A mapping between the categorisation in this section and the MiCAR / ESMA structural taxonomy is provided at §9.x below the table. Per-jurisdiction risk-factor overlays are set out by jurisdiction in Appendix D §D.3 (Risk factors per jurisdiction) — in particular, regulatory risk overlays, counterparty risk overlays for region-specific operational counterparties, and insolvency-delay risk for the offshore legal-holder structure in Mauritius. The list is not intended to be exhaustive and does not displace the obligation of any prospective holder to obtain independent legal, tax, and financial advice before acquiring $GIFT.

9.x Mapping to MiCAR / ESMA risk-disclosure categories

For regulator-facing comparability, the table below maps the §9 risk rows to the structural risk categories used in the issuer's white-paper notification to the home Member State competent authority [E:WP-GIFT-MICAR-FORM-2026-05] (Parts F.1, F.4, F.5 and F.6) and the MiCAR Annex risk-disclosure structure. Mapping is descriptive; it does not displace the substantive content of each row.

The issuer notes for transparency that the Part F.2 entry in the white-paper notification reads "NONE" and the Part F.3 entry reads "NONE". The expanded §9 disclosure in this whitepaper provides issuer-level and offer-level risk content (rows 1, 12, 13, 17) that complements the Submission's structural categorisation; this is not a contradiction but an additional level of granularity at the whitepaper layer, consistent with the issuer's view that issuer-level and offer-level risks are non-trivial and should be made explicit to prospective holders.

The list is not exhaustive and does not replace independent legal, tax, and financial advice.

Cross-references: §3 Tokenomics; §4 Reserves and Custody; §5 Proof of Reserves; §6 Settlement, Mint and Redemption; §10 Counterparty and Governance; §11 Wind-down, Migration, and Holder Protection; §12 Forward-Looking Regulatory Expansion.

10. Counterparty and Governance

10.1 Issuer entity framework

Ubuntu Tribe (a trading name of Ophir Ubuntu International and its subsidiaries) operates as a group of regulated entities under a single brand [E:GROUP-DBA]. "Ubuntu Tribe" and "uTribe" are dba names of Ophir Ubuntu International and its subsidiaries; the brand sits above the entities. No individual subsidiary is identified as "Ubuntu Tribe" itself.

For a given regulated activity, the operative legal entity is the subsidiary licensed for that activity in the relevant jurisdiction:

For activities currently in regulatory engagement (and therefore not yet authorised in those jurisdictions), see §12 Forward-Looking Regulatory Expansion.

Legal Entity Identifiers [E:LEI-REGISTER]

The ISO 17442 Legal Entity Identifier (LEI) of each operative entity in the group, where issued, is set out below. Where an LEI has not yet been issued for an entity, that fact is recorded explicitly; an LEI will be obtained ahead of any regulated activity in a jurisdiction that requires one.

The Ubuntu Uhuru s.r.o. LEI is the LEI that would appear in any EU MiCAR notification submitted by that entity, and is the LEI cited in EU regulator-facing material referring to the EU operative entity.

Registered offices [E:REGISTERED-OFFICES]

The registered office of each operative entity in the group, where documentary primary-source evidence is on file, is set out below. Where the registered office is recorded at primary-source level (commercial register extract, LEI registration record, trade-licence extract, or equivalent regulator-issued document), the entry cites the source. Where the registered office for a given operative entity is not yet recorded at primary-source level on the issuer's compliance files, the entry reads "to be confirmed" rather than restating an address from secondary sources.

The registered office of Ubuntu Uhuru s.r.o. above is the registered office that would appear in any EU MiCAR notification submitted by that entity, and is the registered office cited in EU regulator-facing material referring to the EU operative entity.

Director-of-record clarification. The "Director(s) of record" column lists the director(s) appointed to each named entity, not group-level executive titles. Directorships are entity-specific: a person may hold a directorship at one group entity without holding directorships at others. Mamadou Kwidjim Touré is Director of Ophir Ubuntu International and CEO of the uTribe group at that entity; he is not a director of Ubuntu Uhuru s.r.o. Angoula Dieudonne Gaél is the Statutory Director of Ubuntu Uhuru s.r.o. and is not a director of Ophir Ubuntu International.

10.2 Legal holder of the gold

The legal holder of the physical gold backing $GIFT is Ophir Ubuntu International (Mauritius GBL) [E:LEGAL-HOLDER] [E:CUSTODY-ROLES]. The custody arrangement is structured so that the segregated, allocated bullion stands outside the operational treasury of any operating subsidiary.

10.3 External counterparties

Region-specific partners. In addition to the Group-level counterparties named above, uTribe engages region-specific distribution counterparties, payment-services providers, AML/CFT screening providers, and Travel-Rule interoperability counterparties under jurisdiction-specific commercial arrangements. The identity, contractual scope, and regulatory status of these partners are available on written request under non-disclosure agreement through the evidence-request channel at §13.5. The aggregated regulatory pathway in each jurisdiction is summarised in Appendix D §D.1 (sanctions), §D.2 (AML/CFT pre-launch), §D.4 (Travel Rule), §D.6 (KYC tier matrix), and §D.7 (complaints handling).

10.4 Governance

Executive responsibility for the group rests with the named officers under their respective uTribe roles [E:ROLE-CEO] [E:ROLE-CIO] [E:ROLE-CTO] [E:ROLE-CISO-BACKUP] [E:ROLE-LEGAL-COUNSEL] [E:ROLE-COMPLIANCE-OFFICER]. The Chief Information Officer / Chief Information Security Officer / Data Protection Officer (CIO/CISO/DPO) function owns information security, group compliance architecture, and data protection across the group. AML/CFT supervisory engagement and the MLRO designation operate at the level of each licensed jurisdiction.

Contract-upgrade governance for the deployed Polygon contracts is the multi-signature timelock controller described in §7.2. Reserve drawdown and other reserve-affecting operations are governed by internal policy with separation of duties enforced through the AccessControl roles on the deployed contracts.

10.5 Governance multi-signature and on-chain timelock [E:GOVERNANCE-MULTISIG]

10.5.1 Owner multi-signature wallet

The Owner role on the $GIFT token and its supporting contracts is held by a multi-signature wallet on Polygon Mainnet. The configuration below was verified live on-chain at Polygon block 87,671,950 (2026-05-30 UTC) by direct read and is publicly observable on Polygonscan.

Privileged operations on the $GIFT token contract (contract upgrades, ownership transfer, supply-controller assignment, tax-manager assignment, pause and unpause) require at least two of the three signers to approve the transaction in the Gnosis Safe. No single externally-owned address can execute a privileged operation unilaterally.

10.5.2 Signer-key custody

The issuer's signing-key custody policy is that the three signer keys for the Owner Safe are held on hardware wallets by named individuals within the issuer's senior leadership, with no software-only signing keys in production use for the Owner Safe. The mapping of signer address to named individual is documented in the issuer's compliance records and is available on request under a regulatory or listing engagement.

10.5.3 On-chain timelock (V2 Proof-of-Reserve infrastructure)

The issuer's Proof-of-Reserve infrastructure includes a separately-deployed on-chain Timelock contract that enforces a mandatory delay between the approval and the execution of privileged operations.

During the 48-hour delay window, any proposed privileged operation is publicly visible on-chain. The Owner Safe signers, the issuer's external auditor (HT Digital Ltd.), and any third party monitoring the issuer's contracts can review the proposed operation and (in the Owner Safe signers' case) cancel it if a defect is identified.

10.5.4 Timelock posture on the $GIFT token Safe layer

No on-chain Timelock module is currently installed at the Owner Safe layer for the $GIFT token contract itself; the multi-signature quorum requirement at the Owner Safe and the public on-chain visibility of the Safe transaction queue prior to execution are the operative safeguards at the token layer today. Installation of an additional on-chain Timelock at the $GIFT token Safe layer is a roadmap item and is subject to the issuer's Article 12 whitepaper amendment commitment: any such change would itself be an Owner-Safe-approved on-chain operation, publicly visible on Polygonscan, and disclosed via an updated whitepaper notification.

10.5.5 Public verification path

A reader can verify the governance configuration in this sub-section directly from any Polygon Mainnet JSON-RPC endpoint or via Polygonscan, without trusting any off-chain source:

• The Owner Safe configuration is verifiable by calling getThreshold() and getOwners() on the Safe contract at 0xE37826217759C14c07E4b6E0C02479be50eBa156.
• The $GIFT token's Owner is verifiable by calling owner() on the $GIFT proxy 0xCfde7c43EDB3c9f71331AAc1003b099CE40c94ea and confirming the return value matches the Safe address above.
• The Proof-of-Reserve Timelock delay is verifiable by calling getMinDelay() on the Timelock contract 0xab1fea9B2de957df3B3256b20775aB551632BB05.

The issuer's public Proof-of-Reserve reference at https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit includes the same address inventory and is the canonical public engineering reference for the issuer's on-chain footprint.

Cross-references: §4 Reserves and Custody; §7 Smart-Contract Architecture; §11 Wind-down, Migration, and Holder Protection; §12 Forward-Looking Regulatory Expansion.

11. Wind-down, Migration, and Holder Protection

11.1 Wind-down framework

Ubuntu Tribe operates $GIFT through a network of licensed Group operative entities, each contracting directly with $GIFT holders in its jurisdiction (see §10). In the event that any operative entity ceases operations — whether by regulator revocation, expiry of an authorisation, partnership-arrangement termination, insolvency, or voluntary wind-down — the holder's claim on the underlying physical gold reserve is preserved through one or both of the mechanics described in §11.2.

11.2 Holder protection on cessation

In the event of cessation of an operative entity, outstanding $GIFT tokens held by customers of that entity's perimeter are either (a) redeemed against the issuer's reserve in physical gold or fiat equivalent at the prevailing methodology described at §4 and §6, or (b) migrated to an alternative legally permissible Group operative entity, preserving the customer relationship under the new operative entity's home-supervisor framework. The legal-holder structure (Ophir Ubuntu International, with allocated and segregated weight-account custody of the physical gold at Sequoyah Vaulting — see §4) is engineered so that the cessation of an operative entity does not affect the segregation of the physical gold reserve from the cessating entity's insolvency estate.

11.3 Per-jurisdiction wind-down pathways

The per-jurisdiction implementation of the wind-down framework is set out in Appendix D §D.5 (Wind-down and migration — jurisdiction matrix). The framework draws on the supervisor-prescribed wind-down plan requirements applicable in each operative perimeter — in particular EU MiCAR Article 47 (statutory wind-down plan requirement for asset-referenced tokens, applied by analogy by the issuer for Title II issuance as best-practice) and the SEC Digital Assets Rules 2022 wind-down obligations on Digital Asset Offering Platform (DAOP) and Digital Asset Exchange (DAX) deregistration in Nigeria — and is updated as additional jurisdictional supervisors prescribe wind-down-plan content from time to time.

Cross-references: §4 Reserves and Custody; §6 Settlement, Mint and Redemption; §10 Counterparty and Governance; Appendix D §D.5.

12. Forward-Looking Regulatory Expansion

Each item in this section is an authorisation, registration, or initiative that Ubuntu Tribe is progressing in order to extend $GIFT's regulated footprint and strengthen the protections that already cover $GIFT holders today. The protective effect of each pending authorisation is, on grant, the same protective effect that already operates in the EU under the active Czech VASP registration held by Ubuntu Uhuru s.r.o. and in Mauritius under the Financial Services Commission authorisation held by Ophir Ubuntu International: a supervisory authority, a licensed local entity that contracts directly with $GIFT holders in that jurisdiction, a defined complaints pathway under the relevant supervisor's framework, and a defined wind-down pathway that preserves the holder's claim on the underlying reserve (see §11). Each item is tagged [FORWARD-LOOKING]; no commitment is made as to timing, approval, or scope. Each item that references an authorisation cites the corresponding grc.license_register entry.

• Luxembourg Security Token Offering. Ubuntu Tribe is preparing a Security Token Offering filing in Luxembourg; the regulatory pathway is to be determined among Prospectus Regulation, EU DLT Pilot Regime (Regulation (EU) 2022/858), or MiCA Title II / Title III authorisation (LIC-2026-012, status pending_application) [E:LIC-2026-012]. The Luxembourg STO is not asserted as imminent, approved, or scheduled. [FORWARD-LOOKING]
• EU MiCA Crypto-Asset Service Provider authorisation. Ubuntu Uhuru s.r.o. is progressing its MiCA CASP authorisation with the Czech National Bank (LIC-2026-011, status pending_application) [E:LIC-2026-011]. Activation of MiCA passporting across the EEA is contingent on CNB authorisation. [FORWARD-LOOKING]
• UAE VARA licence. Mansa Musa Digital is progressing its VARA licence application (LIC-2026-004, status pending_application) [E:LIC-2026-004]. Operation in the Dubai mainland under VARA is contingent on grant of licence. [FORWARD-LOOKING]
• Kenya VASP licence. Mansa Musa Technologies Kenya is progressing its VASP licence application with the Capital Markets Authority Kenya (LIC-2026-006, status pending_application) [E:LIC-2026-006]. [FORWARD-LOOKING]
• Nigeria SEC / ARIP. Mansa Musa Integrated Solutions Nigeria is progressing its application under the Nigeria SEC ARIP framework (LIC-2026-007, status pending_application) [E:LIC-2026-007]. The Nigerian entity is not operational. [FORWARD-LOOKING]
• Ghana regulatory sandbox. Engagement with the Bank of Ghana / SEC Ghana sandbox is in progress (LIC-2026-008, status pending_application) [E:LIC-2026-008]. [FORWARD-LOOKING]
• Mauritius data-controller registration. Pending registration with the Mauritius Data Protection Office for Ophir Ubuntu International (LIC-2026-002, status pending_application) [E:LIC-2026-002]. [FORWARD-LOOKING]
• Fee-schedule review. The current fee schedule (§3.2) may be reduced in the future. No date or magnitude is committed; the current schedule remains in force until any change is announced through standard customer-communication channels [E:FEES-FUTURE-REDUCTION]. [FORWARD-LOOKING]
• Additional precious-metal product research. Research on additional precious-metal-backed product structures is paused. [FORWARD-LOOKING]

Cross-references: §3 Tokenomics (regulatory characterisation); §10 Counterparty and Governance; §11 Wind-down, Migration, and Holder Protection; Appendix D §D.5.

13. Evidence Availability and Access

Claims in this whitepaper are tagged inline with evidence identifiers of the form [E:...] (for example [E:CUSTODY-HOLDING], [E:LIC-2026-003], [E:HT-DOC-AUDITOR-REFERENCE]). Each identifier resolves to a row in the Evidence File maintained alongside this whitepaper, which records the underlying source document, the source location within that document, the access classification, and the responsible owner.

13.1 What the Evidence File contains

For every inline [E:...] tag in this whitepaper, the Evidence File records:

• The claim as stated in the whitepaper.
• The source document (custody contract, licence register entry, partner due-diligence record, on-chain transaction, auditor methodology pack, signed weight-account statement, internal control evidence, etc.).
• The source location within that document (clause number, page, on-chain transaction hash, block height, file path, etc.).
• The access classification (PUBLIC / NDA / AUDITOR-ONLY / REGULATOR-ONLY / RESTRICTED).
• The responsible owner within Ubuntu Tribe for producing the underlying source on request.

The Evidence File is not itself distributed with this whitepaper. It is the index that allows an LP, an auditor, or a regulator to request the specific evidence behind any single claim, without Ubuntu Tribe needing to bundle every underlying contract, licence, and audit document with every distribution of the whitepaper.

13.2 What evidence is already publicly available

The following evidence is public and requires no NDA or request:

• On-chain evidence: every [E:...] tag that resolves to an on-chain state read, transaction hash, or event log is independently reproducible by any reader against Polygon Mainnet (chain ID 137) — contract addresses are listed in Appendix A.1; the verification methodology is in §5.
• Public engineering reference: https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit — function inventory, calldata layout, event signatures, and the public verify_kyc.py verification script [E:PUBLIC-ENGINEERING-REF] [E:HT-PUBLIC-COMPANION]. This repository is the engineering source of truth for reproducing the on-chain side of the Proof of Reserves.
• Licensing references: licence numbers cited in this whitepaper are recorded in Ubuntu Tribe's internal licence register; public-register confirmations (where the underlying regulator publishes a register) are linked from Appendix A.4 [E:LIC-2026-001] [E:LIC-2026-003].
• Custodian identity, vault location, legal-holder identity, asset type, and applicable custodian certifications are disclosed in §4.1 per the whitepaper audience disclosure policy [E:CUSTODY-DISCLOSURE].
• The HT Digital Ltd. engagement is acknowledged in §4.5 and §5; the auditor's public confirmation of the engagement (where issued) is linked from Appendix A.3.

13.3 What evidence is available under non-disclosure (NDA)

The following evidence is available upon execution of Ubuntu Tribe's standard non-disclosure agreement and completion of due diligence:

• Custody contract between Ubuntu Tribe and Sequoyah Vaulting (terms, allocation language, segregation language, redemption-counterparty mechanics) [E:CUSTODY-HOLDING] [E:CUSTODY-ROLES].
• HT Digital Ltd. engagement letter and the auditor-grade methodology pack TECH-POR-AUDITOR-001 / PROC-POR-KYC-001 [E:HT-DOC-AUDITOR-REFERENCE] [E:HT-DOC-KYC-PROCEDURE] [E:HT-DELIVERY].
• Most recent signed Sequoyah weight-account statement (current balance figures, balance valuations, account identifiers, and custody-chain history are not in this whitepaper per the whitepaper audience disclosure policy; they are released under NDA) [E:CUSTODY-DISCLOSURE] [E:BALANCE-LATEST-CADENCE].
• Most recent HT Digital Ltd. attestation (full text), including the reconciliation working papers between the on-chain $GIFT supply and the physically verified gold balance.
• Transport-partner specifics for physical redemption (per-shipment counterparty diligence) [E:TRANSPORT].
• Fee-schedule confirmation from internal CEO-confirmed source [E:FEES-BUY-IN] [E:FEES-TRANSACTION] [E:FEES-INTERNAL] [E:FEES-ALLOCATION].
• Reserve-coverage operating parameters (current floor, current coverage ratio) and the reserve-verification operating record for a defined look-back period [E:RESERVE-COVERAGE-DYNAMIC].
• Onboarding operational parameters: settlement times, minimum / maximum ticket sizes, withdrawal-queue mechanics, redemption SLAs as agreed bilaterally [E:SETTLEMENT-PARAMETERS].
• Smart-contract audit reports (full text), upgrade-governance records, and the most recent multi-signature / timelock control evidence.
• The licence register entries for items cited as [FORWARD-LOOKING] in §3.6 and §10, including pending-application status and most-recent regulator correspondence [E:LIC-2026-004] [E:LIC-2026-011] [E:LIC-2026-012].
• Ubuntu Tribe group structure beyond the operative-entity disclosure in §10 — the full corporate structure chart, where required for institutional onboarding.

Insitutional investors in active onboarding receive a curated Evidence Pack containing the subset of the above that is relevant to their counterparty risk assessment, indexed against the [E:...] tags in this whitepaper.

13.4 What evidence is available to auditors and regulators

Under the engagement with HT Digital Ltd., all evidence underlying any inline [E:...] tag is available to the auditor without restriction, including any item classified above as NDA, AUDITOR-ONLY, or REGULATOR-ONLY [E:HT-DOC-AUDITOR-REFERENCE].

Regulators with supervisory authority over Ubuntu Tribe or any of its operating subsidiaries may request any evidence underlying this whitepaper through the relevant licensed entity. Ubuntu Tribe maintains a dedicated regulator-correspondence channel for this purpose; contact details are provided in §10.

A narrow class of evidence — banking details, custody account identifiers, individual customer records, signing keys, and similar sensitive operational material — is RESTRICTED and is released only under a specific regulator request, a specific court order, or a specific auditor-engagement scope [E:CUSTODY-DISCLOSURE]. This restriction protects the security of customer assets, the integrity of the custody arrangement, and adheres to data protection frameworks governing uTribe which include, but are not limited to EU GDPR Reg (EU) 2016/679, UAE PDPL, Mauritius Data Protection Act 2017, and the Nigeria Data Protection Act 2023 (NDPA 2023); it is not a restriction on the substantive evidence underlying any whitepaper claim.

13.5 How to request evidence

Prospective LPs, auditors, regulators, and counterparties performing due diligence may request evidence by contacting Ubuntu Tribe through the channel listed in §10 (Counterparty and Governance) or by emailing the onboarding desk. Evidence requests should be sent to [email protected] and should cite the specific [E:...] tag(s) for which evidence is being requested.

Requests are acknowledged within two business days and are fulfilled — subject to execution of the relevant NDA and completion of due-diligence checks on the requesting party — within a target window of ten business days for NDA items. Auditor and regulator requests are fulfilled under the timelines specified by the relevant engagement letter or supervisory request.

13.6 Civil liability and the issuer's amendment commitment [E:WHITEPAPER-LIABILITY]

13.6.1 Statutory civil liability under MiCAR Article 15

In accordance with Article 15 of Regulation (EU) 2023/1114 (MiCAR), the issuer and members of the issuer's administrative, management or supervisory body are liable to a holder of $GIFT for any loss incurred by the holder as a result of an infringement of the disclosure requirements of MiCAR, including where this whitepaper is incomplete, not fair, not clear, or misleading, and where such information has been instrumental in the holder's decision to acquire $GIFT.

The Article 15 liability applies notwithstanding any contractual exclusion or limitation of liability to the contrary; it is a statutory protection of the holder.

Nothing in this whitepaper, or in the issuer's Terms and Conditions, excludes or limits the holder's rights under Article 15 of MiCAR.

13.6.2 The issuer's material-change amendment commitments

Where a material change occurs in any of the information disclosed in this whitepaper — including but not limited to changes to the consensus mechanism (§7.4), the custodian (§4), the gold-per-token ratio (§3.1, §4), the operative entity framework (§10), the offer cap or subscription mechanics (§3, §6), the pricing methodology (§3.7), the fee schedule (§3.2), the risk factors (§9), or the supply mechanics (§3.1, §3.8) — the issuer will:

1. Notify each home competent authority for each operative perimeter of the modified whitepaper under the applicable framework for that perimeter:
   • European Union / Czech home: Notify Česká národní banka (CNB) under MiCAR Article 12 in respect of the EU public offer.
   • Nigeria (on activation of the Nigerian perimeter): Notify the Securities and Exchange Commission, Nigeria, under SEC Digital Assets Rules 2022 Part A material-change disclosure obligations and Investments and Securities Act 2025 (ISA 2025) Section 357 disclosure duty, in respect of any distribution to Nigerian residents.
   • United Arab Emirates (on activation of the UAE perimeter): Notify the Virtual Assets Regulatory Authority (VARA) under the VARA Compliance and Risk Management Rulebook material-change notification framework.
   • Mauritius: Notify the Financial Services Commission, Mauritius, in respect of any change affecting the legal holder Ophir Ubuntu International, under the FSC Mauritius supervisor notification framework.
2. Re-publish the updated whitepaper at the standing URL referenced in the Notice of Supersedure at the front of this document, with the updated version time-stamped and clearly marked as the applicable version. The updated whitepaper is published simultaneously to every operative-perimeter audience; the issuer does not maintain perimeter-divergent whitepaper versions.
3. Inform existing holders of the modified whitepaper through the channels described at this §13 (Evidence Availability and Access). Holder-facing communications in each operative perimeter are provided in the holder's primary language for that perimeter where the issuer's perimeter Terms and Conditions so provide.
4. EU statutory withdrawal right. Where the modification concerns a significant new factor, material mistake, or material inaccuracy that arose or was noted before the closing of the offer period or the delivery of $GIFT, purchasers who agreed to purchase $GIFT before the modification is published have the right, under MiCAR Article 12, to withdraw their acceptance within two working days after the publication of the modified whitepaper. Parallel statutory or regulator-prescribed withdrawal rights under non-EU regimes, where established by the supervising authority, are honoured by the issuer in accordance with the applicable framework on activation of the relevant perimeter.

The per-jurisdiction notification recipients, the framework citation, and the operative trigger for material-change notification are summarised in Appendix D §D.6 (Material-change notification matrix), indexed by jurisdiction. The issuer commits not to give effect to any material change in any operative perimeter ahead of notification to the supervising authority for that perimeter.

13.6.3 Complaints handling

Holders and prospective holders may submit complaints in relation to this whitepaper, or any other aspect of the issuer's services, free of charge:

• By email to [email protected]; or
• Through the contact form on the issuer's web portal.

Complaints are investigated by the issuer's designated Complaints Officer in accordance with Article 31 of MiCAR. A response is provided within a reasonable timeframe.

Parallel complaints-handling pathways under other operative regimes (including the Nigerian SEC + Central Bank of Nigeria (CBN) consumer-protection framework on activation of the Nigerian perimeter, the VARA complaints framework on activation of the UAE perimeter, and the UK Financial Conduct Authority (FCA) DISP rules where applicable to UK consumers acquiring $GIFT through licensed UK virtual-asset service providers in a counterparty role) are set out in Appendix D §D.7 (Complaints handling — jurisdiction matrix), indexed by jurisdiction.

Where a dispute involving a consumer holder cannot be resolved directly with the issuer, the holder may also address the Financial Arbitrator of the Czech Republic (Finanční arbitr) or use the European Union Online Dispute Resolution (ODR) platform, as further described at §3.x (Rights and obligations attached to $GIFT) above.

Appendix A — Contract addresses, custody references, audit references

A.1 On-chain contracts (Polygon Mainnet, chain ID 137 [E:CHAIN])

ERC-20 metadata: name() = "GIFT", symbol() = "GIFT", decimals() = 18 [E:GIFT-SYMBOL] [E:GIFT-DECIMALS].

Reference verification window (2026-05-20): chain heads 87,187,225–87,189,242; raw totalSupply() 0x4407746d561972a3c0000 (expressed in mg of gold: 5,140,135 mg) [E:GIFT-SUPPLY-SNAPSHOT-2026-05-20]. KYC-verification reference run (2026-05-21): chain head 87,236,996; 109 wallets verified, 109/109 match [E:HT-DOC-KYC-PROCEDURE].

A.2 Public engineering reference

https://github.com/ubuntu-tribe/Utribe-PoR-Public-Audit

Contains the canonical engineering reference (function inventory, calldata layout, event signatures) and the public verify_kyc.py verification script [E:PUBLIC-ENGINEERING-REF] [E:HT-PUBLIC-COMPANION].

A.3 Audit references (HT Digital Ltd.)

HT Digital Ltd. partner-of-record: partner code PSP-2026-015, case reference HT-DIGITAL-PoR-AUDIT-2026 [E:HT-AUDIT-PARTNER-RECORD]. Auditor-pack delivery: 2026-05-22 [E:HT-DELIVERY].

A.4 Custody references

A.5 Licence register

Active licences referenced in this document [E:LIC-2026-001] [E:LIC-2026-003]; pending applications referenced in §12 Forward-Looking Regulatory Expansion [E:LIC-2026-002] [E:LIC-2026-004] [E:LIC-2026-006] [E:LIC-2026-007] [E:LIC-2026-008] [E:LIC-2026-011] [E:LIC-2026-012]. Licence details are maintained in grc.license_register and disclosed to regulators and qualifying counterparties under engagement NDA on request. Cross-references in Appendix D below name the operative Group entity and licence reference for each jurisdiction in which an obligation under that Appendix sub-section applies.

Appendix D — Jurisdiction-specific implementation matrices

This Appendix records the per-jurisdiction implementation detail for every topic in the body that has regional variation. Each sub-section is structured: regulation primary citation → threshold treatment → supervising authority → responsible Group entity (with [E:LIC-2026-NNN] evidence anchor) → operational status → operational scope. Jurisdictions are ordered by operational status (live licences first, pending second) and then by capital-markets importance.

D.1 Sanctions screening — jurisdiction matrix

The Group-level baseline at §8.3 applies across every operative perimeter. Per-jurisdiction overlays:

D.1.1 European Union (and European Economic Area)

• Regulation: Council Regulation (EU) No 269/2014 (restrictive measures in respect of actions undermining the territorial integrity of Ukraine) and the EU consolidated financial-sanctions list as updated; Council Regulation (EU) No 833/2014 (Russia restrictive measures); EU Anti-Money-Laundering Directive 2018/843 (5AMLD) Article 18 enhanced due diligence on high-risk third countries.
• Threshold treatment: all wallets and counterparties screened; no de minimis threshold for sanctions screening.
• Supervising authority: European Commission for EU consolidated list maintenance; AML supervisor for the Group entity is the Finanční analytický úřad (FAÚ), Czech Republic.
• Responsible Group entity: Ubuntu Uhuru s.r.o. (Czech Republic) [E:LIC-2026-003].
• Operational status: Live.
• Operational scope: Screening at onboarding and continuous monitoring; vendor stack and SAR-submission workflow recorded in operational compliance documentation maintained by the MLRO; available under NDA via §13.5.

D.1.2 Nigeria

• Regulation: Money Laundering (Prevention and Prohibition) Act 2022 (MLPPA 2022) and the Securities and Exchange Commission Rules on Issuance, Offering Platforms and Custody of Digital Assets, 2022 ("SEC Digital Assets Rules 2022"); Nigerian Financial Intelligence Unit (NFIU) sanctions list.
• Threshold treatment: all wallets and counterparties screened; no de minimis threshold.
• Supervising authority: Securities and Exchange Commission, Nigeria; AML/CFT supervisor under MLPPA 2022 is the Nigerian Financial Intelligence Unit (NFIU).
• Responsible Group entity: Mansa Musa Integrated Solutions Nigeria Ltd [E:LIC-2026-007].
• Operational status: Pending licence. [FORWARD-LOOKING] Commercial operation under SEC supervision is contingent on Accelerated Regulatory Incubation Programme (ARIP) admission.
• Operational scope: On admission, screening at onboarding and continuous monitoring per SEC Digital Assets Rules 2022 + MLPPA 2022; NFIU SAR submission workflow established.

D.1.3 Other jurisdictions (FATF baseline)

In jurisdictions where uTribe is not separately licensed, sanctions screening is applied on the basis of the United Nations Security Council Consolidated List + the Group-level baseline (OFAC, EU, UN, HM Treasury) at all times. Where a customer is acquiring $GIFT through a licensed virtual-asset service provider in their home jurisdiction, that licensed counterparty applies its home-supervisor screening framework in addition.

D.2 AML/CFT pre-launch and ongoing supervision — jurisdiction matrix

D.2.1 European Union (and European Economic Area)

• Regulation: EU Directive 2018/843 (5AMLD) as transposed; Czech AML Act No. 253/2008 Coll.; EU Regulation 2024/1620 (the Anti-Money Laundering Authority, AMLA, Regulation, in force from 2025); Czech FAÚ Methodological Recommendation on Virtual Asset Service Providers.
• Pre-launch risk assessment: completed; updated annually and on material change. Output available under NDA via §13.5.
• Supervising authority: FAÚ Czech Republic.
• Responsible Group entity: Ubuntu Uhuru s.r.o. [E:LIC-2026-003].
• Operational status: Live.
• Operational scope: AML risk register, customer-risk classification, transaction-monitoring rule set, ongoing-monitoring cadence, escalation pathway to the MLRO and to the FAÚ maintained as operational compliance documentation.

D.2.2 Nigeria

• Regulation: MLPPA 2022 Section 13 (pre-launch AML/CFT risk assessment), Section 6 (enhanced due diligence); SEC Digital Assets Rules 2022 Part B (operational platform requirements).
• Pre-launch risk assessment: to be completed before commercial distribution per MLPPA 2022 Section 13. [FORWARD-LOOKING] Anchored to the ARIP admission timeline for Mansa Musa Integrated Solutions Nigeria.
• Supervising authority: Nigerian Financial Intelligence Unit (NFIU) under MLPPA 2022; Securities and Exchange Commission, Nigeria, under SEC Digital Assets Rules 2022.
• Responsible Group entity: Mansa Musa Integrated Solutions Nigeria Ltd [E:LIC-2026-007].
• Operational status: Pending licence.
• Operational scope: On admission, pre-launch AML/CFT risk assessment outputs filed with NFIU; ongoing-supervision cadence under SEC + NFIU dual oversight.

D.2.3 Other jurisdictions (FATF baseline)

FATF Recommendation 1 (national risk assessment) and Recommendation 15 (VASP-specific requirements) as implemented locally. Where a counterparty’s home jurisdiction has a licensed VASP, AML/CFT compliance is the home-supervisor responsibility of that licensed counterparty.

D.3 Risk factors per jurisdiction

This sub-section overlays jurisdiction-specific risk factors on the Group-level risk categories in §9.

D.3.1 European Union (and European Economic Area)

• Regulatory risk: Final MiCA classification of $GIFT (Title II "other crypto-assets" per Mgr. Ondrej Syllaba’s 2026-05-13 opinion) remains subject to competent-authority determination. Czech National Bank (CNB) MiCA CASP authorisation LIC-2026-011 is pending_application. [FORWARD-LOOKING] Adverse classification or CNB authorisation refusal could require operational adjustments or wind-down for EU customers.
• Counterparty risk: EU customer relationship is with Ubuntu Uhuru s.r.o. as the Czech VASP. Insolvency of Ubuntu Uhuru s.r.o. would require migration of the customer relationship to an alternative operative entity within the Group (or wind-down per §D.5.1) and may delay redemption pending the migration.
• Insolvency-delay risk: Offshore legal-holder structure (Ophir Ubuntu International, Mauritius FSC LIC-2026-001). Insolvency of the legal holder would be subject to Mauritius insolvency proceedings; recourse to the physical gold reserve is preserved through allocated-segregated weight-account custody at Sequoyah Vaulting but enforcement timeline depends on Mauritius proceedings rather than Czech.

D.3.2 Nigeria

• Regulatory risk: SEC Nigeria framework for digital tokens and commodity-backed instruments under SEC Digital Assets Rules 2022 + ISA 2025 is evolving; classification under SEC review may require operational adjustments or product withdrawal. The Nigerian regulatory pathway depends on ARIP admission, DAOP / DAX registration for distribution counterparties, and Digital Asset Custodian (DAC) registration considerations (see Appendix D §D.6.2 chapeau note).
• Counterparty risk: Nigerian distribution via counterparty remains pending. Where Nigerian-market distribution is operationalised through a region-specific distribution counterparty, that counterparty must hold an appropriate Securities and Exchange Commission, Nigeria, Digital Asset Offering Platform (DAOP) registration (and, where secondary-market trading is enabled, Digital Asset Exchange (DAX) registration) under Part B of the SEC Digital Assets Rules 2022. Counterparty selection and the corresponding licensing arrangements are not finalised at the date of this whitepaper; any final arrangement and the identity of the counterparty are subject to the standing disclosure framework described at §10.3 and the NDA-bound evidence-request channel at §13.5.
• Insolvency-delay risk: Same offshore legal-holder structure as the EU; Nigerian-resident holders’ recourse to the physical gold reserve is subject to Mauritius insolvency proceedings rather than Nigerian proceedings.

D.3.3 Other jurisdictions (FATF baseline)

Jurisdictions where uTribe is not separately licensed inherit the Group-level risk categories at §9. Where a customer is acquiring $GIFT through a licensed virtual-asset service provider in their home jurisdiction, the licensed counterparty’s home regulator’s risk-disclosure framework applies in addition.

• Insolvency-delay risk: Same offshore legal-holder structure as the EU and Nigeria. The legal holder of the physical reserve is Ophir Ubuntu International, a Mauritius-registered entity authorised by the Financial Services Commission of Mauritius (LIC-2026-001). Holders resident outside the EU and outside any operative perimeter named at §D.3.1 or §D.3.2 should note that, in the event of insolvency of the legal holder, the procedural jurisdiction for enforcing the trust over the reserve is Mauritius. Recourse to the physical gold reserve is preserved through allocated-segregated weight-account custody at Sequoyah Vaulting; the enforcement timeline depends on Mauritius proceedings rather than on the holder’s own home-jurisdiction proceedings.

D.4 Travel Rule — jurisdiction matrix

D.4.1 European Union (and European Economic Area)

• Regulation: Transfer of Funds Regulation — Regulation (EU) 2023/1113, Article 14 (applying to crypto-asset transfers between crypto-asset service providers and self-hosted addresses).
• Threshold (fixed in primary law): EUR 1,000 per qualifying transfer.
• Supervising authority: European Securities and Markets Authority (ESMA) and European Banking Authority (EBA) joint guidelines on Travel-Rule information fields and interoperability. AML supervisor for the Group entity is the Finanční analytický úřad (FAÚ), Czech Republic.
• Responsible Group entity: Ubuntu Uhuru s.r.o. (Czech Republic) [E:LIC-2026-003], Czech VASP trade licence issued 2024-07-03 by the Authority of Prague 8 City Ward, indefinite term.
• Operational status: Live.
• Operational scope: $GIFT transfers crossing the EUR 1,000 threshold in this perimeter are subject to originator-/beneficiary-information collection, verification, retention for at least seven years (per §8.5), and exchange with counterpart virtual-asset service providers through a compliant Travel-Rule interoperability protocol.

D.4.2 United Arab Emirates

• Regulation: Federal Decree-Law No. 20 of 2018 on Anti-Money Laundering and Combating the Financing of Terrorism and the Financing of Illegal Organisations (as amended); the Central Bank of the UAE AML/CFT Regulations; and, for entities licensed by the Virtual Assets Regulatory Authority (VARA), the VARA Virtual Assets Regulations and the VARA Compliance and Risk Management Rulebook.
• Threshold (set by the supervisor): as prescribed by VARA from time to time, denominated in AED at the level set in the VARA Compliance and Risk Management Rulebook, reflecting the FATF Recommendation 16 USD/EUR 1,000 baseline.
• Supervising authority: Virtual Assets Regulatory Authority (VARA), Dubai. National AML supervisor under Federal Decree-Law No. 20 of 2018 is the Central Bank of the UAE.
• Responsible Group entity: Mansa Musa Digital [E:LIC-2026-004], VARA licence pending.
• Operational status: Pending licence. [FORWARD-LOOKING] Commercial operation under VARA supervision is contingent on grant of the licence.
• Operational scope: On grant, $GIFT transfers crossing the AED-denominated threshold in this perimeter will be subject to originator-/beneficiary-information collection, verification, retention, and exchange on the basis prescribed by VARA.

D.4.3 Nigeria

• Regulation: Money Laundering (Prevention and Prohibition) Act 2022 (MLPPA 2022) and the Securities and Exchange Commission (SEC) Rules on Issuance, Offering Platforms and Custody of Digital Assets, 2022 ("SEC Digital Assets Rules 2022"), read with the Investments and Securities Act 2025 (ISA 2025).
• Threshold (set by the supervisor): as prescribed by the SEC under the SEC Digital Assets Rules 2022 and the MLPPA 2022 from time to time, denominated in Nigerian Naira and disclosed in the Nigerian-market customer documentation at first issuance.
• Supervising authority: Securities and Exchange Commission, Nigeria. AML/CFT supervisor under MLPPA 2022 is the Nigerian Financial Intelligence Unit (NFIU).
• Responsible Group entity: Mansa Musa Integrated Solutions Nigeria Ltd [E:LIC-2026-007], Accelerated Regulatory Incubation Programme (ARIP) application pending.
• Operational status: Pending licence; not yet operational. [FORWARD-LOOKING] Commercial operation under SEC supervision is contingent on ARIP admission.
• Operational scope: On admission, $GIFT transfers crossing the applicable Nigerian threshold in this perimeter will be subject to originator-/beneficiary-information collection, verification, retention, and exchange on the basis prescribed by the SEC under the SEC Digital Assets Rules 2022 and MLPPA 2022.

D.4.4 Other jurisdictions (FATF baseline)

In jurisdictions where uTribe is not separately licensed but where $GIFT may be acquired by qualifying eligible counterparties through licensed virtual-asset service providers, the Travel Rule is applied on the basis of the FATF Recommendation 16 baseline as implemented by the relevant local supervisor, with the operative entity in the counterparty's jurisdiction performing the originator-/beneficiary-information role. Where no Group entity is operative locally, $GIFT acquisition is gated through the licensed counterparty's own Travel-Rule infrastructure under the supervision of that counterparty's home regulator.

D.5 Wind-down and migration — jurisdiction matrix

D.5.1 European Union (and European Economic Area)

• Framework: EU MiCAR Article 47 (wind-down plan requirement for ARTs; applied by analogy for Title II issuers as best-practice); Czech Insolvency Act No. 182/2006 Coll. as applied to the operative entity.
• Triggers: voluntary cessation of operations; CNB authorisation refusal or revocation; insolvency of Ubuntu Uhuru s.r.o.
• Migration option: holder redemption against the issuer’s reserve, or migration of the customer relationship to an alternative legally permissible operative Group entity (subject to that entity’s own perimeter and supervisory regime).
• Responsible Group entity: Ubuntu Uhuru s.r.o. [E:LIC-2026-003]; legal holder Ophir Ubuntu International [E:LIC-2026-001].

D.5.2 Nigeria

• Framework: Issuer-side wind-down framework (redemption against the issuer's reserve in physical gold or fiat-equivalent, or migration of the customer relationship to an alternative legally permissible operative entity); SEC Digital Assets Rules 2022 wind-down obligations on DAOP / DAX deregistration.
• Triggers: SEC withdrawal of ARIP admission; ARIP non-progression to permanent licence; termination of the Nigerian distribution arrangement once such an arrangement is in force; voluntary wind-down.
• Migration option: redemption against the issuer’s reserve, or migration of the customer relationship to an alternative legally permissible Group operative entity available to Nigerian residents.
• Responsible Group entity: Mansa Musa Integrated Solutions Nigeria Ltd [E:LIC-2026-007]; legal holder Ophir Ubuntu International [E:LIC-2026-001].

D.5.3 Other jurisdictions

Where there is no Group operative entity, wind-down is the responsibility of the licensed virtual-asset service provider through which the customer acquired $GIFT, under that counterparty’s home supervisor framework. Holder redemption against the issuer’s reserve via the EU operative entity remains available subject to the operational scope at §D.4.4.

D.6 KYC tier matrix and material-change notification — jurisdiction matrix

D.6 chapeau

This sub-section sets out the per-jurisdiction customer-class mapping (retail / qualified-investor / institutional), the applicable threshold treatment, and the regulatory citation, for each jurisdiction in which a Group entity is licensed or has received counsel-confirmed source-document anchoring at the time of publication of this whitepaper. Jurisdictions where uTribe is progressing licence applications but has not yet received counsel-confirmed source documentation are not enumerated in this sub-section; their KYC tier framework will be added in a subsequent whitepaper version once counsel confirmation has been obtained. Until then, the Travel Rule treatment for those jurisdictions is set out in §D.4 and the entity framework in §10 and Appendix A.5.

Jurisdictions enumerated in §D.6 at this publication: European Union (§D.6.1, including Czech home perimeter) and Nigeria (§D.6.2).

Jurisdictions where licence applications are progressing but §D.6 enumeration is pending counsel confirmation: United Arab Emirates (Mansa Musa Digital VARA application LIC-2026-004 pending; Travel Rule treatment in §D.4.2). When counsel confirmation lands, the UAE-VARA KYC tier framework will be added at §D.6.3 in a subsequent whitepaper version.

Material-change notification commitments per jurisdiction are summarised at the end of this §D.6 sub-section.

In each table below, Threshold treatment describes how the relevant supervisor sets the monetary or eligibility thresholds for the customer class: a primary-law treatment means the figure is fixed in the regulation itself and is cited inline; a supervisor-set treatment means the figure is set by the relevant supervising authority from time to time and is carried in the customer Terms and Conditions at onboarding with a versioned change-log.

D.6.1 European Union (and European Economic Area)

The Group operative entity is Ubuntu Uhuru s.r.o. (Czech Republic), holding a Czech Virtual Asset Service Provider trade licence LIC-2026-003 issued 2024-07-03 by the Authority of Prague 8 City Ward, AML supervision by the Finanční analytický úřad (FAÚ). The same operative entity serves the EEA passport perimeter (under EU MiCAR Title II framework) and the Czech home perimeter (under Czech Trade Licensing Act No. 455/1991 Coll. + Czech AML Act No. 253/2008 Coll. + Section 26 of Czech Financial Market Digitalisation Act No. 31/2025 Coll.); operational substance is the same with the AML supervisor differing per perimeter (ESMA + EBA joint guidance for the EU passport perimeter; FAÚ for the Czech home perimeter) [E:LIC-2026-003].

Operational scope. Customer-class determination is performed at onboarding and re-verified periodically. Travel Rule application per §D.4.1 (EUR 1,000 threshold). AML/CFT pre-launch and ongoing supervision per §D.2.1.

Source-document anchoring. Mgr. Ondrej Syllaba opinion (LEG-OP-SYLLABA-GIFT-CZ-2026-05-13, grc.grc_document.id=87) for trade-licence scope; EU MiCAR primary law (Reg (EU) 2023/1114) cited directly; MiFID II primary law (Directive 2014/65/EU) cited directly.

D.6.2 Nigeria

The Group operative entity is Mansa Musa Integrated Solutions Nigeria Ltd, with the Accelerated Regulatory Incubation Programme application LIC-2026-007 pending_application with the Securities and Exchange Commission, Nigeria. The Nigerian entity is not operational at the time of publication; commercial $GIFT distribution to Nigerian residents is contingent on ARIP admission [E:LIC-2026-007] [FORWARD-LOOKING].

A separate Digital Asset Custodian (DAC) registration consideration arises under SEC Digital Assets Rules 2022 Part C Rule 29.0. The uTribe customer wallet is non-custodial: holders self-custody $GIFT in their own Polygon wallets (see §6 and §7). The non-custodial wallet model does not engage the DAC registration requirement.

Operational scope. On ARIP admission, customer-class determination is performed at onboarding by the region-specific distribution counterparty operating the customer-facing platform under its own SEC DAOP registration (pending_application). Travel Rule application per §D.4.3. AML/CFT pre-launch per §D.2.2. Wind-down per §D.5.2.

Source-document anchoring. Legalpreneur Attorneys and Consulting LP legal opinion on regulatory classification of $GIFT under Nigerian law (LEG-OP-LEGALPRENEUR-GIFT-NG, grc.grc_document.id=84); SEC Digital Assets Rules 2022 + MLPPA 2022 + ISA 2025 primary law cited directly.

D.6 Material-change notification matrix

For each operative perimeter, the issuer commits to material-change notification on the basis of the home-perimeter framework. The trigger for each perimeter includes, at minimum, any of: the consensus mechanism, the custodian or custody arrangements, the gold-per-token ratio, the operative entity framework, the offer cap or subscription mechanics, the pricing methodology, the fee schedule, the risk-factor set, or the supply mechanics.

D.7 Complaints handling — jurisdiction matrix

The Group-level baseline at §13.6.3 (email to [email protected] or contact form on the issuer's web portal; investigation by the issuer's designated Complaints Officer in accordance with MiCAR Article 31) applies across every operative perimeter. Per-jurisdiction overlays:

D.7.1 European Union (and European Economic Area)

• Framework: MiCAR Article 31; EU Directive 2013/11/EU on alternative dispute resolution for consumer disputes; Directive 2014/17/EU; EU Online Dispute Resolution (ODR) platform.
• Escalation pathway: Financial Arbitrator of the Czech Republic (Finanční arbitr); EU ODR platform.
• Responsible Group entity: Ubuntu Uhuru s.r.o. [E:LIC-2026-003].

D.7.2 Nigeria

• Framework: SEC Digital Assets Rules 2022 customer-protection provisions; Central Bank of Nigeria (CBN) Consumer Protection Framework; Federal Competition and Consumer Protection Act 2018.
• Escalation pathway: SEC Nigeria Investor Complaint Management Framework; CBN Consumer Protection Department; Federal Competition and Consumer Protection Tribunal as relevant.
• Responsible Group entity: Mansa Musa Integrated Solutions Nigeria Ltd [E:LIC-2026-007], on activation of the Nigerian perimeter.

D.7.3 United Arab Emirates

• Framework: VARA Compliance and Risk Management Rulebook complaints provisions; UAE Federal Consumer Protection Law.
• Escalation pathway: VARA complaints framework; UAE Ministry of Economy consumer-protection channels.
• Responsible Group entity: Mansa Musa Digital [E:LIC-2026-004], on activation of the UAE perimeter. [FORWARD-LOOKING]

D.7.4 United Kingdom (where applicable to UK consumers acquiring $GIFT through licensed UK virtual-asset service providers)

• Framework: UK Financial Conduct Authority (FCA) Dispute Resolution: Complaints (DISP) sourcebook, where the customer’s licensed virtual-asset service provider is FCA-regulated; UK Financial Ombudsman Service where available.
• Escalation pathway: the licensed UK virtual-asset service provider's complaints framework; FCA DISP; Financial Ombudsman Service.
• Responsible Group entity: none (UK out of perimeter for direct uTribe customer relationships).

D.7.5 Other jurisdictions (FATF baseline)

Where a customer is acquiring $GIFT through a licensed virtual-asset service provider in their home jurisdiction, the licensed counterparty’s home-supervisor complaints framework applies. The Group-level baseline at §13.6.3 remains available to every holder regardless of jurisdiction.

D.8 Regulatory characterisation per jurisdiction

The Group-level position at §3.6 — $GIFT technically architected as an Asset-Referenced Token under MiCA, with final characterisation in each regime subject to competent-authority determination — is overlaid per jurisdiction below. Jurisdictions are ordered by operational status (live licences first, pending second) and within a tie by capital-markets importance.

D.8.1 European Union (and European Economic Area)

• Regulation: Regulation (EU) 2023/1114 (Markets in Crypto-Assets Regulation, "MiCAR"), Titles II and III; Czech Act No. 31/2025 Coll. on the Digitalisation of the Financial Market (Section 26 transitional regime for Virtual Asset Service Providers).
• Expected characterisation: $GIFT is technically architected as an Asset-Referenced Token (ART) under MiCAR Title III. An alternative characterisation as a Title II "other crypto-asset" referencing a commodity has been preserved in counsel opinion (Mgr. Ondřej Syllaba opinion LEG-OP-SYLLABA-GIFT-CZ-2026-05-13); final characterisation is subject to Czech National Bank (CNB) determination on the MiCAR Crypto-Asset Service Provider authorisation under LIC-2026-011.
• Supervising authority: Czech National Bank (CNB) for MiCAR authorisation; European Securities and Markets Authority (ESMA) for the EU central register of crypto-asset whitepapers under MiCAR Article 109; AML supervisor for the Group entity is the Finanční analytický úřad (FAÚ), Czech Republic.
• Responsible Group entity: Ubuntu Uhuru s.r.o. (Czech Republic) [E:LIC-2026-003] for the Czech VASP trade licence issued 2024-07-03 by the Authority of Prague 8 City Ward, indefinite term; same entity for the MiCAR CASP authorisation LIC-2026-011, pending_application with the CNB.
• Operational status: Czech VASP trade licence live; MiCAR CASP authorisation pending. [FORWARD-LOOKING for LIC-2026-011]
• Operational scope: $GIFT issuance and virtual-asset services in the Czech Republic under the Czech VASP trade licence; EU passporting subject to grant of the MiCAR CASP authorisation and confirmation of the Title II or Title III characterisation by the CNB. Whitepaper notification under MiCAR Article 8 (Title II) or Article 17 (Title III) follows from the CNB determination.

D.8.2 United Arab Emirates

• Regulation: Virtual Assets Regulatory Authority (VARA) Virtual Assets Regulations and the VARA Compliance and Risk Management Rulebook; Federal Decree-Law No. 20 of 2018 on Anti-Money Laundering and Combating the Financing of Terrorism and the Financing of Illegal Organisations (as amended).
• Expected characterisation: $GIFT's expected characterisation is consistent with a commodity-referenced virtual asset under the VARA Virtual Assets Regulations. Final classification is subject to VARA determination on the grant of the licence.
• Supervising authority: Virtual Assets Regulatory Authority (VARA), Dubai. National AML supervisor under Federal Decree-Law No. 20 of 2018 is the Central Bank of the UAE.
• Responsible Group entity: Mansa Musa Digital [E:LIC-2026-004], VARA licence pending_application.
• Operational status: Pending licence. [FORWARD-LOOKING] Commercial operation under VARA supervision is contingent on grant of the licence.
• Operational scope: On grant, $GIFT distribution to UAE-resident customers under VARA supervision, on the characterisation determined by VARA at the time of the grant.

D.8.3 Nigeria

• Regulation: Investments and Securities Act 2025 (ISA 2025), in particular Section 357 (white-paper liability) and the underlying definition of "security"; Securities and Exchange Commission Rules on Issuance, Offering Platforms and Custody of Digital Assets, 2022 ("SEC Digital Assets Rules 2022") read with the Accelerated Regulatory Incubation Programme (ARIP); Money Laundering (Prevention and Prohibition) Act 2022 (MLPPA 2022).
• Expected characterisation: $GIFT is expected to be characterised as a digital asset within scope of the SEC Digital Assets Rules 2022 and ISA 2025. Final classification is subject to determination by the Securities and Exchange Commission, Nigeria, in the course of the ARIP application and subsequent Digital Asset Offering Platform (DAOP) / Digital Asset Exchange (DAX) registration considerations. A classification opinion of Nigerian counsel (Legalpreneur LP opinion LEG-OP-LEGALPRENEUR-GIFT-NG, grc.grc_document.id=84, status superseded — pending re-issue against version 1.2 of this whitepaper as sole authoritative input document) addresses the SEC classification prongs in detail and a recommended pathway (SEC classification → ARIP → DAOP/DAX → Digital Asset Custodian considerations → quarterly Proof-of-Reserves by the Group auditor → Central Bank of Nigeria no-objection). The current citation is for transparency of the audit trail; readers should rely on the re-issued opinion once delivered (the re-issued opinion will be filed under a new document code and the citation in this paragraph updated accordingly).
• Supervising authority: Securities and Exchange Commission, Nigeria, for ARIP / DAOP / DAX / Digital Asset Custodian (DAC) considerations; Nigerian Financial Intelligence Unit (NFIU) under MLPPA 2022; Central Bank of Nigeria (CBN) on a no-objection basis where the recommended pathway engages CBN.
• Responsible Group entity: Mansa Musa Integrated Solutions Nigeria Ltd [E:LIC-2026-007], ARIP application pending_application with the SEC.
• Operational status: Pending licence. [FORWARD-LOOKING] Commercial operation in Nigeria is contingent on ARIP admission, classification confirmation, and the subsequent steps in the recommended pathway.
• Operational scope: On admission, $GIFT distribution to Nigerian-resident customers in accordance with the SEC's classification, the ARIP perimeter, and the subsequent DAOP/DAX/DAC pathway. The non-custodial wallet model (see §6 and §7) does not engage the Digital Asset Custodian registration requirement under SEC Digital Assets Rules 2022 Part C Rule 29.0. Naira-denominated fiat disbursement rails for redemption against the issuer's reserve are assessed for fitness for the Nigerian market under the Nigerian regulatory pathway, including a no-objection from the Central Bank of Nigeria (CBN) on the offshore custody structure and the Nigerian-Naira-to-USD settlement flows where required; the operational specifics of the Nigerian rail panel (payment-services provider identity, Naira-denominated settlement bank, clearing window, currency-conversion cost band, statutory and supervisor-imposed limits) are set out in the Nigerian-market customer Terms and Conditions at onboarding, where they are updated in line with the Securities and Exchange Commission, Nigeria's prescribed levels from time to time. Marketing materials distributed to Nigerian residents are pre-cleared by the SEC under SEC Digital Assets Rules 2022, must not make misleading representations regarding gold-backing, value preservation, or investment returns, and prominently disclose the retail investment limits prescribed by the SEC under Part A Rule 8.0 (Naira-denominated; see the Nigerian-market Terms and Conditions).

D.8.4 Luxembourg

• Regulation: Pathway to be determined among (i) the EU Prospectus Regulation (Regulation (EU) 2017/1129), (ii) the EU DLT Pilot Regime under Regulation (EU) 2022/858, or (iii) MiCAR Title II or Title III.
• Expected characterisation: $GIFT-adjacent issuance under a planned Security Token Offering (STO) framework; expected characterisation as a transferable security under the Prospectus Regulation, or a DLT financial instrument under the DLT Pilot Regime, or an asset-referenced or other crypto-asset under MiCAR, depending on the pathway selected. Final characterisation is subject to determination by the Commission de Surveillance du Secteur Financier (CSSF) on the pathway selected.
• Supervising authority: Commission de Surveillance du Secteur Financier (CSSF), Luxembourg.
• Responsible Group entity: Luxembourg issuing entity to be identified as part of the pathway-selection workstream [E:LIC-2026-012], CSSF authorisation pending_application.
• Operational status: Pending application; pathway selection and entity formation in progress. [FORWARD-LOOKING]
• Operational scope: On selection of the pathway and grant of the relevant authorisation, $GIFT-adjacent STO issuance to qualifying investors as defined under the selected framework.

D.8.5 Other jurisdictions

In jurisdictions where the Group has not progressed a licence application, $GIFT acquisition is gated through licensed virtual-asset service providers in the holder's home jurisdiction. The expected characterisation in any such home jurisdiction is the characterisation determined by that home supervisor for crypto-assets of the same architecture as $GIFT (commodity-referenced, allocated-custody). The Group-level Czech VASP licence (§D.8.1) is the operative perimeter through which holders interact with the issuer for redemption against the reserve, subject to the operational scope at §D.4.4.

Appendix B — Glossary

The definitions below are provided for reader convenience in interpreting this whitepaper. They are not intended to limit, expand, or override the meaning of any term as defined under the applicable primary law in any jurisdiction. A fuller curated definitions register, including additional terms referenced incidentally in this whitepaper (such as OFAC, ESMA, EEA, and MiFID II), is maintained by the issuer and is available on written request through the evidence-access channel at §13.5 [E:WP-GLOSSARY].

Appendix C — KYC-state reconciliation: technical field reference

This appendix provides the engineering-level detail behind §5.3. It is intended for technical readers (auditors, engineering teams, regulators reproducing the verification) and is not required reading for a credit/risk review.

The ComplianceRegistry contract holds per-wallet state in the following fields, returned by a single accounts(address) view call [E:KYC-STATE-FIELDS]:

A separate read-only call, canTransact(address, uint256 amountUSD, uint8 minLevel), simulates the gate decision and returns (bool allowed, string reason). uTribe's verification fixture parameterises canTransact(address, 0, 2) to test the whitelist, KYC-tier, and freeze logic without invoking the spend-bucket arithmetic.

For each wallet recorded as KYC-verified in the off-chain customer database, the on-chain state is required to satisfy:

• accounts(address).whitelisted == true
• accounts(address).kycLevel ≥ 1 (or ≥ 2 for any single transaction at USD $1,000 or more)
• accounts(address).frozen == false
• canTransact(address, 0, 2) == (true, "OK")

Deviation is logged before the run is reported as clean [E:HT-DOC-KYC-PROCEDURE].