# Executive summary What is the Dabba network and the Dabba token ? The Dabba network is a [DePIN](https://messari.io/report-pdf/f125632168e9a04e016fe43bc551f412389eda4f.pdf) marketplace designed to bring together all necessary stakeholders to deliver high speed internet access in the emerging markets, starting with **India**. The mission of the Dabba network is to bring a billion Indians internet access over the next decade. The Dabba Network uses the DBT token to incentivise its community and stakeholders to build the network. {% hint style="info" %} **Demand for data in India is skyrocketing, according to** [**Nokia MBiT Index**](https://www.nokia.com/about-us/company/worldwide-presence/india/mbit-index-2023/) * Data traffic jumped 3.2x in last five years and reached 14.4 Exabyte in 2022 * Average data per user per month grew 2x in last five years * Mobile data in India will grow more than double by 2024. {% endhint %} **Bringing super cheap, super fast internet for the next billion users** {% embed url="" %} Relative to its population, India lags behind most other countries in broadband penetration. The US has [112M](https://datasetsearch.research.google.com/search?ref=TDJjdk1URndkMlkxTm5Bd1lnPT0sTDJjdk1URndlRE5qZUhKc1p3PT0sTDJjdk1URnFjekppYW1NeE1BPT0%3D\&query=number%20of%20fixed%20line%20broadband%20connections%20usa\&docid=L2cvMTFwd2Y1NnAwYg%3D%3D) broadband connections, China has [612M](https://datasetsearch.research.google.com/search?ref=TDJjdk1URndkMlkxTm5Bd1lnPT0sTDJjdk1URndlRE5qZUhKc1p3PT0sTDJjdk1URnFjekppYW1NeE1BPT0%3D\&query=number%20of%20fixed%20line%20broadband%20connections%20usa\&docid=L2cvMTFwd2Y1NnAwYg%3D%3D) connections, whereas India has only [30M](https://pib.gov.in/PressReleseDetailm.aspx?PRID=1869222). Unlike developed telecom markets that normally have a few near-monopoly service providers, the developing Indian market is still in its growth stage with high fragmentation and no clear winners as yet. Using the principles of DePin networks, Dabba aims to aggregate the over [150,000 Local Cable Operators (LCO)](/earning-dbt/lco-reward-specification) in India. The Dabba network will provide them with hardware, software, marketing, customer support and access to low cost capital to scale their existing networks. Today, the average LCO has a subscriber base of about 300 connections. Given the density of unconnected homes & small businesses, each LCO has a market opportunity to grow their customer base by 10x. Dabba will enable each of these LCOs by providing the necessary tools and means to scale their networks. The roles of stakeholders in the network can be expressed in two categories: 1. **Connectivity enablers** whose role is the physical creation, deployment and maintainance of the network. These stakeholders are LCOs, hardware manufacturers, hotspot owners, location owners and backhaul providers. 2. **Connectivity users** who consume data on the network. The Dabba token uses a mint and burn model and will launch on Solana Blockchain before Q3'24. The Dabba token has a maximum supply of 10B and has a fixed emission schedule. Tokens are rewarded to connectivity enablers in return for helping create the network. Tokens are burned when users consume data on the network.​ Founded in 2017 and backed by YCombinator, Multicoin Capital, Borderless Capital and angel investors, the team has been pioneering low-cost public wifi over the last 8 years. This includes powering Google’s public Wifi. Our contributions have been instrumental in drafting the necessary telecom legislation that dramatically increases the pace of broadband penetration in India. # How it works Decentralised market place for WiFi connectivity in India {% hint style="info" %} [**Checkout the live Dabba network explorer ->**](https://explorer.dabab.network) {% endhint %} {% hint style="info" %} [**Checkout the live Messari dashboard tracking Dabba ->**](https://messari.io/dashboards/dabba-network) {% endhint %} The Dabba network enables a decentralised marketplace to aggregate providers of connectivity with people who need connectivity. The marketplace includes all the stakeholders necessary to successfully deliver high speed internet access via wifi to end consumers needing connectivity. These stakeholders include local cable operators, hotspot owners, end consumers who need internet, location owners, bandwidth providers and hardware manufacturers.

Dabba marketplace

