bvndle. redemption mesh — KYL Solutions × VFD Group

KYL Solutions

The idea and the audacity

The world has a bias toward Azure, AWS, and cloud-first architecture. If you start thinking there, you will never get to a mesh. You just end up building a deeper dependency on cloud with a different logo — and none of it works in the markets Bvndle is trying to reach.

We don't build where the infrastructure is.
We build where the customers are.

KYL Solutions — Build Philosophy

Partnerships First

We don't disrupt; we enable. This proposal is built on co-building value with VFD Group from day one. The infrastructure VFD funds becomes an asset on their balance sheet. The IP we create together lives in a shared entity. Neither can be automated.

Offline is Not a Failure Mode

Every competitor treats offline as degraded service. We treat it as the default operating condition. The mesh works without internet. It works better with it. But it never depends on it.

One Protocol, Not Two Systems

Online transactions and offline transactions follow the same consensus protocol. The central server is a node in the mesh, not a separate system. This eliminates double-spend vectors by design, not by patch.

Security by Architecture

Hash-chained transaction logs. Per-customer spending caps. Local mesh consensus. Bounded risk at every layer. We don't trust the network — we verify through the mesh, even when the network exists.

User Journey

How Chioma spends her coin

Chioma is a market trader in Lagos. She has ₦5,000 in Bvndle loyalty points. She walks to a vendor stall in her local market. There is no internet. There doesn't need to be.

📱

Chioma checks her balance USSD

On her feature phone, Chioma dials *384*BVNDLE#. No data plan. No app. Just the keypad she already knows.

*384*BVNDLE#
Welcome, @chioma
Balance: ₦5,000
Tier: GOLD

1. View offers 2. Transaction history 3. Share VTag

🚶

She walks to the market No internet needed

Chioma arrives at Mama Nkechi's stall. The vendor's device detects her phone via Bluetooth. No pairing. No setup. Proximity is enough.

BLE SCAN → Device detected in range
VTAG RESOLVE → @chioma identified
PROFILE LOAD → Gold tier, ₦5,000 balance, segment: fashion + food
OFFER SCORE → Ranking 5 offers by relevance...

📺

The stall TV lights up IR blaster

The vendor's device fires an infrared signal to the TV above the stall. Chioma's personalised offer appears: MTN 1.5x data bonus. Her name is on the screen. It's her offer.

IR BLAST → Samsung TV power on (NEC: 0xE0E040BF)
IR BLAST → Switch to HDMI 2 (NEC: 0xE0E07D82)
MESH SERVER → Offer page served to all phones in range

Welcome, Chioma — MTN 1.5x Data Bonus
Spend ₦500 → Get ₦750 value

🔗

The mesh verifies Consensus One Protocol

Chioma says "yes." The vendor's device checks two paths simultaneously: it pings the central server over 3G to register the hash immediately, and broadcasts to local mesh peers for consensus. Whichever confirms first wins. If neither is available, bounded offline caps apply.

PATH 1: CENTRAL PING (3G)
POST hash to central → 200 OK → Confirmed in 340ms

PATH 2: MESH CONSENSUS (BLE)
Broadcast to peers → 3/3 vendors verify chain → Confirmed in 800ms

RESULT: Central confirmed first. Hash registered globally.
New hash: e9b1d4... → Balance: ₦4,500

✓

Chioma gets her data Complete

Done. Hash-chained, verified via the fastest available path, registered globally. Chioma walks away with ₦750 of MTN data from a ₦500 redemption. No cloud dependency. No latency anxiety. No waiting.

TRANSACTION COMMITTED
Customer: @chioma | Amount: ₦500 | Value: ₦750 (1.5x)
Merchant: MTN via Mama Nkechi's Stall
Verification: Central (340ms) + Mesh (800ms)
Hash chain: ...a3f7c2 → e9b1d4

The Hard Question

What stops Chioma from spending the same Naira twice?

If Chioma has ₦5,000 and redeems ₦2,000 at a vendor stall while simultaneously buying ₦4,000 airtime through the Bvndle app online, the system has approved ₦6,000 against a ₦5,000 balance. This is the attack. This is what the mesh is built to prevent.

