Ubitel Compounding Subscription & Rewards

Ubitel Compounding Subscription

Ubitel redefines how internet service operates this system thrives on a virtuous cycle fueled by growth, community participation, and financial ingenuity. Here’s how it works:

Economies of Scale for Bandwidth Savings

As the Ubitel subscriber base grows, we unlock greater purchasing power on bandwidth costs leading to lower average price. This is the hallmark of economies of scale. Rather than pocketing these savings, we pass them directly to our subscribers. This means that every new user makes the service progressively more affordable for everyone else.

Subscription Yield

We amplify subscription value by transforming monthly subscription fees into an active DeFi primitive. Instead of passively holding subscriber payments, we deposit these funds into an interest-bearing stablecoin pool mechanism, where they generate yeild that is distributed back to subscribers.

Shared Prosperity Through Rewards

The earned yield isn’t retained by the company; it’s redistributed back to our subscribers as a reward for their participation. This creates a dual benefit: customers enjoy lower service costs as the subscriber base grows and receive financial rewards that grow alongside the fund’s performance.

Ubitel Subscription & TEEPOT Synergy

Ultimately since every Ubitel user implicitly will have a TEAPOT this creates a synergystic economics between the two services. On one hand subscribers pay the network for service, simultaneously they are rewarded for their passive secure compute participation in the network.

A Community-Driven Ecosystem This model is inherently participatory. Every subscriber contributes to a system that benefits the whole. Growth drives affordability, and collective resources drive financial rewards, creating an ecosystem where subscribers are both customers and stakeholders in the system’s success.

This approach is more than just an internet service; it’s a community-powered DeFi and technological innovation. By aligning economic incentives with customer satisfaction, we create a sustainable, scalable model that serves not only today’s needs but also future growth.

Ubitel Open Bandwidth Market Overview

Introduction

The Ubitel eSIM Market serves as a critical component of the broader Ubitel decentralized wireless network, acting as the user-facing entry point where consumers can purchase eSIM data packages using cryptocurrency or fiat. This system bridges traditional mobile data usage with blockchain-based payments, providing a seamless, user-friendly experience.

Objectives

The Ubitel eSIM Market aims to:

Simplify eSIM and data purchasing for global users.
Enable cryptocurrency-based transactions in tandem with fiat payments.
Promote adoption via referral incentives and airdropped rewards.
Serve as an on-ramp to Ubitel’s decentralized DeISP network.

Components

The eSIM Market consists of several interconnected components that work together to deliver its features:

Smart Contracts

UbitelESIMMarket Contract: Facilitates eSIM purchases by allowing users to purchase a receipt on-chain for an eSIM package with a group number and ID.
Points Token Contract (ERC-20): Tracks user points for pre-launch campaigns. Points will convert into spendable rewards (e.g., Data Credits) upon launch. The market contract is permissioned as a minter for this token.
UBI (ERC-20): The primary utility token for the Ubitel network, used for purchasing eSIMs, potentially at a discount. The market contract is permissioned as a vendor for this token.
Upgradeable Proxy Pattern: Ensures that contracts can be upgraded without disrupting the user experience.

eSIM Purchases

Users can purchase eSIM data packages via cryptocurrency or fiat payment:

On-chain: Users choose from supported cryptocurrencies (e.g., stablecoins or UBI).
Stripe: Allows fiat payments, with Stripe receipts saved for backend order processing.

Referral Rewards

Users can refer others to earn points tokens:

A configurable percentage of each referred user’s spending is credited to the referrer.
Referrers can redeem these points as part of the Data Credits pool post-launch.

Backend Infrastructure

The backend API supports the user-facing application by handling:

Inventory Management: Tracks and updates the catalog of available eSIM packages.
Database (MongoDB): Stores user purchases, receipts, and orders.
Quote Generation: Prices eSIM packages dynamically, including token-based and fiat pricing, with constant market updates.
User Authentication: Ensures secure access to user data and purchases through Privy-based verification.

Catalog

The eSIM Market manages a catalog of packages classified by:

Data size (e.g., 1GB, 5GB) or unlimited options.
Region-specific availability.

Each package is associated with a unique identifier and group number for tracking.

Quotes

An eSIM package purchase quote is structured as follows:

struct ESIMPackageQuote {
    address user;
    uint256 group;
    uint256 price;
    uint256 expiry;
    address token;
    uint256 points;
    bytes signature;
}