The marketplace is a decentralised platform with series of smart contracts on the Solana blockchain that sets the token incentive allocation to each party. This ensures a transparent and fair distribution to all stakeholders relative to their value contributed to the network. Allocations can be amended over time through Dabba Improvement Proposals. ### Stakeholder definitions: {% embed url="" %} #### Hotspot owners (HO) An individual or an entity that buys a compatible hotspot and leases it out on the Dabba Network to a LCO for provisioning, thereby helping data consumers access the internet. **Local cable operator (LCO)** Local cable operators list their networks on the marketplace, displaying their existing networks along with capabilities and reputational indicators such as uptime, customer reviews, etc. Competition arises between local cable operators to attract hotspot owners to choose their networks for deployment. #### Data consumers Data consumers browse local cable operators on the network and choose the best service provider for them and available a Dabba Wifi connection for there home or office. **Location owners** Location owners who own multiple locations or large venues list their locations for installation. Local cable operators and hotspot owners compete for installation rights. #### Backhaul providers Backhaul providers offer core internet connectivity. This allows local cable operators and location owners to access competitive backhaul pricing. **Hardware manufacturers** Hardware manufactures list their Dabba Network compatible hotspots with capabilities that compete for local cable operator and hotspot owners' requirements. # Why it works Aggregating a fragmented market into a platform is a tried and tested strategy in the web2 world by Uber, AirBnB, Doordash and many others {% hint style="info" %} Aggregating over [150,000 Local cable operator](broken://pages/yVo9RwG9LV9hf80f0BVf)s (LCO) in India to cater to surging demand offers several advantages as a internet service delivery model {% endhint %} {% embed url="" %} **1. Wider Coverage**: India is a vast country with diverse geographic areas. Aggregating small LCOs allows for a quicker expansion of services to remote or underserved regions where larger ISPs might not have a presence. This can attract customers looking for reliable internet access in these areas. **2. Infrastructure and Resources**: Small LCOs often have localized infrastructure and established customer bases. By aggregating them, the Dabba network leverages these existing resources, such as network infrastructure, customer relationships, and local expertise, to scale operations more efficiently. **3. Competitive Edge**: Combining the strengths of multiple small LCOs create a more competitive offering in terms of pricing, service quality, and technological advancements. This aggregated entity can compete better with larger, established ISPs in the market. **4. Faster Market Penetration**: Instead of starting from scratch, aggregating small LCOs allows for a quicker entry into the market. This is particularly beneficial in a rapidly growing market like India, where demand for internet services is high. **5. Regulatory Compliance**: Small LCOs face challenges in complying with various regulations. Aggregating them under a larger entity streamlines regulatory processes and ensure better compliance, facilitating smoother operations. **6. Enhanced Service Portfolio**: Each LCO currently offers a narrow range of services to its customers. By aggregating them, the Dabba network can offer a diverse range of services, potentially attracting a broader customer base with varied needs. Functionality such as Wifi Roaming is possible on the Dabba Network. # Mint, Buyback & Burn Understanding how Dabba tokens move through the Dabba network ### Overview The Dabba Network implements a structured revenue allocation framework designed to: • Reduce circulating DBT supply\ • Align incentives across infrastructure contributors\ • Maintain operational sustainability\ • Introduce predictable token demand driven by real revenue All buybacks are funded exclusively through fiat revenue generated from broadband service operations. ### Revenue Allocation Framework Let: Rₜ = Total fiat revenue generated in month t Revenue is allocated across stakeholder categories according to fixed minimum thresholds. The allocation structure is as follows: | Category | Allocation % | Treatment | | ---------------------------------- | ------------ | -------------------------- | | LCO Buyback (P2) | ≥ 45% | Tokens bought and burned | | Bandwidth Provider Settlement (P1) | ≥ 30% | Tokens acquired and burned | | Hotspot Owner Reserve (P4) | 5% | Tokens bought, not burned | | Operating Company (Dabba Inc) (P3) | 20% | Retained for operations | Total allocation: Rₜ = R\_LCO + R\_BW + R\_HO + R\_INC Where: R\_LCO ≥ 0.45 Rₜ\ R\_BW ≥ 0.30 Rₜ\ R\_HO = 0.05 Rₜ\ R\_INC = 0.20 Rₜ #### Revenue-Backed Buyback Commitment for LCO and Bandwidth Providers In every epoch, 37% of total DBT emissions are allocated to infrastructure operators, including Local Cable Operators (LCOs) and Bandwidth Providers. These participants are essential to the physical expansion and maintenance of the network. To align token economics with real-world revenue, the protocol commits a minimum of 75% of all fiat revenue generated from broadband operations to purchasing DBT from these operator categories. This commitment is revenue-based, not token-based. The number of tokens repurchased each epoch depends on: * Total revenue generated * The prevailing market price of DBT **How It Works** If revenue is strong relative to token price, the protocol may absorb the entire 37% allocation issued to LCOs and Bandwidth Providers in that epoch. In such cases, all acquired tokens are burned, creating meaningful supply reduction. If revenue is insufficient to absorb the full 37%, the protocol still deploys 75% of revenue toward buybacks. Any remaining tokens not purchased remain with operators, who may retain them or sell them on the open market. This design ensures: * A structural, revenue-backed floor of token demand * Predictable buy pressure independent of market sentiment * Operator flexibility under varying economic conditions * Long-term alignment between network growth and token supply As revenue scales and emissions decline over time, the system naturally increases its capacity to absorb operator allocations, strengthening supply discipline. This mechanism directly links broadband adoption to token demand, creating a closed-loop economic model grounded in real-world usage. **Working formula** Let: * E\_t = total DBT emitted in epoch t * R\_t = total fiat revenue in epoch t * P\_t = epoch-average DBT price The total DBT allocated to LCO and Bandwidth Providers is: $$ T\_{LBW,t} = 0.37 , E\_t $$ The protocol’s minimum buyback budget for these categories is: $$ R\_{buy,t} = 0.75 , R\_t $$ The maximum quantity of DBT that can be purchased using this budget is: $$ B\_{LBW,t} = \frac{0.75 , R\_t}{P\_t} $$ **Buyback Outcomes** **Full Absorption** If: $$ B\_{LBW,t} \ge T\_{LBW,t} $$ the protocol can absorb the entire LCO and Bandwidth allocation. Tokens acquired under this mechanism are burned. **Partial Absorption** If: $$ B\_{LBW,t} < T\_{LBW,t} $$ the unpurchased balance remains with operators: $$ U\_t = T\_{LBW,t} - B\_{LBW,t} $$ This remaining balance may be retained or sold on secondary markets by LCOs and Bandwidth Providers. This mechanism ensures a revenue-backed minimum level of token demand while maintaining operator flexibility under varying revenue and token price conditions. #### Why This Structure Is Strong • Buyback is revenue-driven, not token-driven\ • As revenue grows, absorption approaches or exceeds 37%\ • As emissions decay 10% annually, required revenue to absorb 37% declines\ • Long-term, revenue can exceed emission supply It creates: Revenue floor → Buy pressure floor → Supply discipline ### Hotspot Owner Liquidity Pool (5% Revenue Allocation) In addition to the LCO and Bandwidth buyback commitments, the protocol allocates **5% of monthly fiat revenue** to a dedicated Hotspot Owner (HO) liquidity pool. This pool is designed to provide predictable, revenue-backed liquidity to hotspot operators. #### Structure Let: * R\_t = total fiat revenue in epoch t The monthly Hotspot Owner liquidity allocation is: $$ R\_{HO,t} = 0.05 , R\_t $$ These funds are used by the Foundation to purchase DBT from Hotspot Owners at prevailing market prices. The quantity of tokens that can be absorbed in epoch t is: $$ B\_{HO,t} = \frac{0.05 , R\_t}{P\_t} $$ Where: * P\_t = average DBT market price during the epoch *** ### Liquidity Function This 5% of revenue is allocated for liquidity functions as a **recurring protocol-sponsored liquidity pool.** ### Operating Allocation (20% Revenue Retained by Dabba Inc) To ensure long-term operational sustainability, **20% of total fiat revenue** generated each epoch is retained by Dabba Inc. This allocation is not used for token buybacks and does not directly affect circulating DBT supply. #### Structure Let: * R\_t = total fiat revenue in epoch t The operating allocation is: $$ R\_{INC,t} = 0.20 , R\_t $$ These funds are retained in fiat and used exclusively to support network operations and growth. ### Purpose of the Operating Allocation The 20% operating pool funds: * Network monitoring and maintenance * Engineering and product development * Regulatory compliance * Hardware logistics and support * Administrative and infrastructure costs * Market expansion and deployment operations This ensures the network can scale without relying on token emissions to fund real-world expenses. ### Economic Rationale The Dabba model is designed so that: * 75% of revenue creates token demand (LCO + Bandwidth buybacks) * 5% of revenue creates structured liquidity for Hotspot Owners * 20% of revenue sustains operational infrastructure This creates a self-funded operating structure tied directly to broadband adoption. Unlike many token networks that rely on treasury token sales to fund operations, Dabba Inc is revenue-backed. ### Long-Term Sustainability Because this allocation scales linearly with revenue: * Operational funding increases as the network grows * Token emissions are not required to subsidize expenses * The protocol avoids structural dependency on token inflation This design separates: * Revenue-based business sustainability * Token-based incentive coordination The result is a system where real-world cash flow supports operational growth, while token mechanisms coordinate infrastructure incentives. # Current Network Metrics > **Note:** The numbers in this document are indicative and not final. They reflect the current framework discussed in Townhall 23 and may change based on community feedback and final launch parameters. We recommend reading this alongside the Townhall recording for full context. This section applies the token architecture to Dabba’s current operating metrics. ### Baseline Assumptions * Active Hotspots: 120,000 * Monthly ARPU: $7 * Monthly Hotspot Growth: 20% * Initial Annual Emission: 600,000,000 DBT * Emissions decline 10% annually * Token Price (illustrative): $0.05 ## 1. Current Monthly Revenue Monthly revenue: $$ R\_{month,0} = 120{,}000 \times 7 = 840{,}000 $$ Annualized revenue: $$ R\_{year,0} = 840{,}000 \times 12 = 10{,}080{,}000 $$ ## 2. Revenue Allocation Today From monthly revenue of $840,000: * 75% LCO + Bandwidth Buyback: $$ 0.75 \times 840{,}000 = 630{,}000 $$ * 5% HO Liquidity Pool: $$ 0.05 \times 840{,}000 = 42{,}000 $$ * 20% Operating Allocation: $$ 0.20 \times 840{,}000 = 168{,}000 $$ ## 3. Tokens Absorbed at $0.05 Price Monthly LCO + Bandwidth buyback capacity: $$ B\_{LBW} = \frac{630{,}000}{0.05} = 12{,}600{,}000 \text{ DBT} $$ Monthly HO liquidity absorption: $$ B\_{HO} = \frac{42{,}000}{0.05} = 840{,}000 \text{ DBT} $$ Total monthly token demand created by revenue: 13,440,000 DBT ## 4. Emissions Comparison (Year 1) Year 1 emissions: $$ E\_1 = 600{,}000{,}000 \times 0.9 = 540{,}000{,}000 $$ Monthly emissions: $$ 45{,}000{,}000 \text{ DBT} $$ LCO + Bandwidth share (37%): $$ 0.37 \times 45{,}000{,}000 = 16{,}650{,}000 \text{ DBT} $$ At current revenue: * Protocol absorbs 12.6M DBT per month * 16.65M DBT allocated to LCO + BW * Remaining ≈ 4.05M DBT may remain with operators This reflects early-stage partial absorption. ## 5. 12-Month Growth Projection (20% MoM) Hotspots after 12 months: $$ 120{,}000 \times (1.2)^{12} \approx 1{,}069{,}920 $$ Monthly revenue after 12 months: $$ 1{,}069{,}920 \times 7 \approx 7{,}489{,}440 $$ Annualized revenue: ≈ $89.9M ## 6. Buyback Capacity After 12 Months 75% allocation: $$ 0.75 \times 7{,}489{,}440 = 5{,}617{,}080 $$ Monthly tokens absorbed at $0.05: $$ \frac{5{,}617{,}080}{0.05} = 112{,}341{,}600 \text{ DBT} $$ Compare with Year 1 monthly LCO + BW allocation: 16,650,000 DBT Result: Buyback capacity exceeds allocation by \~95.7M DBT per month. This implies: * Full absorption of LCO + Bandwidth allocation * Additional secondary market absorption * Strong net burn pressure ## 7. Structural Implication With an initial emission of 600M DBT declining 10% annually: * Emissions fall predictably each year * Revenue scales with hotspot growth * Buyback capacity grows faster than emissions decline Under sustained 20% MoM growth, the model transitions from partial absorption to structural over-absorption within 12 months. This creates a measurable path toward: * Full allocation absorption * Net deflation * Supply tightening anchored to broadband adoption # Path to Net Deflation > **Note:** The numbers in this document are indicative and not final. They reflect the current framework discussed in Townhall 23 and may change based on community feedback and final launch parameters. We recommend reading this alongside the Townhall recording for full context. The network becomes structurally deflationary when annual token burn exceeds annual emissions. ### Deflation Condition Net deflation occurs when: $$ Burn\_t > E\_t $$ Where: * E\_t = total annual emissions * Burn\_t = tokens purchased and burned from revenue Burn is determined by: $$ Burn\_t = \frac{0.75 , R\_t}{P\_t} $$ Therefore, the deflation condition becomes: $$ \frac{0.75 , R\_t}{P\_t} > E\_t $$ Solving for required revenue: $$ R\_t > \frac{E\_t , P\_t}{0.75} $$ This defines the minimum revenue needed to achieve net supply contraction at a given token price. ## Emission Schedule (600M Baseline) Year 1: $$ E\_1 = 540{,}000{,}000 $$ Year 2: $$ E\_2 = 486{,}000{,}000 $$ Year 3: $$ E\_3 = 437{,}400{,}000 $$ ## Revenue Projections * Year 1: $89.9M * Year 2: $134.9M * Year 3: $202.4M Buyback budget each year: $$ 0.75 \times R\_t $$ ## Crossover Analysis at Different Token Prices ### Case A : Token Price = $0.05 Required revenue for deflation (Year 1): $$ R > \frac{540{,}000{,}000 \times 0.05}{0.75} $$ $$ R > 36{,}000{,}000 $$ Actual projected revenue: $89.9M Result: **Deflation achieved in Year 1** ### Case B : Token Price = $0.10 Required revenue (Year 1): $$ R > 72{,}000{,}000 $$ Projected revenue: $89.9M Result: **Deflation achieved in Year 1** ### Case C : Token Price = $0.20 Required revenue (Year 1): $$ R > 144{,}000{,}000 $$ Projected revenue: $89.9M Result: Not deflationary in Year 1 Year 2 requirement: $$ R > \frac{486{,}000{,}000 \times 0.20}{0.75} $$ $$ R > 129{,}600{,}000 $$ Projected Year 2 revenue: $134.9M Result: **Deflation achieved in Year 2** ### Case D — Token Price = $0.50 Year 1 requirement: $$ R > 360{,}000{,}000 $$ Not achieved. Year 2 requirement: $$ R > 324{,}000{,}000 $$ Not achieved. Year 3 requirement: $$ R > \frac{437{,}400{,}000 \times 0.50}{0.75} $$ $$ R > 291{,}600{,}000 $$ Projected Year 3 revenue: $202.4M Result: Not yet deflationary at $0.50 by Year 3. ## Summary Table | Token Price | Crossover Year | | ----------- | -------------- | | $0.05 | Year 1 | | $0.10 | Year 1 | | $0.20 | Year 2 | | $0.50 | Beyond Year 3 | *** ## Structural Insight Because: * Emissions decline 10% annually * Revenue scales with network growth The revenue threshold for deflation declines over time. As broadband adoption increases, the system naturally transitions from: Early-stage inflation → Neutral supply → Net deflation. The crossover year is mathematically determined by revenue growth, token price, and emission decay, not speculation. This creates a transparent and measurable path toward structural supply contraction. # Token allocation & supply This section defines DBT supply, allocations, and the token release schedule ### Supply Overview * **Total Supply at Genesis (minted at TGE):** 4,890,000,000 DBT * **Max Supply:** 10,000,000,000 DBT Genesis supply represents tokens minted at TGE across non-emission allocations. Max supply includes long-term emissions. The relationship is: $$ S\_{max} = S\_{genesis} + S\_{emissions} $$ Where: * S\_genesis = 4,960,031,642 * S\_max = 10,000,000,000 * S\_emissions = 5,039,968,358 *** ### Token Allocation (Max Supply Basis) All allocations below are expressed as a % of **Max Supply**. | Allocation Bucket | Tokens | % of Max Supply | | --------------------------- | -----------------: | --------------: | | Seed Investors | 845,600,000 | 8.456% | | Private presale (investors) | 295,000,000 | 2.950% | | Foundation / Treasury | 1,339,400,000 | 13.394% | | Team | 1,520,000,000 | 15.200% | | Community Genesis | 960,031,642.15 | 9.600% | | Emission Rewards | 5,039,968,358 | 50.396% | | **Max Supply** | **10,000,000,000** | **100.00%** | ### Circulating Supply at TGE Circulating supply at TGE is defined as the subset of genesis-minted tokens that are unlocked and transferable at TGE. * **Circulating Supply at TGE:** 184,689,382 DBT * **Circulating % at TGE (total):** \~ 1.84% of total supply. ## Release Schedule Summary The release schedule is defined in epochs (monthly). Below is a summary of when each bucket begins releasing and when it completes its release within the modeled horizon. > Note: Emission rewards continue beyond the modeled monthly horizon, with a remaining “thereafter” balance. ### Exchange / Airdrop * ``` | SAFT | 24,583,333 | ``` ``` | -------------------- | ----------- | | Foundation | 100,000,000 | | Airdrop | 16,556,500 | | 15 day Genesis bonus | 38,443,500 | | Genesis | 3,462,214 | | EPOCH | 1,643,835 | ``` * One-time unlock ### Foundation / Treasury Unlocked in tranches: * **100,000,000 DBT** at TGE * **200,000,000 DBT** on 2026-08-31 * **300,000,000 DBT** on 2026-12-31 * **250,000,000 DBT** on 2027-12-31 * **304,400,000 DBT** on 2028-12-31 Total: **1154,400,000 DBT** ### Private Sale * **Starts:** AT TGE - 10% Unlock * **Ends:** 2027-10-01 * Cliff: 6 months * **Structure:** 11 monthly unlocks Monthly unlock: $$ \frac{295{,}000{,}000.01}{12} \approx 24{,}583{,}333.33 \text{ DBT/month} $$ ### Community Genesis * **Starts:** AT TGE, Day 1 unlock of 3,308,600 DBT * **Ends:** 2028-04-30 * **Structure:** staged monthly unlocks totalling 840,030,000 DBT This bucket unlocks in phases: 1. **102,000,000 DBT/month** for 4 months 2. **30,000,000 DBT/month** for 14 months 3. Final month: **12,030,000 DBT** ### Seed Investors * **Starts:** 2028-04-30 * **Ends:** 2030-03-31 * **Structure:** 24 monthly unlocks Monthly unlock: $$ \frac{845{,}599{,}999.92}{24} \approx 35{,}233{,}333.33 \text{ DBT/month} $$ ### Team * **Starts:** 2028-04-30 * **Ends:** 2030-03-31 * **Structure:** 24 monthly unlocks Monthly unlock: $$ \frac{1{,}519{,}999{,}999.92}{24} \approx 63{,}333{,}333.33 \text{ DBT/month} $$ ## Emission Rewards and Long-Term Supply Estimated Validator / Emission Rewards are distributed over time and represent the largest share of total supply. * **Total Emission Allocation:** 5,159,970,000 DBT * Emissions follow a **10% annual decay**. Annual decay model: $$ E\_n = E\_0 \times (0.9)^n $$ Within the modeled horizon, a portion of emissions unlocks monthly, and the remaining balance is represented as a “thereafter” allocation to complete the max supply schedule ### Summary DBT supply is designed such that: * Non-emission allocations are fully scheduled within the modeled horizon * Emissions continue over a longer period with 10% annual decay * Circulating supply at TGE is materially lower than total genesis supply due to vesting
# Earning DBT This page defines how participants earn DBT tokens through on-chain reward mechanics.\ Rewards transition in structure over time to align early network bootstrap incentives with long-term utilization efficiency. ### Core Reward Pools The Dabba reward system comprises two primary earning mechanisms: 1. **Universal Basic Income (UBI)** 2. **Performance Pool (PP)** These mechanisms operate with different epochs and weightings: * **Year 1:** 100% of rewards are distributed via UBI * **Year 2 onward:** PP is enabled alongside UBI, with protocol governance adjusting weighting as network matures Rewards are distributed at regular epochs (e.g., monthly), computed off-chain, and settled on-chain. ### Definitions Let: * t = epoch index * H\_t = set of active deployed hotspots in epoch t --> total deployed (sum of hotspots owned by community + foundation) * R\_t = total reward tokens allocated for epoch t * UBI\_t = portion of R\_t assigned to UBI * PP\_t = portion of R\_t assigned to Performance Pool * U\_i = UBI share for hotspot i * P\_i = performance score for hotspot i * C\_i = coverage score for hotspot i * D\_i = data throughput score for hotspot i Network governance may adjust relative weights between coverage and throughput in the performance computation. ### Year 1 — Universal Basic Income (UBI) Only For all of **Year 1**, the entire rewards allocation is distributed via UBI. Formally: $$ UBI\_t = R\_t $$ $$ PP\_t = 0 $$ The UBI allocation is distributed equally among all actively participating hotspots: For hotspot i in H\_t: $$ U\_i = \frac{UBI\_t}{|H\_t|} $$ **Key properties:** * All hotspots receive a baseline allocation irrespective of usage * Incentivizes rapid network coverage and bootstrap deployment * Ensures broad participation in the earliest stage This creates a uniform token reward floor ideal for the bootstrap phase. ### Year 2 Onward: Introduction of Performance Pool Starting in **Year 2**, the Performance Pool (PP) is enabled to initiate usage-based reward differentiation. At epoch t (Year 2+): $$ R\_t = UBI\_t + PP\_t $$ Where: * UBI\_t = UBI portion * PP\_t = Performance Pool portion Governance may parameterize: * alpha = fraction of R\_t allocated to UBI * beta = fraction of R\_t allocated to PP * alpha + beta = 1 Example: $$ UBI\_t = \alpha , R\_t $$ $$ PP\_t = \beta , R\_t $$ Protocol governance can adjust alpha and beta over time to balance coverage vs. efficiency incentives. ### Performance Pool Scoring The Performance Pool is allocated proportionally to participant performance metrics including: * Coverage contribution C\_i * Data throughput D\_i Define the composite performance score: $$ S\_i = w\_{cov} \cdot C\_i + w\_{data} \cdot D\_i $$ Where: * w\_cov = coverage weight * w\_data = data throughput weight * w\_cov + w\_data = 1 The total network performance sum: $$ S\_{total} = \sum\_{i \in H\_t} S\_i $$ Then hotspot i’s share of the PP is: $$ P\_i = PP\_t \cdot \frac{S\_i}{S\_{total}} $$ ### Final Reward Computation Per Epoch For hotspot i: #### Year 1 (UBI only) $$ Reward\_{i,t} = U\_i = \frac{R\_t}{|H\_t|} $$ #### Year 2+ (UBI + PP) $$ Reward\_{i,t} = UBI\_{i,t} + P\_i $$ This structure ensures: * All participants receive a baseline reward * Higher utilization and coverage are rewarded proportional to contribution ### Score Normalization To prevent score outliers from dominating rewards: 1. **Coverage C\_i** is normalized by maximum theoretical coverage radius. 2. **Data throughput D\_i** is normalized by network capacity bounds. 3. Final performance score S\_i is bounded to avoid extreme skew. Normalization examples: Let: * C\_max = maximum coverage score * D\_max = maximum throughput score Then: $$ \tilde{C}*i = \frac{C\_i}{C*{max}} $$ $$ \tilde{D}*i = \frac{D\_i}{D*{max}} $$ Composite performance: $$ S\_i = w\_{cov} \cdot \tilde{C}*i + w*{data} \cdot \tilde{D}\_i $$ ### Governance Controls Governance can adjust: * Relative weights w\_cov and w\_data * UBI vs Performance Pool split (alpha and beta) * Reward epoch timing * Normalization parameters These controls provide flexibility for aligning incentives as the network evolves. ### Protocol Notes * Reward computation occurs off-chain and is settled on-chain via a proof of validity * Rewards are distributed in DBT at the start of the next epoch * Participants must meet minimum criteria (active, compliant, up-to-date firmware, etc.) to qualify ### Transition Rationale **Year 1 UBI-only Phase:**\ Supports maximal coverage, fast deployment, and participant onboarding. **Year 2+ Performance Phase:**\ Introduces usage signals to reward efficiency, throughput, and real utilization. This two-phase approach balances early growth with long-term operational meritocracy. ### Summary Rewards are designed to: * Maximize coverage early * Transition to usage optimization * Remain flexible via governance * Scale with network utilization # Hotspot owner Hotspot Owners (HOs) are the foundational infrastructure participants in the Dabba Network.\ They deploy and maintain physical connectivity nodes that generate coverage and throughput for end users. This section defines how Hotspot Owners earn DBT across protocols and epochs. ### Eligibility Criteria To qualify for DBT rewards, a Hotspot Owner must: * Own a compliant hotspot device * Be actively connected and reporting at epoch boundaries * Pass on-chain and off-chain validation checks * Be in compliance with protocol participation rules * Foundation is the hotspot owner for unsold deployed hotspots Compliance is evaluated in each epoch; non-compliant hotspots are excluded from that epoch’s reward calculation. (Applicable year 2 onwards) Hotspot owners are not merely hardware owners on the Dabba Network but play a role as a small business operator as well. Each hotspot is an individual business that requires all the right managerial decisions to be taken for in order to be a successful business. {% embed url="" %} Hotspot owners are building their own little telecom empires within the Dabba network. These owners play a pivotal role in expanding the reach and accessibility of high-quality internet services, while also opening doors to DBT rewards and community engagement. By purchasing and provisioning Dabba network compatible hotspots in various locations, owners become integral to the network's expansion. They facilitate seamless connectivity for users in homes, offices, cafes, and public spaces, contributing to an enhanced digital experience for individuals within these venues. Hotspot owners not only provide a valuable service but also potentially attract more foot traffic or extended visits to the locations where their hotspots are installed, creating opportunities for increased engagement and business growth. Dabba lite hardware is priced at $199 (exclusive of tax). Any individual that wishes to participate has to purchase the Dabba network compatible hardware from a whitelisted hardware manufacturer. Presently, [Wifi Dabba](https://wifidabba.com) is the only approved hardware manufacturer. More will be added going forward. **Once purchased, the hotspot owner needs to lease out the hardware to an LCO for provisioning. The cost involved for this service is paid in DBT.**