Attack Scenario

Simultaneous online + mesh redemption

@chioma balance: ₦5,000

14:32:01 MESH Chioma redeems ₦2,000 at Mama Nkechi's stall
14:32:03 ONLINE Chioma buys ₦4,000 airtime via Bvndle app

Total attempted: ₦6,000
Available balance: ₦5,000
Discrepancy: ₦1,000 overspend

Without protection, this is a race condition. Two systems, two paths, one balance. The offline vendor doesn't know about the online transaction. The online system doesn't know about the offline one. Both approve. Both are valid at the moment they happen.

The Answer: One Protocol for Every Transaction

There are not two systems. There is one mesh protocol. The central server is a node in the mesh — the most connected node, but architecturally identical. Every transaction, whether initiated online or at a vendor stall, follows the same hash-chain consensus protocol.

Vendor Stall (Mesh)

Chioma → Vendor types @chioma → Vendor pings central via 3G → Central checks hash chain → If balance supports it, hash appended globally → Confirmation returned to vendor in under 500ms.

If no 3G: Local mesh consensus verifies via BLE peers. If no peers: bounded offline cap applies.

Online Purchase (App/USSD)

Chioma → Bvndle app or USSD → Central server receives request → Central follows the same mesh protocol: check hash chain, verify balance, append hash → Broadcast updated hash to all mesh nodes on next sync pulse.

Same chain. Same rules. Same protocol. Central is just another node.

Why the Attack Fails

Both transactions hit central — the race is resolved at the hash

14:32:01 — Vendor pings central with mesh redemption for ₦2,000. Central checks chain: hash valid, balance ₦5,000, approved. New hash written. Balance: ₦3,000
14:32:03 — Online app requests ₦4,000 airtime. Central checks chain: balance is now ₦3,000. ₦4,000 > ₦3,000. Rejected.
The hash chain is the single source of truth. The first transaction that registers its hash wins. The second sees the updated chain and either adjusts or rejects.
This works because the vendor has 3G — even a brief burst is enough to POST a hash. The customer doesn't need internet. The vendor needs a signal for however long it takes to land a hash on central.

Fallback: No 3G Available

Local mesh consensus + bounded offline caps

If the vendor cannot reach central, the transaction falls to local mesh consensus: nearby vendor nodes verify the hash chain via BLE
If no mesh peers are available, the vendor operates within a bounded offline cap — a fraction of the customer's balance (e.g., 20% or ₦1,000 max)
The cap is assigned per customer per node at last sync. Chioma cannot exceed her allowance at any single offline vendor
On reconnection, the queued transaction syncs to central. If the balance no longer supports it, the transaction is flagged for dispute resolution
Expected exposure from truly offline transactions: under 1% of transaction volume, mathematically bounded by the cap system

THE BOTTOM LINE

The primary path is: vendor has 3G, hash hits central, race resolved instantly. Zero risk.
The secondary path is: vendor has mesh peers, local consensus verifies. Near-zero risk.
The tertiary path is: vendor is completely isolated, offline caps bound the exposure.

Three layers. Each independently functional. The mesh doesn't need the cloud to work.
The cloud doesn't need the mesh to work. But together, they are mathematically airtight.

Architecture

Four layers, each independently functional

Each layer operates without the layers above it. Remove the internet and the mesh still works. Remove the mesh and the node still works. Offline is not a failure mode — it's the default.

Central Ledger Layer 4
Authoritative hash chain database. Customer management. Merchant dashboard. USSD gateway. Participates in mesh as a node. Always online
WAN Tunnel Layer 3
WireGuard-encrypted tunnels. Real-time hash registration over 3G. Periodic batch sync when 3G is unavailable. Relay servers in Lagos and Abuja. 3G / Periodic
Consensus Layer 2
Hash-chained VTag verification. Local mesh consensus via BLE prevents double-spending. Gossip protocol propagates chains between vendors. Local mesh
Vendor Node Layer 1
Standalone transaction engine. BLE detection. IR TV control. Offer scoring. Ad serving. Bounded offline caps when isolated. No connectivity

Consensus Protocol