The signature is an ECDSA-signed packet containing:

bytes32 messageHash = keccak256(
    abi.encodePacked(quote.user, quote.group, quote.price, quote.expiry, quote.token, quote.points)
);

Frontend Application

The user interface, delivered as a web application, allows customers to:

Browse available eSIM packages.
Customize purchases by selecting tokens or fiat for payment.
Track referral rewards and pre-launch points.
Complete transactions with minimal clicks.
Includes a wizard to assist new users.

The primary focus is to reduce friction for first-time buyers.

Operational Flow

Purchase Process 1. User Browses Packages:

The frontend fetches the eSIM catalog from the backend.

Users select a package, choose a payment method, and proceed to checkout.

Quote Generation: - The backend provides a real-time quote for the selected package. - The frontend displays the price in the chosen token.
Transaction Execution: - The frontend initiates the transaction via the user’s wallet. - Smart contracts handle payment, inventory updates, and referrals.
Post-Purchase: - The eSIM package is registered to the user’s account. - Providers are notified of the new activation.

Referral Rewards

Referrers share their unique addresses.
New users input the referrer’s address when purchasing.
The smart contract credits referral points to the referrer’s account.

Challenges and Considerations

Real-Time Pricing - Dynamic token exchange rates require integration with pricing oracles and careful management of rate updates.

Scalability The system must support:

High transaction volumes during promotions.
A growing user base post-launch.

Security - Robust smart contracts to prevent exploits (e.g., reentrancy or overflow issues). - Secure storage of user data, including eSIM package details.

Network Basics

Hosting The Network

What Is A Ubitel Host?

A Ubitel Host is an individual, DAO, or other telco entity deploying host node and radio hardware to provide Ubitel’s Universal Basic Internet coverage in exchange for stablecoin payments and points.

Prerequisites to Become a Host

Physical Space: A clear outdoor area with compliance for radio emissions.
Internet Access: Outbound connection for web2 internet services.
Radio and Node Hardware: Combination of node and radio hardware for network deployment.

Hardware Requirements:

Node Hardware:

The job of the node hardware is to monitor the on-chain Subscriber Registry and run a small CN this can run on minimal hardware like Raspberry Pi.

Radio Hardware:

The radio hardware will provide connectivity to subscribers; we support COTS or FLOSS options both band and region agnostic.

Name

Band

Status

Type

Baicells Nova227

CBRS

Working

COTS

Baicells Nova223

CBRS

Working

COTS

Blade RF xA9

Muilt (5G)

Working*

FOSS*

USRP/USRP Clones

Multi (5G)

Working*

FOSS*

Hardware Freedom: You are free to choose what works best for your wallet, local DAO size and country’s radio frequency regulations; up to and including running a completely FLOSS hardware stack. Macro to femto sized setups.

Figure: A variety of COTS and FLOSS Radio flavors.

We do not gatekeep across hardware, locality nor RF frontend

Node Setup:

Run the forked telco CN and bridge middleware on hardware of your choosing ex. Raspberry Pi, binaries provided for aarch64 and x86_64

The CN is currently implemented in a fork of SRSRAN (srsepc) found here: SrsEPC Fork

Please follow below for more setup details. SrsEPC requirements

You will also need to run the python hss bridge middleware alongside the forked CN above Ubitel HSS Bridge
Radio Unit Hardware Setup:
- Follow manufacturer’s instructions for installation and mounting.
- Configure radio unit’s EPC/CN address to match that of the Node EPC/CN above.
Ubitel Host Registration:
- (Optional) Manually register host through the bridge middleware or register your pubkey through the DApp at Ubitel Host DAO

Using The Network

This section focuses on subscribing to decentralized Ubitel Hosts’ internet services.

Requirements

User Equipment

Subscribers need a device to connect to the network, users can bring their own COTS LTE/5G user equpiment; phone, modem etc. so long as the below are true.

Device has a physical SIM-card slot or supports eSIM (initial esim feature parity with pSIM)
Device supports bands provided by local hosts.

Ubitel ETHTEE

Subscribers will need to obtain or create their own Ubitel ETHTEE to connect to the Network. You can buy one from us at https://shop.ubi.tel in either eSIM or pSIM format. Or bring your own compatible smartcard.

Subscriber Setup

For ease of use, you can automatically register your Ubitel ETHTEE by being in range of a network host. Alternaively we have a manual DApp that provides this functionality should you not be in a covered area.