How it works

Reward distribution

#### Hotspot onboarding fees (One time)
ProcessDescriptionDBT Equivalent
AttachmentHotspot owner needs to attach the hardware to Dabba Platform. For this, HO needs to burn $ 10 worth of DBT to demonstrate proof of ownership. Once attached, HO gets a unique NFT that is the proof of device ownership and all the token rewards for this hotspot will be transferred to the wallet that holds this NFT$10
LCO leasingStep 2 involves selecting LCO and location from the available providers. A 7 year lease contract is signed with the selected LCO. HO pays $70 worth of DBT for device commissioning.$70
LCO CommissioningOnce commissioned, LCO will burn $10 worth of DBT to demonstrate proof of work.$10
MarketingThe HO selects the marketing provider to promote and market the hotspot availability to end users$10
Total cost of ownership for 1 hotspot is USD $299. While the $199 (plus tax if any) is paid in fiat to the hardware seller, the balance of $100 is rewarded in DBT to the connectivity enablers by the hotspot owner. The hotspot owner can procure DBT via a DEX or from other available sources. One time relocation or LCO switch is complimentary per hotspot. Additional hotspot relocation request or change in LCO will result in fee paid in DBT equivalent of $70. #### Ongoing hotspot fees After deployment, maintaining a hotspot in active service is a continuous process that requires other stakeholders to be incentivised on an ongoing basis. The hotspot owner having received 100% of the rewards proportionate to their ownership of the network is required to distribute those rewards to the necessary stakeholders required to maintain active service. Each stakeholder can set their required reward to ensure a competitive marketplace. Stakeholders can set reward requirements as a fixed number or as a percentage of the hotspot owner's reward per epoch. This will be paid in DBT at a fixed percentage from the rewards earned by HO. | Stakeholder | Role | % of HO epoch reward | | --------------------- | --------------------------- | -------------------- | | LCO | Operations & Maintenance | 25% | | Backhaul provider | Bandwidth Uplink | 12% | | Hardware manufacturer | Warranty & Service | 1% | | Location owner | Physical Installation Space | 2% | | Hotspot owner | Owner of the Device | 60% | ### Reward Components Hotspot Owners earn DBT from two distinct reward components: 1. **Universal Basic Income (UBI) Reward** 2. **Performance Pool (PP) Reward** The proportion of rewards from each component depends on the protocol phase: * **Year 1:** 100% UBI * **Year 2 onward:** UBI + PP ### Epoch Outcome Settlement Reward computation for each epoch is executed off-chain, with results submitted on-chain as a single settlement transaction that: * Verifies hotspot compliance * Normalizes performance scores * Allocates epoch tokens to individual hotspots * Emits event logs for indexing and auditing Tokens are distributed in DBT at the start of the subsequent epoch. ### Key Properties * Rewards scale with adoption, coverage, and usage. * Early participants earn baseline UBI while long-term merit is rewarded via PP. * Normalization prevents disproportionate rewards from extreme outliers. * Hybrid reward structure aligns behavior with coverage and real network value. # LCO Reward Specification #### Local Cable Operator (LCO) Reward Specification A Local Cable Operator (LCO) is a network participant responsible for on-ground infrastructure deployment, management, and operational support of broadband connectivity within a given area. An LCO earns DBT tokens for enabling physical connectivity that supports hotspots, backhaul, and end-user traffic. This section describes how LCOs earn DBT, including eligibility criteria, calculation methodology, and settlement mechanics. ### Eligibility To qualify for reward allocation in epoch t, an LCO must: * Be registered and validated on-chain * Provide documented operational support data for hotspots under its scope * Maintain compliance with performance and uptime requirements * Pass protocol integrity checks Non-compliant or incomplete entries are excluded from reward calculations for that epoch. ### Reward Components LCOs earn rewards from the protocol based on: 1. **UBI Allocation Component** 2. **Performance Pool (PP) Component** The relative contribution of each component depends on the protocol phase: * **Year 1:** 100% UBI * **Year 2 onward:** UBI + PP Each epoch’s total reward allocation assigned to LCOs is derived from the global reward pool emitted by the protocol. ### Year 1: Universal Basic Income (UBI) During Year 1, all epoch reward allocation is distributed via UBI.\ Let: * R\_t = total reward tokens assigned to LCOs in epoch t * L\_t = total number of eligible LCO entries in epoch t Then each LCO i receives: $$ Reward\_{LCO,i,t} = \frac{R\_t}{L\_t} $$ This structure incentivizes early network coverage, broad deployment participation, and rapid onboarding of operational partners. ### Year 2 Onward: UBI + Performance Pool (PP) Beginning in Year 2, LCO rewards follow a hybrid allocation structure with two components: * **UBI Component:** fixed baseline share of $R\_t$ * **Performance Pool Component:** usage and contribution based share Let: * UBI\_t = alpha , R\_t * PP\_t = beta , R\_t * alpha + beta = 1 Governance can tune alpha and beta to balance coverage incentives vs performance incentives. ### Performance Metrics LCO performance is quantified using two primary scores: 1. **Coverage Contribution C\_LCO,i**\ Measures the extension and density of network infrastructure supported by the operator. 2. **Support Throughput D\_LCO,i**\ Captures aggregate traffic volume sustained by hotspots under the operator’s management. A composite score for each LCO $i$ is defined: $$ S\_{LCO,i,t} = w\_{cov} \cdot \tilde{C}*{LCO,i,t} + w*{data} \cdot \tilde{D}\_{LCO,i,t} $$ #### Normalization Let: * C\_max,t = maximum coverage score among eligible LCOs in epoch t * D\_max,t = maximum throughput score among eligible LCOs in epoch t Then: $$ \tilde{C}*{LCO,i,t} = \frac{C*{LCO,i,t}}{C\_{max,t}} $$ $$ \tilde{D}*{LCO,i,t} = \frac{D*{LCO,i,t}}{D\_{max,t}} $$ This prevents single outliers from skewing the pool. *** ### Performance Pool Allocation For each LCO i, the PP reward is: Let S\_total,t be the sum of composite scores across all eligible LCOs: $$ S\_{total,t} = \sum\_{j=1}^{L\_t} S\_{LCO,j,t} $$ Then LCO $i$’s share of the PP pool is: $$ P\_{LCO,i,t} = PP\_t \cdot \frac{S\_{LCO,i,t}}{S\_{total,t}} $$ *** ### Total Reward Per Epoch **Year 1 (UBI only):** $$ Reward\_{LCO,i,t} = \frac{R\_t}{L\_t} $$ **Year 2+ (UBI + PP):** $$ Reward\_{LCO,i,t} = \frac{UBI\_t}{L\_t} + P\_{LCO,i,t} $$ Where: * frac\_UBI\_t,L\_t is the baseline shared equally * P\_LCO,i,t is the performance-weighted component This ensures LCO contributions are rewarded both for participation and measurable impact. *** ### Settlement Mechanics * Reward calculations are performed off-chain in each epoch * Results are submitted on-chain as a single epoch settlement transaction * Final rewards are minted or released in DBT at the start of the next epoch * Each settlement logs per-operator allocations for transparency and auditing *** ### Example (Year 2+) Suppose: * Epoch reward allocated to LCOs: R\_t = 100,000 DBT * UBI weight alpha = 0.40 * PP weight beta = 0.60 * Total eligible LCOs: L\_t = 100 UBI component: $$ UBI\_t = 0.40 \times 100{,}000 = 40{,}000 $$ Baseline per LCO: $$ \frac{40{,}000}{100} = 400 \text{ DBT} $$ Assume normalized composite score for LCO i is 0.015 and total network score is 1.000: PP portion: $$ P\_{LCO,i,t} = 60{,}000 \times \frac{0.015}{1.000} = 900 \text{ DBT} $$ Total reward: $$ Reward\_{LCO,i,t} = 400 + 900 = 1{,}300 \text{ DBT} $$ *** ### Governance Controls Governance parameters that may be tuned include: * UBI vs PP split \alpha, \beta * Coverage vs throughput weight w\_{cov}, w\_{data} * Epoch timing * Normalization ceilings These parameters enable protocol evolution while maintaining a transparent and measurable reward structure. ### Compliance Notes * Only active and verified LCOs are eligible for rewards * Data feeds for coverage and throughput must be validated * Failure to meet compliance thresholds results in exclusion from that epoch’s settlement # Location owner Stakeholder who provides physical location access Location Owners help grow the Dabba Network by providing physical spaces where hotspots can be installed. This could include: * Shops * Rooftops * Apartment buildings * Commercial spaces * Public venues By hosting Dabba infrastructure, Location Owners help expand coverage and enable internet access in new areas. ### How Location Owners Earn Location Owners earn DBT every reward epoch (for example, monthly) if: * At least one active hotspot is deployed at their location * The hotspot is online and compliant * The location passes protocol verification checks Rewards are distributed in two phases. ### Year 1: Equal Rewards (Bootstrap Phase) During the first year of the network: * 100% of rewards are distributed equally * Every eligible location earns the same amount * Usage does not affect rewards This phase is designed to encourage rapid network expansion and onboarding of new locations. If your location is active and compliant, you earn. ### Year 2 and Beyond: Performance-Based Rewards Starting in Year 2, rewards shift to a hybrid model: 1. A baseline reward (equal for all eligible locations) 2. A performance reward (based on usage and contribution) Your total reward depends on: * The coverage your location enables * The amount of internet traffic passing through your location’s hotspots Locations that support higher traffic and stronger coverage earn more. ### What Impacts Your Earnings Your earnings increase when: * Your hotspot remains online consistently * More users connect through your location * Your site improves network reach * Uptime and service quality remain high Your earnings decrease if: * Your hotspot goes offline * Performance data is not reported correctly * The location fails compliance checks ### Important Notes * Rewards are distributed in DBT. * Calculations are performed every epoch and settled on-chain. * Inactive or non-compliant locations earn nothing for that epoch. ### Why This Structure Exists Year 1 focuses on expanding coverage quickly. Year 2 onward rewards real usage and network value. This ensures the network grows first, then optimizes for efficiency and adoption. By hosting a hotspot, Location Owners directly participate in building decentralized broadband infrastructure and earn DBT as the network grows. # Backhaul provider #### Backhaul Provider — Reward Specification Backhaul Providers supply upstream internet bandwidth to the Dabba Network.\ They enable hotspots to connect to the broader internet and support end-user data consumption. Backhaul Providers earn DBT in exchange for providing reliable, high-throughput upstream connectivity. ### Role in the Network A Backhaul Provider: * Supplies upstream bandwidth to one or more hotspots * Maintains uptime and service quality * Supports traffic growth as broadband adoption increases * Ensures stable latency and throughput Without backhaul connectivity, hotspots cannot serve users. ### Eligibility Requirements To qualify for rewards in epoch t, a Backhaul Provider must: * Be registered and verified on-chain * Provide active upstream connectivity during the epoch * Meet minimum uptime and performance thresholds * Submit validated bandwidth usage data * Pass compliance checks Providers failing validation for an epoch receive no rewards for that epoch. Total Reward Per Epoch #### Year 1: $$ Reward\_{BH,i,t} = \frac{R\_t}{B\_t} $$ #### Year 2+: $$ Reward\_{BH,i,t} = \frac{UBI\_t}{B\_t} + P\_{BH,i,t} $$ ### Settlement Process * Performance metrics are calculated off-chain each epoch * Eligibility and scoring are validated * Results are submitted on-chain * DBT rewards are distributed at the start of the next epoch All settlements emit logs for transparency and auditability. ### What Increases Earnings? Backhaul Providers earn more when: * Traffic volume increases * Network adoption grows * Reliability remains high * Latency remains stable * Uptime approaches 100% As broadband usage grows, performance-based rewards increase proportionally. ### Why This Design? Year 1 prioritizes onboarding and infrastructure availability. Year 2 onward prioritizes real bandwidth contribution and reliability. This ensures that: * Early participation is incentivized * Long-term rewards align with measurable network value # Hardware manufacturer Hotspots that power the network Hardware Manufacturers help power the Dabba Network by building and supplying approved network devices. This includes: * Hotspot devices * Network access hardware * Approved infrastructure components By producing reliable and compliant hardware, manufacturers help expand the network’s physical footprint and support broadband adoption. ### How Hardware Manufacturers Earn Hardware Manufacturers earn DBT based on: * The number of compliant devices deployed in the network * The operational quality of those devices * The reliability and uptime of hardware in the field Rewards are distributed in two phases. ### Year 1: Equal Rewards (Bootstrap Phase) During the first year: * 100% of rewards are distributed equally * All eligible hardware manufacturers earn the same amount * Device performance does not affect rewards This phase encourages early participation and rapid hardware supply growth. If your devices are compliant and actively deployed, you earn. ### Year 2 and Beyond: Performance-Based Rewards Starting in Year 2, rewards follow a hybrid model: 1. A baseline reward shared equally among eligible manufacturers 2. A performance-based reward tied to real network contribution Your earnings increase when: * More of your devices are deployed * Your devices remain online consistently * Hardware quality is high * Error rates are low * Firmware is up-to-date and compliant Manufacturers with higher-quality and more widely deployed devices earn more DBT. ### What Impacts Your Earnings? Your rewards grow when: * Deployment volume increases * Devices maintain high uptime * Hardware meets protocol standards * Performance metrics remain strong Rewards decrease if: * Devices are offline * Hardware fails compliance checks * Telemetry reporting is incomplete * Quality thresholds are not met Inactive or non-compliant devices do not earn rewards. ### Summary Build compliant hardware.\ Deploy devices into the network.\ Keep them reliable and online. As adoption grows, manufacturers who enable scalable and high-quality infrastructure earn more DBT. # Staking We’re at \~125k connections live and adding more every day. As the network grows, each hotspot owner's reward gets diluted. To give owners exposure to network growth, we’re introducing a staking mechanism that turns idle unclaimed owner‑share into sustainable staking rewards. #### How it works * Collect idle owner‑share from unclaimed hotspots (the 60% that would normally go to an owner) * Route 30% as staking incentive (remaining 70% funds community growth). * Distribute pool rewards pro‑rata to stakers , bigger stake = bigger rewards. With zero net new emissions, this creates sustainable rewards that flow back to long‑term supporters. *** ### Staking Reward Flow Diagram This diagram explains how DBT flows from hotspot emissions into staking rewards. ``` +----------------------+ | Active Hotspots | +----------+-----------+ | v +----------------------------------------+ | DBT emitted per hotspot per day (E_t) | +-------------+--------------------------+ | +-----------+------------+ | | v v +--------------------------+ +------------------------------+ |Claimed & Active Hotspots | | Unclaimed & Active Hotspots | | | | | | Rewards distributed | | Owner Share (60%) | | as per UBI model | | Redirected to Incentive Pool | +--------------------------+ +-----------+------------------+ | v +------------------------+ | Network Incentive | +-----------+------------+ | +-------------------------+----------------------+ | | v v +----------------------+ +---------------------+ | Staking Incentives | | Growth Incentives | | (30%) | | (70%) | +-----------+----------+ +----------+----------+ | | v v +------------------------+ +----------------------+ | Reward DBT staking | | Hotspot Sales | | (weight based) | | Marketing | +------------------------+ | Hackathons | | Network expansion | +----------------------+ ``` **Staking rewards are funded by network expansion rather than arbitrary token inflation.** *** ## APY Simulation Model Because staking rewards depend on both network state and staking demand, APY must be modeled dynamically. The effective APY can be estimated using the following framework. *** {% stepper %} {% step %} ### Step 1: Calculate Daily Staking Reward Pool Let: * `U_t` = active but unclaimed hotspots * `E_t` = DBT emitted per hotspot per day Owner share parameters: ``` owner_share (of unclaimed hotspot)= 60% staking incentive = 30% of owner_share ``` Daily staking pool: ``` StakePool_t = U_t * E_t * 0.60 * 0.30 ``` {% endstep %} {% step %} ### Step 2: Calculate Total Weighted Stake Let: * `T` = total DBT tokens staked * `W` = weighted stake after applying lock multipliers
Lock DurationMultiplier
6 Months1.5x
12 Months2.2x
Example distribution: ``` 6 Month stake = 40M DBT 12 Month stake = 60M DBT ``` Weighted stake: ``` 40M * 1.5 = 60M 40M * 2.2 = 88M Total weighted stake = 148M ``` {% endstep %} {% step %} ### Step 3: Daily Reward Per Weight Unit ``` RewardPerWeight = StakePool_t / WeightedStake ``` {% endstep %} {% step %} ### Step 4: Calculate Individual Rewards Example user staking: ``` Amount = 10,000 DBT Lock Duration = 12 months Multiplier = 2.2x User weight+ = 10,000 * 2.2 = 22,000 DBT ``` Daily reward: ``` user_daily_reward = weight * RewardPerWeight ``` {% endstep %} {% step %} ### Step 5: Convert to Annualized APY Approximate APY: ``` APY ≈ (DailyReward / StakedAmount) * 365 ``` {% endstep %} {% endstepper %} *** ## Example Scenario Assume: ``` Sold & Active hotspots = 25,000 Unclaimed & Active hotspots = 100,000 ``` Daily emissions for unclaimed locations: ``` Daily Mainnet Rewards = 1,643,835 DBT Daily H.O Rewards = 60% x Daily Mainnet Rewards = 986,301 DBT Daily H.O Rewards per hotspot = 7.890408 DBT/hotspot Daily H.O Rewards from Unclaimed Locations = 100,000 x 7.890408 = 789040.8 DBT ``` Staking Incentives: ``` Staking Incentive Pool = 30% of Daily H.O Rewards from Unclaimed Locations = 0.3 x 789040.8 = 236,712.24 DBT/day ``` If total weighted stake: 148M ``` reward_per_weight = 236,712.24 / 148,000,000 = 0.0015994 DBT ``` Calculating APY for a user: ``` If user has staked 10,000 DBT at 12 month lock User weight: 10,000 × 2.2 = 22,000 Daily Reward = 22,000 * 0.0015994 = 35.1868 DBT/day Annualized = 34.716 x 365 = 12843.182 DBT Effective APY ~ 128.4% ``` *** ## Sensitivity Analysis (What Moves APY) APY increases when: * more hotspots are deployed but not yet claimed * fewer DBT tokens are staked * longer lock durations dominate APY decreases when: * more DBT tokens enter staking * hotspot inventory gets sold to owners * emission schedule declines *** ## Growth Phase vs Mature Network This design naturally produces two phases. ### Early Network Phase * large unclaimed hotspot inventory * high staking rewards * strong bootstrap incentives ### Mature Network Phase * most hotspots claimed * smaller incentive pool * staking yield decreases This mirrors the natural growth cycle of infrastructure networks. # DBT Utility DBT is the coordination asset of the Dabba Network.\ It integrates infrastructure incentives, revenue conversion, capital formation, governance, and platform settlement into a single economic framework. Its utility is multi-layered and anchored to real broadband adoption. ### 1. Infrastructure Incentive Layer DBT is the primary reward asset for all network participants, including: * Hotspot Owners * Local Cable Operators * Backhaul Providers * Location Owners * Hardware Manufacturers Rewards are distributed per epoch and evolve from a bootstrap UBI model to a performance-weighted structure. **Utility Outcome:**\ DBT incentivizes physical infrastructure deployment and ongoing network performance. ### 2. Revenue-Linked Demand & Burn Layer A defined portion of broadband revenue is used to purchase and burn DBT. Supply evolves as: $$ S\_{t+1} = S\_t + E\_{t+1} - Burn\_{t+1} $$ When: $$ Burn\_t > E\_t $$ the network becomes net deflationary. **Utility Outcome:**\ Real-world broadband revenue is converted into token demand and structural supply tightening. ### 3. Capital Formation Layer (Bandwidth Staking) DBT enables infrastructure-linked staking. Each deployed hotspot unlocks: $$ 4 \text{ USD worth of staking capacity} $$ Staking: * Locks circulating supply * Provides dynamic yield * Scales proportionally with infrastructure growth **Utility Outcome:**\ DBT coordinates capital formation for bandwidth expansion while reducing liquid supply. ### 4. Governance Layer DBT holders participate in protocol governance, including adjustments to: * Reward weights * Staking parameters * Emission decay * Treasury usage * Burn mechanisms **Utility Outcome:**\ Token ownership confers economic policy influence. ### 5. Platform Settlement & Service Utility Layer DBT functions as the transactional asset of the Dabba ecosystem. It may be used for: * Premium feature access * Advertising settlement * **Dabba hardware purchases** * Software subscriptions * Developer fees * Platform service fees * Transaction fees * Ownership transfer fees As platform activity increases: $$ Burn\_t \propto Usage\_t $$ Higher usage increases token velocity and burn rates. **Utility Outcome:**\ Ecosystem growth compounds token demand across multiple service layers. ### Structural Design Principle DBT utility operates across three reinforcing loops: 1. Infrastructure Growth → Token Rewards 2. Revenue Growth → Buyback & Burn 3. Platform Expansion → Transactional Usage & Burn This creates a coordinated system where: * Physical network growth drives issuance * Revenue growth drives deflationary pressure * Platform growth drives transactional demand ### Economic Positioning DBT is not designed as a passive speculative asset. It functions as: * An infrastructure incentive token * A revenue-conversion asset * A staking coordination mechanism * A governance instrument * A platform settlement currency Its long-term value proposition is structurally tied to broadband deployment, user adoption, and ecosystem activity. ### Summary DBT integrates: * Real-world infrastructure * Real revenue * Real platform usage into a unified, supply-disciplined token economy. As adoption increases, utility compounds across incentive, burn, staking, governance, and settlement layers — creating a demand-anchored economic system. # Onchain data :warning:TESTNET Playground:
The onchain representation of the Dabba network is represented by the following primitives:\ \ **NFTs**\ We use NFT's to represent the Hotspot device, Hotspot owner and LCO partner. Compressed NFTs are used for efficiency as well as cost. **Merkle trees**\ Bandwidth and Payments data are stored on chain using merkle trees for cost and efficiency. Raw data is available on IPFS/Arweave. PDAs\ PDAs are used in conjunction with NFTs to store additional attributes and metadata Registries\ Registries are used for lookup style data like city, state, etc. Contracts\ Mint, stake and reward contracts will contain logic of token creation and interaction. # NFTs Core NFTs on the Dabba network ## :warning: TESTNET ## Hotspot Device NFT Playground - The Hotspot Device NFT represents a physical wifi router currently deployed in a customer premise IRL. The cNFT standard implementation - \ \ \ NFT Example | Attribute | Type | | ------------- | ---------------------------------------------------------------------------------------- | | Solscan link | | | Explorer link | | | PDA address | | ## Hotspot Owner NFT TBA
## LCO Partner NFT Playground - The LCO partner NFT represents the Local cable operator whose responsibility is to install, maintain and service wifi hotspots IRL. The cNFT standard implementation - The NFT and it's PDA will contain real world verifiable metadata on the LCO such as:\ 1\. LCO company registered name\ 2\. Lat/Long location of LCO headquarters\ 3\. Official Indian Goods & Services Tax number\ 4\. Current size of network\ 5\. Owner wallet address\ 6\. Hotspot Device NFT link | Attribute | Type | | ------------- | ---------------------------------------------------------------------------------------- | | Solscan link | | | Owner address | | # Subscriber revenue How Dabba network reports revenue onchain In an effort to balance cost against transparency, we have chosen to use Merkle trees as the method of representation of subscriber revenue. This provides us the ability to store subscriber payments per hotspot on a an epoch (24 hour) basis. Playground: Sample Hotspot Device NFT: \ J1pJnQiijQacgbMfRzV5wHpbrcNc5djRLVyZXKKHPJuu # Bandwidth How Dabba network bandwidth data is stored on chain In an effort to balance cost against transparency, we have chosen to use Merkle trees as the method of representation of network data consumption. This provides us the ability to store data consumption per hotspot on a an epoch (24 hour) basis. Playground: Sample Hotspot Device NFT: \ J1pJnQiijQacgbMfRzV5wHpbrcNc5djRLVyZXKKHPJuu # Network use cases **Low cost wifi in India** The Indian telecom market is the second largest in the world. It is growing rapidly and has much headroom for the next few decades. The steady rising demand for data consumption deserves its own equivalent of Moore's law. There is room to serve **hundreds of millions** of unconnected Indians with high speed low cost internet access. **Low cost wifi in other developing nations** If a low cost network can be setup and operated in India, that model can scale to the billions of other potential customers in underserved developing nations. **5G network neutral offload host** The Dabba network can service as a neutral offload host for existing telecom providers. **5G private networks** The Dabba network is capable of serving as a private 5G network for industrial facilities and remote locations. **Multi-token mining** Instead of the current DePin approach wherein single use hardware devices are deployed, the Dabba network makes a concerted effort to make sure the hardware deployed on the network is capable of mining multiple tokens at the same time thereby increasing the ROI of deployment. **Dabba developer network** The unique hardware capabilities of the Dabba Network allow for the creation of an entirely new class of applications that leverage public wifi networks. **Decentralized app store** New applications developed for the Dabba Network will require a new type of decentralized app store owned and operated by the community. # Community Townhall Dabba Network Townhalls are recurring community sessions where the core team walks through the latest updates across the network. Each townhall is designed to give the community a transparent look at what is being built, what decisions are being made, and what comes next for the network. The goal is simple: **Build in Public** and keep the community closely involved as the network evolves. Every townhall is documented here so anyone can revisit the discussions, understand the reasoning behind major decisions, and follow the evolution of the network over time. Whether you're a hotspot owner, community member, developer, or investor, these recaps provide a clear view of how Dabba Network is being built step by step. ### Townhall index {% hint style="info" icon="landmark" %} [**Townhall #19**](/community-townhall/townhall-19)**:** Jan 9, 2026 ; Q1 roadmap leading up to TGE , bringing the network onchain {% endhint %} {% hint style="info" icon="landmark" %} [**Townhall #20**](/community-townhall/townhall-20)**:** Jan 16, 2026; Bringing the network onchain part 2 {% endhint %} {% hint style="info" icon="landmark" %} [**Townhall #21**](/community-townhall/townhall-21)**:** Feb 11, 2026 ; Update to tokenomics pillars to align with the Dabba Telco Vision {% endhint %} {% hint style="info" icon="landmark" %} [**Townhall #22**](/community-townhall/townhall-22)**:** Feb 20, 2026 ; Full onchain architecture, token and security framework {% endhint %} {% hint style="info" icon="landmark" %} [**Townhall #23**](/community-townhall/townhall-22)**:** Mar 9, 2026 ; Revised Tokenomics and launch Pathways {% endhint %} # Townhall #19 Date: 9 January 2026 Focus: Q1 roadmap leading up to TGE {% embed url="" %} Townhall #19 set the 2026 plan to move every meaningful network metric on-chain before TGE. *** ### 2025 Recap * Hotspots deployed: 3,000 → 75,000 over 2025; targeting 1M by 2026 * Daily active users: grew proportionately with each connection, increasing network revenue to 500k+ over 30 day billing cycles * Community growth within and beyond traditional DePIN circles, with partners across web3 sectors and IRL events across Breakpoint, Token 2049, Solana Summit, and more ### Moving the Network Onchain As we plan the revised TGE, we are pushing the network on-chain with community feedback. This makes key metrics transparent and verifiable. A demo of the Hotspot Device NFT on devnet was presented. * Each location on ground will be represented on-chain with an NFT * Compressed NFT standard to reduce costs for millions of connections * Each NFT will link to key metrics like: * Broadband consumption per epoch, verifiable on-chain * Registry data connecting all stakeholders keeping connections live * WD number for unique hardware identification and replacement/repair tracking * Customer invoice details showcasing payment plans ### What’s coming next * Series of on-chain updates planned across January and February * Full rollout of the NFT architecture * Transition from data-consumption to revenue-based model for burn and hotspot owner rewards * Developer ecosystem development now that data is on-chain * Revised TGE rollout plan targeting end of Q1 * Hotspot sales closed till tokenomics are revised, with new Genesis rewards structure for future purchase Explore the devnet Hotspot Device NFTs today. Stay tuned for upcoming townhalls as we shape revised tokenomics based on network growth since inception. *** ### Closing Notes & Takeaway The north star for 2026 is growth. It’s crucial that all data can be transparently showcased and verified by the community. The network has grown rapidly since our initial whitepaper. Together we will shape revised tokenomics to reflect sustainable growth aligned with projected expansion. # Townhall #20 Date: January 16, 2026 Focus: Bringing the network on-chain, growth & upcoming milestones {% embed url="" %} Townhall #20 covered key developments in bringing Dabba’s operational data fully on-chain. It also covered improvements to visibility and tooling, growth impact for LCOs, and upcoming milestones. *** ### Onchain Data & Transparency Goal Publish full network data on-chain. Make it verifiable and queryable by anyone. Iteration 2 of the Open Network Data Layer launched. Initial rollout of on-chain data included: * Hotspot Device NFTs * Compressed NFTs used * Bandwidth tracked per epoch (24-hour period) using Merkle trees * WD number to identify unique hardware * Invoice of customer payments * Each device stores references to all five stakeholders that keep the connection live * LCO Partner NFTs * Compressed NFTs used * Stored fields include company name, GST registration identifier, coordinates, network size, wallet info, and links to connections * Compressed data via Merkle trees and PDAs for efficiency * Network data will be live on Solana testnet, followed by mainnet deployment ### Onchain Playground A new GitBook section captures network data on Solana testnet. It lets the community explore and verify data directly. UI and visualisation improvements are coming. A glossary will clarify technical terms. *** ### Closing Notes and Takeaway * Transparency first: core network data is being brought fully on-chain for independent verification * Structured execution: updates are rolling out in phases to keep on-chain data and tokenomics clear * Real-world impact: success is measured by outcomes for LCOs (subscriber growth, revenue, sustainability) Explore the MVP playground to understand the network with numbers. This will help refine tokenomics together over the upcoming townhalls. # Townhall #21 Date: February 11, 2026 Focus: Dabba telco vision (1M hotspots), tokenomics evolution & road to TGE {% embed url="" %} Townhall #21 covered Dabba’s transition to a full-fledged telco. The target is 1 million hotspots in the next 12 months. It also covered network growth metrics, on-chain progress, and tokenomics refinements ahead of TGE. *** ### Network Growth Network fundamentals continue growing independently of market conditions. * 12 months ago: \~2,000 deployments, \~10,000 daily active users, \~$12K monthly revenue * Today: 100,000+ hotspots deployed, rapid growth in DAUs and recurring revenue * Strong LCO onboarding pipeline (200+ partners queued) * Over the coming 12 months: push toward 1 million connections and top-10 ISP category in India ### Onchain Update * All operational data reflected on-chain * Messari dashboard launched for third-party validation: * Current revenue reflects lump-sum payments (3/6/12-month plans) counted upfront * Next update will spread payments across the subscription period for accurate monthly breakdowns ### Tokenomics Evolution * Shift from a data-credit model to a revenue-based burn framework and mainnet rewards * Revise Day 1 unlock for all stakeholders * Discuss details over upcoming tokenomics-focused townhalls * Rewards generated by unclaimed locations held in an independent wallet managed by the Foundation * Tokens used for community and network growth initiatives * May include hotspot purchase incentives * May include staking rewards for existing holders *** ### Closing Notes and Takeaway 2026 is a build year. Scale and execution matter more than hype. Growth is the north star. Tokenomics will evolve to support long-term infrastructure scale. Community feedback will shape the final structure. A proposal is expected over Townhall 23. # Townhall #22 Date: February 20, 2026 Focus: Full onchain architecture, token infrastructure & security framework ahead of TGE {% embed url="" %} Townhall #22 covered all on-chain updates. It focused on NFT architecture that represents every stakeholder. It also covered token mint, staking, registry, and security frameworks. Everything is designed to be publicly verifiable on-chain. *** ### The 5 Solana Programs Dabba’s on-chain structure consists of: * Identity NFT programs (all stakeholders) * Bandwidth program (daily Merkle tree storage) * Token mint contract (DBT creation + emission controls) * Staking program (lock logic + reward tracking) * Wallet registry program (global on-chain index of stakeholders) Together, these allow public verification of: * Network activity * Token supply and emissions * Stake positions * Stakeholder legitimacy ### Onchain Onboarding Update Every hotspot owner will need to complete onboarding on-chain. The flow: * Mint Hotspot Owner NFT in your wallet * Bind to Hotspot Device NFT which represents a live connection on ground * Claim rewards generated from every claimed location * Swap to a different location in case of subscriber churn ### Token Mint & Emission * Pre-mint placeholder: 4B DBT (final numbers pending) * Mint authority revoked after 10B hard cap is emitted * Admin roles (Admin, Config, Daily Minter, Burn) protected by multisig + circuit breakers * Security audit in progress; report will be published before TGE *** ### Closing Notes & Takeaway This architecture provides the infrastructure backbone for a transparent, scalable, telecom-grade DePIN. On-chain updates are wrapped. Next townhalls move into tokenomics-focused discussion. # Townhall #23 Date: March 9th, 2026\ Focus: Tokenomics Framework, TGE Launch Paths & GTM Strategy. {% embed url="" %} TownHall #23 was the first full tokenomics-focused deep dive. Team presented 3 token launch paths each with its own trade-off for community feedback towards an aligned launch. *** ## Market Reality Check The team spent significant time explaining why the launch strategy needed to be reconsidered. #### Core observations shared: * The broader DePIN sector has not produced enough clear market winners recently to inspire strong retail enthusiasm * Trading volume appears to be driven more by volatility-seeking traders than by long-term believers in infrastructure projects * Market conditions today are very different from the earlier phase when the “launch big everywhere immediately” strategy looked more attractive **Takeaway:** While the market will eventually reward strong fundamentals, but this cycle may require more patience, better execution, and a more adaptive launch structure than earlier DePIN projects pursue *** ### Network Growth & Fundamentals * 120,000+ hotspots deployed * Largest DeWi by actual data transferred * Strong Fiat Revenue placing the project in top 5 of DePIN leaderbaord * Projected \~20% month-on-month growth this year **Takeaway:** The thesis with which we began has been successful on ground and scaled faster than initially positioned, with half a million D.A.U generating revenue from every connection *** ### 3 Paths to TGE The team presented 3 launch stratergies with evaluations based off market and network conditions. * **A**: Aggressive Day-1 visibility with major CEXs (high cost, high volatility). * **B**: DEX-first + gradual smaller ("long-tail") CEX listings (recommended for stability + sustainable momentum). * **C**: Pure DEX-only organic growth (maximum runway preservation, slower start). The goal: Choose the path that best aligns with Dabba's mission; team identified Option B strikes the ideal balance. | Decision Factor | Option A: Day-1 DEX + Tier 1/2 CEX | Option B: DEX + Gradual CEX Ladder (Recommended) | Option C: DEX-Only Organic Growth | | -------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------- | | Visibility & Attention | Highest (strong trader hype from major exchanges) | Medium (builds organically + phased listings) | Lowest (community-driven only) | | Capital / Runway Efficiency | Low (halves effective runway due to high costs) | High (preserves most capital for network build-out) | Maximum (zero concessions to exchanges) | | Token Supply Given Up | High (3–8% across exchanges + large deposits) | Low–Modest (phased, 1.5-3%) | Zero | | Lockup/Cliff Impact on Genesis/Presale | Severe (additional 6-month cliffs common) | Minimal (avoids heavy restrictions on existing holders) | None | | Initial Volume & Liquidity | Highest (but often dominated by volatility traders) | Balanced & more sustainable (organic price discovery) | Lowest (depends fully on DEX + community) | | Day-1 Volatility Risk | Highest | Low (gradual exposure) | Lowest | | Alignment with Current Market & DePIN | Misaligned (expensive/restrictive in soft conditions) | Best fit (capital-efficient, supports long-term growth) | Most protective but slower momentum | | Long-Term Network Growth Fit | Restrictive (diverts resources early) | Strongest balance for real adoption & incentives | Pure organic (full control, but higher risk of slow start) | | Day 1 Circulating Supply | \~8% | \~3.5% | \~1.5% | Percentages are approximately based on exchange discussions; final figures subject to negotiations and market conditions. Option B recommended to minimize dilution while building sustainable momentum via DEX + long-tail CEX approach. *** ### Token Supply & Distribution #### Total supply structure * Max supply: 10B DBT * Preminted / locked initially: 4.84B * Epoch emissions over time: 5.16B #### Stakeholder allocations (this changes slightly based off path to TGE) * Seed investors: 8.46% * Private presale: 2.95% * Exchanges: 7.3% under the full tier-one scenario * Foundation: 6%(If Option B is pursued, unused exchange allocation roll into Foundation-controlled growth resources) * Team: 15% * Community Genesis pool: 8.4% * Emission rewards: 51.6% *** ### Revenue Flow & Buyback Structure A major section of TownHall #23 focused on how fiat revenue actually moves through the protocol. This foundational understanding is key to grasp the shift from a DC burn mechanism to a cleaner revenue based burn that scales with the network sustainably **Per $1 of revenue:** * 45% goes toward acquiring LCO tokens → then burned * 30% goes toward acquiring bandwidth provider tokens → then burned * 5% goes to hotspot-owner liquidity support * 20% goes to Dabba Inc for operations **This ties in the core utility of the token to:** * Buying bandwidth on the network * Supporting hotspot related participation and expansion * Eventually powering service access and broader developer integrations Token is tied to real network demand and real bandwidth purchases (aka Revenue over Data use), with value accruing as the network grows. *** ### Mainnet Rewards Current network metrics * \~125,000 hotspots deployed * \~25,000 sold * Roughly 1.6M tokens emitted daily for active hotspots Based on the numbers above, daily emission of \~320K daily rewards is distributed to claimed hotspots by the community, while the rest goes to unclaimed. This sets up an unique condition we plan to solve using a growth incentive pool. From the unclaimed pool of tokens, this will be redistributed to the community along 2 paths * 70% for future hotspot buyer incentives / post-TGE growth campaigns * 30% for staking rewards ### Staking * Collect idle owner‑share from unclaimed hotspots (the 60% that would normally go to an owner) * Route 30% as staking incentive (remaining 70% funds community growth). * Distribute pool rewards pro‑rata to stakers , bigger stake = bigger rewards. With zero net new emissions, this creates sustainable rewards that flow back to long‑term supporters. *** ### GLP Update Based off current market conditions, a public token presale does not look like the best path to pursue at the moment which would effectively shelv the idea of a Genesis Liquidity Pool.\ With lower appetite for token sales across the market, the reduced liquidity will not allow meaningful GLP return for Hotspot Owners.\ Team is still pursuing the best solution to execute on this.\ \ Note: All vaultpass/lootbox particpation will be honored as expected, giving full allocation to all participants, *** ### Closing Notes & Takeaway 2026 may be a rough year for many projects, team is prepared for launching in what might be considered a bear market, with network growth as the north star.\ The idea is to launch in a way that protects the network’s future, not just its first week of trading.\ \ This townhall opens up for feedback from all community members over the coming week on their expectation, concern suggestions and more to finalize the direction to TGE. # Townhall #24 Date: March 9th, 2026\ Focus: Tokenomics Framework + TGE Launch Paths {% embed url="" %} TownHall #24 was a short, focused update covering our appoach to token launch and launching the dabba network mapping app. *** ### Network mapping app We are launching a new mobile app, this is meant for people across India to map the network around them.\ The aim is to give people who may not be in the web3 world a feeling of what it means to own the network, how steps taken by anyone can help influence and upgrade the internet they are using across any service provider. # Dabba Lite Low cost wifi router #### Introduction
The Dabba lite is designed to be a public wifi router that lowers the cost of data access by offering public wifi services as well as mining a limited set of tokens by running various crypto apps. It is a incrementally more powerful than a regular router so as to be a more efficient use of space and time. It is designed for indoor use and supports wifi 6. You can buy Dabba Lite here - Learn more about the purchase refund policy - | Spec | | | ---------------- | ------------------------------------------------- | | CPU | MediaTek MT7986(Filogic 830) Quad core ARM Cortex | | SDRAM | 2 GB DDR4 | | On board Storage | 8GB | | Wifi |