How the mesh prevents double-spending

One protocol. Online or offline. The fastest path confirms.

1

Request

Vendor receives redemption request from customer

▶

2

Dual Path

Ping central (3G) + broadcast to mesh peers (BLE) simultaneously

▶

3

Verify

Hash chain checked against last known state at each path

▶

4

First Wins

Central or mesh — whichever confirms first commits the hash

▶

5

Propagate

Updated hash chain broadcast to all nodes. Global state consistent.

Delivery

8-Month Roadmap

From handshake to live pilot in a Nigerian market. Built by KYL Solutions with VFD Group's IT team and infrastructure.

Phase 1

Months 1–2

Stand up Headscale coordination server on VFD infrastructure
WireGuard tunnels between Android vendor nodes and central server
Central ledger database (Postgres) with hash-chain transaction log
Harden sync protocol: CRDTs for conflict-free merge, vector clocks for ordering
Define offline cap algorithm and per-customer allowance model

Phase 2

Months 3–4

BLE + WiFi Direct device discovery for market-radius mesh
Peer-to-peer transaction sync between vendor nodes (no internet required)
Gossip protocol for hash-chain propagation across vendors
Deploy relay servers in Lagos and Abuja
3G real-time hash registration path (dual-path verification)

Phase 3

Months 5–6

Full redemption engine on top of the mesh
USSD integration for customers (Africa's Talking or equivalent gateway)
Merchant onboarding flow and offer management dashboard
Ad server: branded offers to any device on the local mesh
Online transaction routing through mesh protocol (unified path)

Phase 4

Months 7–8

Double-spend attack testing across partitioned nodes
Load testing with VFD IT team simulating market conditions
Pilot deployment in one live market with real vendors
Monitoring, alerting, and operational runbooks
Handover documentation and training for VFD operations team

Commercial Structure

MeshCore — A Joint Venture

The mesh infrastructure is too valuable to sit inside either company alone. We propose a joint venture entity — MeshCore Infrastructure (Pty) Ltd — that holds the mesh IP, with both parties holding equity. KYL retains operational control and builds. VFD owns the infrastructure asset and the upside.

Partnership Terms

Hybrid Partnership

VFD acquires a minority equity stake in MeshCore. KYL builds. Both parties grow together.

KYL Solutions build fee (8 months)R3,000,000

Contingency reserve (transparent)R400,000

Total upfront (KYL)R3,400,000

Infrastructure hard costs (servers, relay nodes, USSD gateway, vendor hardware)VFD direct — as and when required (est. R400K–R800K)

Infrastructure ownershipVFD balance sheet

Mesh IP ownershipMeshCore (JV entity)

Transaction royalty (post-pilot)R0.15 – R0.25 per redemption

Commencement100% of upfront fee deposited into KYL Solutions account

RoyaltiesAccrued and dispersed quarterly

VFD IT team allocationDedicated resources — VFD's cost

Active Users	Redemptions/mo	@ R0.15	@ R0.25
1,000,000	2 per user	R300,000/mo	R500,000/mo
5,000,000	2 per user	R1,500,000/mo	R2,500,000/mo
20,000,000	2 per user	R6,000,000/mo	R10,000,000/mo

KYL only earns more if Bvndle grows. That is not accidental. That is the structure.

Deliverables

What VFD receives at month 8

Working Mesh Network

Vendor nodes connected across one Nigerian market. WireGuard tunnels to central. BLE local mesh. Relay servers in Lagos and Abuja. Infrastructure they own.

Offline-First Redemption

Zero-connectivity transactions with hash-chain verification. Dual-path confirmation (3G + mesh). Bounded offline caps. No internet dependency.

Unified Protocol

One consensus protocol for online and offline transactions. Central server participates as a mesh node. No double-spend vectors.

USSD Customer Access

Feature phone support via USSD gateway. No app required. 60M+ potential users on day one.

Ad Serving Mesh

Branded offers served to any device in range. HTTP server on every vendor node. Personalised by customer segment. Revenue from day one.

Live Market Pilot

Real vendors. Real customers. Real Naira. Operational runbooks, monitoring, and VFD team training. Proof, not promises.