Ubitel ETHTEE Setup: - Users must insert the Ubitel ETHTEE into their phone
Registering Ubitel ETHTEE On-Chain: - User must visit be near a host for initial OTA registration, OR they can do it through the DApp below - (Optional) Manually Add Subscriber Authentication Keypair to on-chain registry at Ubitel Subscribe

ETHTEE Security+

Ubitel leverages our unique ETHTEE wallet technology to enhance cellular radio link security and decentralize AAA (authentication, administration, and accounting) processes inside telco networks. Instead of relying on the traditional cellular network authentication system called MILENAGE we introduce modern asymmetric PKI cryptography via ECDH with Ethereum-native cryptography (secp256k1 & altbn128).

Introduction

Ubitel’s approach to security and decentralization in telecommunications is rooted in addressing the limitations of the traditional AAA and MILENAGE framework. By implementing hardware wallet security and smart contracts, we ensure a secure, soverign and decentralized telecommunications environment, even on devices as simple as flip phones.

Challenges with Traditional Systems

MILENAGE, the conventional cellular network authentication system, necessitates a carrier-owned centralized database where all private key material is stored. This centralized approach poses significant security risks, as it places the security of user data in the hands of a few large telecommunications companies, which are prone to exploitation.

Key Improvements

Ubitel addresses these challenges through several key improvements:

Ownership of Private Keys: We move the private key out of a centralized database and into a sovereign physical ETHTEE wallet owned by the user. This eliminates vulnerabilities associated with SIM swaps and eavesdropping, and empowers users with a full Ethereum hardware wallet based on proven secure element technology, the same as popular hardware wallet brands such as Ledger, Grid+ & Status Keycard.
On-chain Subscriber Registry: Subscriber public keys are stored on-chain in an immutable sovereign subscriber registry, similar to a telco HSS (Home Subscriber Server). This allows users to activate services, top-up their accounts with cryptocurrency, and perform other functions without the need for intermediaries, including potentially unreliable customer service.
Global Roaming Subscription: By storing subscriber information on-chain, Ubitel ensures a truly global roaming subscribership, enhancing accessibility and connectivity for users worldwide.

Conclusion

Ubitel’s utilization of ETHTEE technology and innovative cryptographic techniques represents a significant advancement in the field of telecommunications security and decentralization. By addressing the limitations of traditional systems, we provide users with greater control over their data and a more secure telecommunications experience.

Technical Flow

Below is the general flow from Hosts through Core Network and out to Subscribers

Ubitel HSS Smart Contracts

You can find our Smart Contract implementation of the on-chain HSS subscriber registry here. In it’s simplest form it’s just a list of subscriber public keys; of which the private key is stored in the ETHTEE. This is crucial to the ECDH process as well as determining who is allowed on the network; the conditions of their subscription etc. Ubitel Subscriber Registry

TEEPOT Network

Distributed Trustless Execution Applets on Secure Smartcard Platforms

What?

Broadly speaking, the goal is to deploy hundreds of thousands of these distributed Trusted Execution Environments (TEEs) at the edge.

ETHTEEs can be integrated into phones, nodes, or minimal hardware setups—such as those used in home staking—to provide decentralized, trusted execution environment (TEE) capabilities.

Why?

Smartcard-based execution environments offer unmatched security and scalability:

Cost-effectiveness: Custom-fabricated solutions are expensive (7-8 figures) and require years to develop.
Accessibility: ETHTEEs are low-power, abundant, and inexpensive, enabling broad geographic and economic distribution, which enhances resilience and accessibility.
Edge compatibility: Designed for edge devices, ETHTEEs operate seamlessly on mobile phones, unlike server-based TEEs like Intel SGX or AMD SEV.
Ethereum alignment: Supports Ethereum’s roadmap to enable mobile validators.
Advanced functionality: More capable than native secure enclaves in phones, such as iPhone’s Secure Enclave, which has limited functionality (e.g., restricted to P-256).
Proven security: Over three decades of deployment and billions of devices with no mission-critical exploits reported. ETHTEEs have fewer vulnerabilities than SGX and SEV, with a minimized attack surface.
High certification: Certified to EAL6+ security standards, exceeding the capabilities of AMD, Intel, and ARM TrustZone.

TEEPOT Architecture Overview

TEEPOTs are secure element-based Trustless Execution Environments (TEEs) optimized for secure trustless execution at the edge, even in limited hardware like home staking nodes and mobile phones.