Wifi 6 4x4 2.4G

4x4 5G

| | Enclosure | Indoor metal clamshell |
# Dabba Foundation The Dabba Foundation stands as the backbone of governance within the decentralized marketplace, fostering trust, innovation, and sustainable growth within the Dabba network. As a governing body, it embodies the principles of decentralization, transparency, and community-driven decision-making. Its primary role revolves around overseeing the network's operations, setting standards, and ensuring fair participation and development across all stakeholders. Primarily, it oversees the development and evolution of the protocol that underpins the Dabba network, ensuring that the technology remains cutting-edge, secure, and efficient. This involves managing the lifecycle of Dabba Improvement Proposals (DIPs), where members of the community can suggest enhancements or modifications to the network's protocol. The foundation meticulously evaluates these proposals, fostering innovation while maintaining the integrity and coherence of the system. Additionally, the Dabba Foundation plays a crucial role in the formation and organization of the Dabba Decentralized Autonomous Organization (DAO). This involves orchestrating the governance structure, which is integral for a decentralized network, ensuring that decision-making processes are transparent, democratic, and aligned with the community's interests. Outreach and education are also key facets of the foundation's activities. It undertakes various initiatives to promote awareness about the Dabba network, educating the public and potential users about the network's capabilities, benefits, and the underlying technology. Moreover, the foundation aims to run a grants program targeted at developers working on the Dabba network. This program aims to incentivize innovation and development within the ecosystem by providing financial support to projects that have the potential to enhance the network's functionality or user experience. Through this, the Dabba Foundation not only supports existing developers but also attracts new talent to the ecosystem, fostering a vibrant and dynamic development community. As part of the mainnet launch, the Dabba Treasury will go live and will be overseen by the Dabba Foundation. The Treasury will be responsible for managing the Foundation’s DBT holdings, administering grants, maintaining the ledger, and overseeing fee revenues. # Wifi Dabba inc #### About the company Wifi Dabba Inc () is a pioneer in building and operating low cost public wifi networks in India. Founded in 2017, Dabba Inc has has deployed thousands of hotspots across India at retail, residential and commercial locations serving users with super fast, super cheap internet. Demand for data in India is roughly doubling every 18 months and Wifi Dabba is building a new data only network for a data hungry generation. The Bengaluru-based team consists of full-stack software engineers, multiple PhDs in hardware engineering, several MBAs, and other important support staff. Learn more at[ dabba.com](https://dabba.com/about) # Disclaimer Neither Wifi Dabba Inc (the ‘”Company”) nor any of its affiliates (together with the Company, the “Group”) makes any warranty whatsoever (express or implied) with respect to the Dabba network, any Dabba hardware devices, or any Dabba Token, including, without limitation, any: (i) warranty that any Dabba Token will be issued, (ii) warranty of merchantability; (iii) warranty of fitness for a particular purpose; (iv) warranty of title; or (v) warranty against infringement of intellectual property rights of a third party, whether arising by operation of law, course of dealing, course of performance, usage of trade, or otherwise except as expressly set forth in writing between the Company and any recipient of Dabba Token, it is a condition of you receiving and retaining this White Paper that you warrant to the Group, its managers, directors, affiliates and its officers that you have not relied upon any warranty made by the Group, or any party within the Group, or any other person on the Group’s behalf. The information in this White Paper is subject to change or update and should not be construed as a commitment, promise or guarantee by the Company, the Group or any other individual or organization mentioned in this White Paper relating to the future availability of services related to the Dabba network or the use of DBT Token or their respective future performance or value. The Group expressly disclaims any and all responsibility for any loss or damage of any kind whatsoever, including but not limited to direct or consequential damages, arising directly or indirectly from reliance on any information contained in this White Paper, any error, omission or inaccuracy in any such information or any action resulting therefrom. **ANTI-MONEY LAUNDERING AND KNOW-YOUR-CUSTOMER REQUIREMENTS** Any recipients of Dabba Token may be required to comply with the Company’s anti-money laundering and know-your-customer requirements. **IMPORTANT INFORMATION: DISCLAIMERS AND CAUTIONARY NOTE REGARDING FORWARD-LOOKING STATEMENTS** This White Paper is being furnished solely for informational purposes. This White Paper does not constitute an offer to sell, or solicitation of an offer to buy, securities of any kind nor is it any way to be construed that Dabba Token may be deemed to be securities. This White Paper includes certain forward-looking statements and projections, which involve substantial risks and uncertainties. Forward-looking statements and projections may be identified by statements of a future date or the words “may,” “will,” “would,” “potential,” “expect,” “intend,” “ anticipate,” “believe,” “go-to-market,” “objective,” “seek,” “project” or similar expressions, words and phrases, including the negatives of these terms, or other variations of these terms, that denote future events. Forward-looking statements in this White Paper may include, without limitation, statements about the strategy, future operations, prospects and plans of the Company and the Dabba network, the size of the markets in which the Company or Dabba network operates or will operate, the potential future capabilities and scale of the Dabba network and its related technologies, monetization models, payments and rewards programs and Dabba network infrastructure. No representations or warranties are made by the Company or any of its affiliates or advisors as to the accuracy of any such statements or projections or with respect to any other materials contained herein. Whether or not any such forward-looking statements or projections are in fact achieved will depend upon future events and are subject to significant business, economic and competitive risks, many of which are not within the control of the Company and no assurances are being made with respect thereto. Such risks include, without limitation, (i) the risk that there are no guarantees that Dabba Token will have any value, retain any value, increase in value, or receive any distributions, nor does anyone guarantee the liquidity or market price of Dabba Token to any extent at any time; in fact, it is expected that Dabba Token will not have any cash value (ii) purchasers or recipients of Dabba Token may not be able to obtain all of the information they want regarding Dabba Token, the Dabba network or the Company, on a timely basis or at all; (iii) holders of Dabba Token will not have any voting rights in respect of the Dabba network or the Company; (iv) regulation of digital assets (including tokens) and offerings of digital assets are currently undeveloped and likely to rapidly evolve, and vary significantly among non-U.S. and U.S. federal, state and local jurisdictions and are subject to significant uncertainty and could have a material adverse effect on the Company and the Dabba network; (v) the Company, the Dabba network and third parties on which the Dabba network relies are operating in a regulated sphere, and as the Dabba network expands, additional regulatory approvals may be required. To the extent these are not able to be obtained, or any regulatory approvals that are obtained are then revoked or limited, this could impact the services provided by the Dabba network and have a material adverse effect on the Company and the Dabba network; (vi) the Company and the Dabba network are developing technology in a highly competitive industry; it is possible that competitive networks could be established or developed that attempt to implement services that are materially similar to or otherwise in competition with those offered by the Company and the Dabba network may be forced to compete with these competitive networks, which could adversely impact the Company and the Dabba network; (vii) any breach of data security that exposes or compromises the security of the Dabba network could have a material adverse effect on the Dabba; (viii) network outages or service or product failures that could lead end users to use competitors’ services and products; (ix) the ability of the Company to develop, test and validate its technology and the network infrastructure for the Dabba network; (x) investigations, claims, disputes, enforcement actions, litigation and/or other regulatory or legal proceedings; (xi) and the possibility that the Company may be adversely affected by other economic, business, and/or competitive factors. You are cautioned not to place undue reliance on forward-looking statements, which speak only as of the date the statement was made. Actual results may vary from the anticipated results and such variations may be material. The Company and its affiliates expressly disclaim any obligation to update or alter any forward-looking statements, whether as a result of new information or otherwise, except as required by laws. Statements contained herein describing documents and agreements are summaries only and such summaries are qualified in their entirety by reference to such documents and agreements. In addition, statements that “we believe” and similar statements reflect our beliefs and opinions on the relevant subject. These statements are based upon information available to us as of the date of this White Paper, and while we believe such information forms a reasonable basis for such statements, such information may be limited or incomplete, and our statements should not be read to indicate that we have conducted an exhaustive inquiry into, or review of, all potentially available relevant information. These statements are inherently uncertain, and you are cautioned not to unduly rely upon these statements.