While TEE- “Trusted Execution Environment” is the popular nomenclature to describe products like the TEAPOT. ie. those that do some sort of “blinded/obsfucated/shielded” compute, We are emphasising that our platfrorm is designed to be much more “trustless” than current offerings from Intel, AMD even at the hardware level.

In fact TEEPOT hardware is much more robust, secure and resilliant than offerings from Intel, AMD etc. both in hardware as well as in general distribution and availability because TEEPOTs are not reliant on a centralised shared servers in the cloud and so called “glock-security”. TEEPOTs are the most secure and robust TEEs on the market and are the product of 30+ years of besopke secure element R&D and are designed to be tamper resistant, unlike other offerings they carry EAL6+ certification. In fact

Dare you to find any EAL certifications for Intel or AMDs offerings. And in fact you will find that there are a littany of exploits past and continuing on Intel and AMDs offerings. In fact of note is that SGX was origionally a component of Intel Managment Engine which has a dubious and checkered security past.

Key Features:

TEAPOTs autonomously perform trustless execution tasks and services.
Tasks are coordinated across a distributed, decentralized network.
An economic model similar to Ethereum’s GAS is leveraged for trusted execution.

Core Concepts

ETHTEE: This is the physical TEE hardware that comprises TEAPOTs and that provides the environment and physical resources that TEAs rely on
TEAPOT: The execution unit(s) that host trustless execution applets (TEA) and perform arbitrary computation inside those applets in a secure environment. A TEAPOT maybe a single ETHTEE or a group operating in a randomized or deterministic setup for a specific trustless execution task.
TEA (Flavors): These are “Trusted Execution Applets” (TEAs) containing secure code applets verified by the network and that that run within the ETHTEE hardware. They are authenticated by the network and verified for secure operation through remote attestation.
BREW: The execution tasks that run inside a TEAPOT, managed and verified by the decentralized ETHTEE network.
BREWMASTER: Decentralized TEA and BREW manager, runs according to on-chain consensus and rules.

Economic Model for TEA brewing

TEEs can stake value to secure authenticity on the network. Brewers pay for ETHTEE services via our coin

Brewmaster - Decentralized Applet and Execution Manager

The Brewmaster deploys various TEA applets to TEAPOTs and assigns them BREWS to execute inside the TEAs. The Brewmaster takes in some job from either the internal network for example onboarding a new node’s public key or from an external actor that needs trustless compute.

TEA execution is parallelizable, allowing single or multiple TEAPOTs to handle brews depending on task requirements.

TEA Flavor Management

Ensuring that Trustless applets are deployed using verified code.

Each TEA flavor is autonomously installed, verified, and managed across ETHTEE nodes by the BREWMASTER, enabling diverse, trustless execution tasks (“brews”) requested by clients.

The network ensures that only verified TEA flavors run on physically secure ETHTEE hardware, with results delivered to brewers for a fee.

Technical Specifications

Each TEA is a deployed smartcard applet running inside a TEAPOT(s) secure environment. TEA flavors are installed and managed remotely and autonomously by the BREWMASTER.

Trustless execution applets are managed (installed, updated, removed) permissionlessly and verifiably according to GlobalPlatform specifications:

We utillize management functions of GP to ensure that verifiable TEA and only verifiable TEA code is loaded onto the TEAPOT.
This ensures that only code signed by the network or by Ubitel initially will even install on TEAPOTs

**Progressive Decentralization **

Phase 1: TEAs are signed by Ubitel’s multisig, providing an initially centralized management environment for TEA code verification and loading.

Phase 2: As the network grows TEAs are signed by the broader TEAPOT network using FROST threshold signatures and economic stake. A quorum of staked signers can produce signatures across applet code that will be come a TEA.

TEA Execution & Verification

There is a clear method to ensuring that TEAs run verified code but we need to verify that this code is being executed inside of a real life ETHTEE. There are two bespoke methods we use to do this. RA and Receipts. RA ensures that a physical ETHTEE device is running the process inside it’s secure isolated environment.

Receipts are used to verify the execution outputs of BREWs and for secure deletion of keys and applets.

Remote Attestation Methods

ETHTEE nodes perform remote attestation (RA) to ensure that execution takes place inside of the actual ETHTEE hardware, and not for example a normal computer.

There are many methods of doing RA. And we will progressively decentralize this

Including seeding a TEA that specifically creates an internal RA keypair at personalization time and remotely and autonomously by the BREWMASTER

This TEA will have a verifiable code. The code will use normal JC APIs. to create a protected keypair. The private key of which will never leave the execution environment, even under physical attack. ‘ However it will expose a function to sign some attestation data. Thus, we can use this to ensure that an ETHTEE is being used for computation and nothing else.

Furthermore, once we achieve manufacturer-level access, we can use methods such as physical unclonable functions (PUFs), raw memory hashes and other more advanced methods to ensure Remote Attestation.

Progressive Decentralization of RA

Phase 1: The RA key is created at setup and subsequently by the BREWMASTER

Phase 2: Access to additional features, such as PUFs and memory management, enables enhanced RA capability.

Certificate Authority (CA) Decentralization for Wireless Networks

Traditional WiFi and cellular networks rely on centralized CAs. For genuine decentralization, Ubitel aims to develop a “Meta-DePIN” layer acting as a decentralized CA. This allows a single public key in eSIM profiles, governed by FROST threshold signatures, to validate new network participants without centralization.

Decentralized Execution Manager - DEM

This is the framework that delivers various trustless applets TEAs and instructs ETHTEE nodes to handle brew jobs to perform work on the network

TEA execution and thus brews can be parallelized, and depending on the parameters of the brew can be executed by one or many TEEs in the TEAPOT in a random or uniform way.

Trustless Execution Applets (TEAs)

TEAs are secure applets that are deployed in a decentralized, autonomous, and, above all, secure manner.

TEA flavors are autonomously, remotely and securely distributed by the Decentralized Execution Manager to ETHTEE nodes.

Technical

Each TEA is a Javacard application (CAP file) that contains code that will run inside the ETHTEE secure environment. TEAs are installed and managed by the DEM remotely according to gp specifications.

Obstensively, this means that TEA flavors are signed off on by the network DAO at large, and only those that are signed off on will be executed in each node’s ETHTEE hardware.

Progressive Decentralization of TEA Management Security Domain

PHASE 1:

TEAs are signed off on by Ubitel multisig in a centralized manner (we personalize the GlobalPlatform environment to be this)

PHASE 2:

TEAs are signed off on by the network at large with threshold signatures. staked nodes are chosen and use FROST threshold signatures.

TEA Flavors

*FROST Threshold Signature Scheme

*Distributed CA using the above

*VDF (Leveraging the hardwares native slowness)

*Creating zk proofs

GIVE example of MEV TEA code

What do we need to do to turn Javacard environment into something like a TEE.

Remote Attestation:

variety of different methods:

Things that require privileged access from mfgr. PUF, hash of memory (presuming low level C access in needed)

Some RA key is provisioned at personalization OR remotely via gp etc.

Progressive Decentralization

Phase 1:

RA key created at personalization , Ubitel only knows the public key and puts this on chain

Phase 2:

We get access to PUF, low-level memory management etc. for proving RA.

**Why does Ubitel need this for a DeISP ? ** Namely to decentralize the root of trust in cell and wifi networks, but also to validate our L3

How it works in WiFi

Currently, in WiFi without a centralized CA you’d have to issue your own cert or have to install a cert for every new connection to a new public network.

From a UX point of view this is a “add new exception” for every new network you want to be on. And takes away the verifiability that actors are truly part of the Ubitel network

How it works in Cellular

In Cellular it’s even worse, we basically get one TLS public key for the whole network.

We’re trying to get rid of MILENAGE and instead use TLS…. Put in releveant 3GPP spec.

WHY get rid of milenage…

With eSIM we can presumably prevision a public key but this opens up to 2 problems:

making this public key dynamic during the eSIM provision process is going to be near impossible, ie. we basically get a 1 shot provision of each eSIM profile there is cost and no go UX associated if we were to put in a new TLS provider key for every accesspoint.

Solution: Meta-DePIN Layer

Regardless, both of these rely on a centralized Certificate Authority. So to truly decentralize wireless network we build our own meta-DePIN layer that serves as a decentralized Certificate Authority.

Thus we can put a single public key in the eSIM that has to be provisioned by a trusted third party without ever centralizing this root of trust, even to the 3rd party (currently this happens in MILENAGE)

for TLS and still have a decentralized network allow new providers on the network by FROST threshold signing on new entrants certificates as if they came from a centralized CA

There are a few decentralized CA network projects out there like LIT protocol.

Why does Ubitel need this ? In order to truly decentralize wireless DePIN networks we need to decentralize the Certificate Authority which generally comes from a centralized root of trust in wireless networks.

Examples of Emerging Markets for TEEPOT compute services

Similar to how Ethereum charges GAS for Proof-of-Stake-based global execution, markets are expected to emerge for trusted execution on ETHTEEs.

Examples of emerging markets include:

LIT, Automata Network, Threshold, LINK all have markets for various “Trusted” execution
Ubitel’s L3 Chain, which will utilize distributed TEAPOTs in-house for: - Security and scaling of the Layer 3 blockchain. - Decentralization of ISP root-of-trust.

Examples of Trustless Execution Primitives that can be brwed inside TEAs

Distributed of Threshold Signatures,
Distributed DKG,
Distributed VDF

—

Example: MEV Proof Miner TEA

This example TEA is a proof of concept that demonstrates how to create a TEA that takes in a batch of transactions and throughly randomizes them before signing with an unextractable key bonded to the TEAPOT. Thus, eliminating transaction ordering and MEV.

package teapot;

import javacard.framework.*;
import javacard.security.*;
import javacardx.crypto.*;

public class ShuffleHashApplet extends Applet {
    private static final short ELEMENT_SIZE = 32; // 32 bytes for each element
    private static final byte CLA_TEAPOT = (byte) 0x80;
    private static final byte INS_MIX_AND_HASH = (byte) 0x10;

    private RandomData rng;
    private MessageDigest keccak256;

    private byte[] inputBuffer;
    private byte[] outputBuffer;

    private ShuffleHashApplet() {
        // Allocate buffers
        inputBuffer = new byte[256];  // Example buffer size
        outputBuffer = new byte[32]; // For 32-byte Keccak256 hash

        // Initialize RNG and Keccak256 hash
        rng = RandomData.getInstance(RandomData.ALG_SECURE_RANDOM);
        keccak256 = MessageDigest.getInstance(MessageDigest.ALG_SHA_256, false); // Replace with Keccak256 instance
    }

    public static void install(byte[] bArray, short bOffset, byte bLength) {
        new ShuffleHashApplet().register();
    }

    @Override
    public void process(APDU apdu) {
        byte[] buffer = apdu.getBuffer();

        if (selectingApplet()) {
            return;
        }

        if (buffer[ISO7816.OFFSET_CLA] != CLA_TEAPOT) {
            ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
        }

        switch (buffer[ISO7816.OFFSET_INS]) {
            case INS_MIX_AND_HASH:
                mixAndHash(apdu);
                break;
            default:
                ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
        }
    }

    private void mixAndHash(APDU apdu) {
        byte[] buffer = apdu.getBuffer();
        short lc = apdu.setIncomingAndReceive(); // Number of bytes received

        if (lc % ELEMENT_SIZE != 0 || lc == 0) {
            ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
        }

        short numElements = (short) (lc / ELEMENT_SIZE);

        // Copy input data to buffer
        Util.arrayCopyNonAtomic(buffer, ISO7816.OFFSET_CDATA, inputBuffer, (short) 0, lc);

        // Shuffle the array using Fisher-Yates shuffle
        shuffleArray(numElements);

        // Hash the shuffled array
        keccak256.reset();
        keccak256.doFinal(inputBuffer, (short) 0, lc, outputBuffer, (short) 0);

        // Send back the hashed result
        apdu.setOutgoing();
        apdu.setOutgoingLength((short) outputBuffer.length);
        apdu.sendBytesLong(outputBuffer, (short) 0, (short) outputBuffer.length);
    }

    private void shuffleArray(short numElements) {
        for (short i = (short) (numElements - 1); i > 0; i--) {
            short j = (short) (rng.nextByte() & 0xFF); // Random index
            j = (short) (j % (i + 1)); // Restrict to range [0, i]

            // Swap elements at i and j
            short offsetI = (short) (i * ELEMENT_SIZE);
            short offsetJ = (short) (j * ELEMENT_SIZE);

            for (short k = 0; k < ELEMENT_SIZE; k++) {
                byte temp = inputBuffer[(short) (offsetI + k)];
                inputBuffer[(short) (offsetI + k)] = inputBuffer[(short) (offsetJ + k)];
                inputBuffer[(short) (offsetJ + k)] = temp;
            }
        }
    }
}