Inside the engineering work strengthening marketplace security, resource ownership, transaction verification, and recovery across the RAGE REALMZ ecosystem.

Building a secure digital marketplace requires more than making transactions work. It requires proving that they work correctly, that ownership cannot be manipulated, that resources cannot be duplicated, and that failures do not compromise the integrity of the system.

That is the engineering challenge behind Whisper, the marketplace and transaction infrastructure within the RAGE REALMZ ecosystem.

On November 13, 2026, Whisper reached an important engineering milestone: its Phase 3 automated security test suite completed with 631 tests passed and zero failures, finishing in approximately 33.47 seconds.

But the number alone doesn’t tell the story.

Behind those 631 successful tests is a substantial body of engineering work focused on some of the most important challenges facing transactional digital ecosystems: ownership verification, reservation management, treasury protection, cryptographic proofs, blockchain settlement, recovery mechanisms, and operational reliability.

The Phase 3 review examined how Whisper responds not only when everything works as expected, but also when things go wrong.

What happens when a transaction is replayed? What happens when a wallet attempts to claim resources belonging to someone else? Can a resource be transferred twice? Can an incomplete blockchain confirmation release reserved assets? What happens when a service restarts in the middle of an operation?

These are the kinds of questions the test suite was designed to address.

The results demonstrate extensive automated coverage across marketplace operations, Water resource accounting, checkout authorization, settlement finalization, Oracle authority, cancellation verification, public transaction history, and graceful server shutdown.

Particularly important are the safeguards designed to prevent duplicate transfers, unauthorized ownership changes, premature resource releases, and inconsistent financial or inventory records.

The report also examines release verification and deployment safeguards, including protections against tampered contract artifacts and unauthorized publishers.

However, responsible engineering means being transparent about what testing proves — and what it doesn’t.

Although all 631 reported tests passed, the review does not establish production certification. Repository-wide secret scanning, Git-history verification, production configuration review, and deployment validation remain outstanding verification tasks.

That distinction matters.

A successful test suite is evidence of engineering progress. Production readiness requires additional evidence.

This report documents what Phase 3 demonstrated, where Whisper’s strongest tested safeguards stand, and what remains before a broader production-readiness conclusion can be justified.

For RAGE REALMZ, this milestone represents more than a passing test run. It represents a continued commitment to building systems where ownership, transactions, resource integrity, and recovery are governed by verifiable engineering rules.

631 passed. Zero failed. Phase 3 complete.

The next challenge is turning that engineering evidence into independently verified production confidence.

Read the accompanying Whisper Detailed Engineering & Security Report for the complete technical breakdown.

By ApeLevel Gaming & Branding | November 13, 2026

As PARLAY continues developing its blockchain-powered governance platform, a dedicated Privacy Policy establishes an important foundation for transparency between the application, its operators, and the community members who use it.

Privacy in a Blockchain-Connected World

Privacy in cryptocurrency applications is different from privacy on traditional websites.

When someone connects a wallet, participates in a governance vote, or registers a blockchain-linked username, certain information may become associated with a publicly identifiable blockchain address.

That does not automatically reveal someone’s real-world identity. However, blockchain activity can be publicly observable, and wallet addresses can sometimes be connected to individuals through information disclosed elsewhere.

For a platform like PARLAY, which combines token-weighted governance, cryptographic wallet authentication, permanent usernames, and a public prediction leaderboard, understanding these distinctions is particularly important.

That is why PARLAY has introduced a dedicated Privacy Policy for its application.

The objective is straightforward: provide users with an accessible explanation of the platform’s information practices, responsibilities, and relevant privacy considerations.

What Makes PARLAY Different?

PARLAY is not a conventional social media website or centralized voting platform.

Developed by ApeLevel Gaming & Branding for Skuxx and the PARLAY community, the application uses Robinhood Chain blockchain infrastructure alongside Cloudflare-hosted application services.

Its technical features include:

• Wallet-based authentication: Participants can establish control of their connected wallets using cryptographic signatures.
• Token-weighted governance: Voting influence is calculated using PARLAY token holdings at the relevant blockchain snapshot.
• Permanent usernames: Eligible participants can register recognizable identities associated with their wallets.
• Public governance records: Certain voting information and supporting verification evidence are designed to be independently examinable.
• Prediction leaderboards: Verified results can contribute to public rankings associated with registered usernames.

These capabilities make transparency possible, but they also create responsibilities around how information is collected, stored, displayed, and retained.

A privacy policy helps explain those responsibilities.

Public Blockchain Records Are Not Private Database Records

One of the most important things PARLAY participants should understand is the difference between public blockchain information and information maintained by the application.

Blockchain transactions and publicly available token-transfer records may be independently accessible through blockchain explorers and network infrastructure.

PARLAY also maintains application records needed to operate features such as signed voting, username registration, proposal management, and historical verification.

These records serve different purposes and may be subject to different technical limitations.

For example, removing information from an application database does not necessarily remove an independently recorded blockchain transaction.

Likewise, a permanent wallet-linked username creates a persistent connection between a chosen public identity and the blockchain address used to register it.

The new policy provides an important reference point for understanding the platform’s information-handling responsibilities.

Security Without Asking Users to Surrender Their Wallets

PARLAY’s governance architecture was developed around signed wallet messages rather than requiring users to surrender custody of their tokens to participate in voting.

A cryptographic signature allows the application to verify that a request was authorized by the relevant wallet.

It does not require a user to disclose their recovery phrase or private key to the application.

Nevertheless, signed requests, wallet identifiers, voting records, and associated database information require responsible handling.

Security is not simply a matter of using blockchain technology. It also depends on authorization controls, database protections, infrastructure configuration, and the integrity of the surrounding software.

ApeLevel’s engineering approach has emphasized these controls throughout PARLAY’s development.

No internet-connected application can responsibly guarantee complete immunity from every potential vulnerability.

An Important Boundary Between ApeLevel and PARLAY’s Operators

ApeLevel Gaming & Branding developed PARLAY’s software infrastructure as a commissioned application.

The platform’s operators retain responsibility for their own business decisions, operational practices, and applicable legal obligations.

PARLAY governance is advisory: token-holder sentiment can inform wagering decisions, but it does not independently execute or authorize real-world wagers.

Similarly, publishing a privacy policy should not be interpreted as an independent security certification or a guarantee that all potential privacy risks have been eliminated.

The policy should be understood alongside the platform’s actual technical implementation and operating responsibilities.

Why Publishing the Policy Matters

One of the challenges facing emerging blockchain communities is establishing confidence without relying on exaggerated promises.

A transparent system should explain not only what its technology can accomplish, but also the limitations of that technology.

Publishing a dedicated Privacy Policy makes that information easier to locate and evaluate.

It also creates a public reference that can be updated as the application develops, new features are introduced, or information practices change.

For PARLAY participants, this is an opportunity to become more informed about how their wallets, usernames, governance activity, and other interactions relate to the platform.

For ApeLevel, it reflects a broader commitment to developing software with clear documentation and identifiable operational boundaries.

Read the PARLAY Privacy Policy

The PARLAY Privacy Policy is intended to be available through the application’s public website.

Privacy Policy: https://parlay.apelevel.workers.dev/privacy/

PARLAY Governance: https://parlay.apelevel.workers.dev/

Users should review the published policy for its specific terms, including the information collected, purposes of processing, potential disclosures, retention practices, and available privacy-related contact procedures.

As PARLAY continues evolving, clear technical documentation and accessible policies will remain important parts of maintaining a transparent governance platform.

About ApeLevel Gaming & Branding

ApeLevel Gaming & Branding develops custom websites, software applications, blockchain integrations, and interactive gaming experiences. PARLAY Governance was commissioned for Skuxx and the PARLAY community as a blockchain-integrated application supporting token-weighted participation, cryptographic verification, and public governance records.

Editorial disclosure: This article introduces PARLAY’s privacy initiative and describes the application’s documented engineering architecture. It is not a substitute for the operative Privacy Policy or independent legal or security advice.

Date: November 12, 2026
Organization: Apesoft Canada
Website: https://apesoft.ca
Status: Successfully deployed and verified

1. Executive Summary

Apesoft Canada successfully completed two website improvements focused on privacy, transparency, and reducing reliance on external services.

The work included publishing a comprehensive corporate Privacy Policy and migrating the website’s custom typography away from Google Fonts to locally hosted font files delivered through Apesoft Canada’s Cloudflare infrastructure.

Both implementations passed production build checks, were deployed successfully, and were verified through live HTTPS requests.

2. Privacy Policy Implementation

A dedicated, publicly accessible Privacy Policy was created at:

https://apesoft.ca/privacy/

The policy includes 17 sections addressing:

• Collection, use, protection, retention, and deletion of personal information.
• Customer inquiries and business communications.
• Spacebend player names and leaderboard information.
• Cloudflare infrastructure and third-party services.
• Artificial intelligence and automated technologies.
• Consent, privacy rights, and international processing.
• Children’s privacy and security safeguards.

Product-Specific Privacy Governance

The policy establishes that each software product developed or delivered by Apesoft Canada will be assessed individually and governed by privacy documentation appropriate to its operation.

This recognizes that Apesoft’s clients may face different legal obligations depending on their industries, jurisdictions, data processing activities, and product functionality.

Client-owned products remain subject to their applicable privacy arrangements, while Apesoft Canada retains responsibility for its own legal and contractual obligations.

Privacy Officer: Chad McDonald
Contact: apelevelbranding@gmail.com

The Privacy Policy was integrated into the homepage, customer inquiry form, About page, and XML sitemap.

Verification: Both the custom domain and Cloudflare Worker URL returned HTTP 200, with all 17 policy sections and required contact information confirmed.

3. Self-Hosted Font Implementation

Apesoft Canada eliminated Google Fonts references from its audited website production files and migrated its custom typography to locally served WOFF2 assets.

The original visual design was preserved.

Font familyWeights deployedManrope400, 500, 600, 700Cormorant Garamond400, 500, 600

Seven font files and their associated license documentation were deployed through Cloudflare.

Both font families were verified as distributed under the SIL Open Font License 1.1 (OFL-1.1).

The implementation also introduced a dedicated local font stylesheet at:

https://apesoft.ca/fonts/fonts.css

Verification results:

• All seven font files returned successful HTTP responses.
• All seven files passed WOFF2 format checks.
• The live stylesheet returned HTTP 200.
• All seven font declarations were confirmed.
• No Google Fonts references were found in the audited production files.
• The existing Spacebend game, Privacy Policy, and website assets remained present in the production build.

This improvement removes the need for browsers to contact Google Fonts servers to obtain Apesoft’s custom typography.

4. Deployment and Engineering Verification

The website was built using Vite and deployed through Cloudflare Wrangler 4.161.0.

Privacy Policy deployment:
7f93ff53-f9db-4220-957b-9439c6f06f13

Self-hosted fonts deployment:
1399e999-2f80-4d64-a807-2af1660b79e1

The final font deployment recognized 65 static assets and successfully uploaded 13 new or modified assets.

The existing Cloudflare Worker bindings for email delivery, the Spacebend D1 leaderboard database, and leaderboard submission rate limiting remained configured.

5. Limitations and Next Steps

These improvements establish a stronger privacy and transparency foundation but do not constitute a complete cybersecurity, legal compliance, or accessibility certification.

Further work will include:

• Auditing actual data retention and deletion practices against the published policy.
• Conducting WCAG 2.2 AA accessibility testing.
• Reviewing contact form and leaderboard security.
• Completing browser-level checks for unexpected third-party network requests.
• Maintaining separate privacy documentation for individual Apesoft and client software products.

6. Conclusion

Apesoft Canada successfully published its corporate Privacy Policy and transitioned its custom website typography to self-hosted infrastructure.

The changes improve public transparency, reduce dependence on third-party font delivery, and establish a clearer privacy framework for future software products.

Both implementations were verified in production without requiring changes to the website’s core gaming, music, or customer inquiry features.

Prepared by Apesoft Canada
British Columbia, Canada
https://apesoft.ca

Implementation report — November 12, 2026

Published by ApeLevel Gaming
November 11, 2026
Development Update | RAGE REALMZ | Whisper Market Live | Polygon Amoy

\A Market That Exists Beyond the Game

What happens to a game’s economy when the game server goes offline?

For most players, the answer is simple: they lose access to it.

But when an in-game economy begins recording actual blockchain-associated transactions, something interesting happens. Those transactions become part of a history that shouldn’t disappear from public view just because the game itself is temporarily unavailable.

That’s one of the ideas behind Whisper Market Live, the independent market-observation platform being developed for ApeLevel Gaming’s RAGE REALMZ ecosystem.

The website already exists.

Visit Whisper Market Live:
https://whisper-market-live.whispermarketlive.workers.dev

It displays recorded Water trades, execution prices denominated in test TILT (tTILT), historical transaction references, and a graphical record of price activity.

It’s hosted independently through Cloudflare Workers and Cloudflare D1.

And unlike the game itself, you don’t need to connect a cryptocurrency wallet or enter a virtual world to inspect its market history.

But there was one major limitation.

The website could display historical transactions, but new trades still had to be manually imported.

This week’s engineering work focused on changing that.

From a Public Dashboard to a Self-Updating Market

During the previous development session, Apesoft Canada helped ApeLevel Gaming recover nine finalized Water transactions from Whisper’s original SQLite settlement ledger.

Those records represented:

• Nine Water units traded.
• Eight SELL transactions and one BUY transaction.
• A combined historical settlement value of 9.25 tTILT.
• Execution prices of 1 and 1.25 tTILT per Water.

Those transactions were validated using Whisper’s settlement records and imported into a dedicated Cloudflare D1 database.

That gave us the beginnings of an independent market observatory.

However, the dashboard couldn’t automatically learn about the next trade.

If another player bought or sold Water, Whisper would finalize the transaction internally, but the public website would continue showing the previously imported history.

The website could refresh as often as it wanted. If the new information hadn’t reached Cloudflare, there was nothing new to display.

So the next engineering challenge wasn’t another visual feature.

It was connecting two systems that deliberately operate separately.

How do you automatically publish newly completed trades without giving a public website control over the game economy?

Our answer was to build a dedicated synchronization pipeline.

First, We Had to Understand Exactly When a Trade Becomes Final

Whisper Market handles Water purchases and Water sales through separate settlement-finalization functions.

We inspected both.

In each case, the system performs several important operations before returning a successful settlement result.

It checks the relevant settlement records, updates Water ownership, records the resource transfers, and changes the settlement’s status to FINALIZED.

The BUY operation also transitions the buyer’s capacity reservation, while the SELL operation handles its applicable treasury-capacity transition.

Both paths commit their database transactions before returning successful finalization.

That gave us an important architectural boundary.

We didn’t need to rewrite Water trading.

And we didn’t need to make gameplay wait for Cloudflare.

Instead, we could develop a separate service that looks for transactions Whisper has already finalized.

If Cloudflare becomes unavailable, a player’s completed Water trade should remain completed.

The synchronization system can retry later.

That separation is fundamental to the design. Public reporting must never become a requirement for successful gameplay settlement.

The Security Question: Who Is Allowed to Publish a Trade?

A publicly accessible market dashboard needs to be readable by anyone.

But it cannot allow just anyone to submit their own transactions.

Imagine a visitor could send a message saying they purchased 10,000 Water for one million tTILT, and the website simply accepted it.

The public price history would become meaningless.

We therefore developed a separate authenticated receiving endpoint:

POST /api/whisper/sync

This is not a public trading endpoint.

It does not purchase or sell Water, sign wallet transactions, or change player inventory.

Its purpose is to receive finalized market records from an authorized synchronization process.

The original public history endpoint remains:

GET /api/whisper/public/trades

Anyone can inspect market history. Only a client possessing the private synchronization credential can attempt to publish a record.

Testing the authentication system

We generated a cryptographically random credential and installed it as a Cloudflare Worker secret named WHISPER_SYNC_SECRET.

The credential was not embedded in the public website or application source code.

We then tested the deployed endpoint directly.

An unauthorized submission returned:

HTTP 401 — Unauthorized

A submission containing the correct credential but an invalid trade returned:

HTTP 400 — Invalid Water trade

That second result was particularly useful.

It confirmed the real Cloudflare Worker recognized the authentication credential and allowed the request to reach trade validation.

The invalid submission was rejected before the database-writing stage.

These tests were performed without importing fictional trades into the production database.

The original nine historical transactions remained available.

A Trade Isn’t Valid Just Because Its Numbers Look Convincing

Authentication answers one question: who submitted the information?

Validation answers another: is the submitted information structurally consistent?

The synchronization receiver checks that incoming records identify Water as the traded resource, use the expected Polygon Amoy network, contain valid transaction-hash formatting, and represent either BUY or SELL activity.

It also checks quantities and execution prices.

This becomes especially important when one checkout contains multiple prices.

Consider a hypothetical transaction involving two Water units.

One sells for 1 tTILT.

The other sells for 1.5 tTILT.

The total should be 2.5 tTILT, and the volume-weighted average price should be 1.25 tTILT per Water.

The receiver needs to reject a submission that claims the total was 8 tTILT or provides an average-price ratio inconsistent with the individual executions.

We added those mathematical integrity checks and introduced limits on unusually long numerical fields.

Seven additional financial-validation tests passed.

There is an important distinction here: these checks verify the submitted record’s format and arithmetic. They do not independently prove that a blockchain transaction occurred.

The game-side pipeline is designed to reuse Whisper’s existing settlement-integrity validator, which examines finalized intents, matching receipts, resource transfers, manifest hashes and payment consistency.

Independent verification against live Polygon Amoy transaction receipts remains a separate engineering objective.

We Tested Against the Real Cloudflare Database Structure

One of the more revealing moments came during database compatibility testing.

The locally developed synchronization receiver initially attempted to insert three fields:

• Trade ID.
• Recorded timestamp.
• JSON transaction payload.

However, inspection of the actual production Cloudflare D1 database revealed a fourth required field: the blockchain transaction hash.

The table also automatically records an import timestamp.

Had we deployed the original insert statement unchanged, it would have failed against the production schema.

We corrected the receiver and tested it using a local SQLite table matching the actual Cloudflare structure.

The tests confirmed successful insertion, duplicate handling, transaction-hash storage, original-record preservation and automatic timestamp generation.

That is exactly why testing against actual infrastructure specifications matters.

Code can work perfectly in a simulated database while still being incompatible with the database it’s supposed to use.

What Happens If the Same Trade Is Sent Twice?

Automatic systems must be prepared for interruptions.

Imagine Whisper successfully sends a transaction to Cloudflare.

Cloudflare saves it.

But the connection drops before Whisper receives the success message.

From the publisher’s perspective, the result is uncertain.

The safest response is to retry.

However, that retry must not create a second historical transaction.

Our receiver uses an insert-only approach that preserves the existing trade record.

If a submitted trade already exists, the receiver checks whether the saved record matches the submitted one.

An identical retry can be acknowledged safely.

A different transaction using an existing trade identifier is rejected with a conflict response.

We tested both scenarios.

This is the foundation of idempotent delivery: repeating a successful operation should not keep changing its result.

For a market-history system, that helps prevent duplicate entries and accidental corruption of historical records.

Building the Publisher That Talks to Cloudflare

With the receiving endpoint deployed and tested, development shifted back to the RAGE REALMZ server.

We created a separate game-side publisher responsible for sending previously validated Water trade records to the approved Cloudflare endpoint over HTTPS.

It includes a 10-second request timeout and distinguishes between several types of delivery outcomes.

A successful insertion can be acknowledged.

An already-synchronized trade can be acknowledged.

A temporary network outage can be marked for retry.

An authentication failure can be treated as a non-retryable configuration problem rather than repeatedly sending the same invalid credential.

The publisher also restricts its destination to the approved Whisper Market Live endpoint.

Five simulated publisher tests passed.

At this point, we had a functioning receiving endpoint in Cloudflare and locally tested code capable of publishing transaction records.

But automatic publication still required reliable scheduling and persistent recovery state.

The Problem With Remembering What Has Already Been Published

Imagine Whisper synchronizes 500 transactions.

Then the game server restarts.

How does it know which transactions have already reached the public website?

If synchronization progress exists only in application memory, it disappears during a restart.

We therefore created a separate persistent SQLite checkpoint system.

The checkpoint database is distinct from the operational Whisper settlement ledger.

Its job is straightforward: remember which trade identifiers and transaction hashes Cloudflare has successfully acknowledged.

After a successful delivery, the coordinator records the checkpoint.

On a later run, the coordinator can skip that transaction.

We tested this process by writing a checkpoint, closing the SQLite database, reopening it and checking whether the record still existed.

It did.

We also tested that a conflicting transaction hash could not replace an existing checkpoint.

Five persistence tests passed.

This is a significant step toward unattended operation, although the deployment host’s persistent-storage behavior must still be verified before enabling continuous synchronization.

Cloudflare Can Go Down Without Taking Water Trading With It

We also developed a synchronization coordinator.

The coordinator is responsible for organizing trade delivery.

It reads validated history, orders transactions chronologically, checks whether each record has already been synchronized, sends outstanding records through the publisher, and stores success checkpoints.

If the publisher encounters a temporary failure, the coordinator stops that delivery sequence rather than pretending everything succeeded.

The outstanding transaction remains eligible for a later attempt.

We tested successful delivery, already-synchronized records, recovery after simulated Cloudflare outages, overlapping-run prevention, history-limit handling and checkpoint-write failures.

All six coordinator tests passed.

Then we connected the coordinator, publisher and persistent checkpoint storage through a synchronization runner.

End-to-end local testing demonstrated that two simulated trades could be delivered in chronological order.

A second synchronization cycle skipped both already-completed deliveries.

A simulated runner restart also preserved that behavior.

Four of four end-to-end checks passed.

The original settlement operations remained outside this publishing workflow.

A Problem We Didn’t Want to Ignore: What Happens After 100 Trades?

The initial history reader had a practical limitation.

It retrieved at most 100 qualifying transactions.

That works when there are only nine transactions.

But what happens after the game grows?

Suppose the synchronization service is unavailable while hundreds of transactions accumulate.

If the publisher only retrieves the newest 100, older unsynchronized trades might never reach the public dashboard.

We didn’t want the system to silently pretend its historical record was complete.

Our initial coordinator therefore stopped safely when it couldn’t guarantee that all relevant history had been retrieved.

The next development stage introduced cursor-based pagination.

Instead of requesting a single limited history set, the reader can advance through settlement candidates page by page, using recorded timestamps and transaction identifiers to determine where the next page begins.

We tested its behavior with multiple pages, identical timestamps and invalid settlement candidates.

We also built a paginated synchronization source that adds duplicate detection, repeated-cursor protection and safeguards against incomplete historical retrieval.

Its five local tests passed.

This creates a foundation for historical catch-up after extended downtime.

However, the final connection between the paginated reader and the synchronization runner has not yet been confirmed by a completed integration test.

That work remains part of the next development session.

Where Whisper Market Live Stands Today

The public website remains operational:

https://whisper-market-live.whispermarketlive.workers.dev

The nine previously imported historical Water transactions remain available.

The authenticated Cloudflare synchronization receiver is deployed and has passed its live authentication checks.

The game-side publisher, persistent checkpoints, coordinator, runner and paginated reader have all been developed and tested individually or in defined combinations.

But Whisper Market Live is not yet automatically updating when a new Water trade occurs.

That’s an important limitation to state clearly.

The remaining work is to finish connecting the paginated history source to the runner, test recovery with larger validated trade histories, establish a reliable automatic schedule, and demonstrate actual end-to-end synchronization under live operating conditions.

Our intended target is for newly finalized Water trades to appear on the website within approximately 60 seconds, assuming the game server, synchronization process and Cloudflare service are available.

That is an engineering target, not a production performance result we’ve already achieved.

Why ApeLevel Gaming Is Investing in This Infrastructure

Whisper Market is more than a menu where players exchange resources.

It is part of the developing RAGE REALMZ economy.

Water has individual resource identifiers. Ownership transfers follow settlement rules. The game tracks resource availability and capacity while blockchain-associated token payments occur on Polygon Amoy.

As that system expands, historical transparency becomes increasingly valuable.

Players should be able to see what actually traded.

They should be able to examine recorded execution prices rather than rely on invented reference values.

And they should be able to inspect the history even when the game itself is temporarily offline.

There is also a practical development benefit.

By separating observation from execution, we can improve the public dashboard without repeatedly modifying the sensitive game-settlement engine.

The website can evolve independently, while Whisper retains authority over game inventory and settlements.

This does not eliminate security risks or make historical records automatically trustworthy. But it gives us a clearer architecture in which each component has a narrower responsibility.

The Role of Apesoft Canada

This infrastructure work was carried out with Apesoft Canada, the software-development company within the broader ApeLevel business ecosystem.

The development process combined AI-assisted code generation with manually reviewed and executed development commands.

Rather than granting an autonomous AI system unrestricted access to GitHub Codespaces, each engineering change was implemented through controlled steps, with deliberate tests, backups and deployment boundaries.

That approach does not make software immune to vulnerabilities.

It does, however, allow potentially sensitive changes to be examined and tested before they reach live infrastructure.

For Whisper Market Live, that included testing database constraints, authentication, duplicate handling, token arithmetic, server responses, persistent checkpoints and recovery behavior before enabling the next stage.

The Next Milestone: The First Automatically Published Water Trade

The next major demonstration won’t be another screenshot of the dashboard.

It will be a genuinely finalized Water transaction appearing on Whisper Market Live without manually exporting SQL, importing records or editing the database.

The successful demonstration should confirm that Whisper identifies the finalized trade, validates its historical record, delivers it through the authenticated publisher, receives Cloudflare’s acknowledgement and stores the corresponding checkpoint.

Then the public dashboard should display the new transaction.

A later restart should not cause a duplicate.

And a temporary Cloudflare outage should not undo a player’s completed settlement.

That’s the system we’re building toward.

The previous development session established the independent public dashboard.

This session established and tested much of the infrastructure needed to automate its updates.

The receiving side is live. The publishing pipeline is substantially developed. Automatic operation is the next milestone.

RAGE REALMZ continues to grow beyond the boundaries of a traditional browser game, with Whisper Market Live forming the public-history layer of its developing resource economy.

Follow ApeLevel Gaming for further development updates.

ApeLevel Gaming
RAGE REALMZ — Whisper Market

Software engineering: Apesoft Canada
Network: Polygon Amoy Testnet
Public market dashboard: https://whisper-market-live.whispermarketlive.workers.dev

Development status as of November 11, 2026. Historical prices refer to testnet tTILT, not fiat-market valuations. This article describes implemented software, completed tests, and planned development; it does not represent an independent blockchain security certification.

By Apesoft Canada | November 10, 2026

When an Existing Game Economy Becomes a Software Engineering Project

ApeLevel Gaming has been developing RAGE REALMZ, a browser-based gaming ecosystem featuring interconnected realms, player inventories, resource collection, and a trading economy managed through a system known as Whisper.

Whisper is more than a conventional in-game marketplace.

Its design involves resource ownership, transaction authorization, inventory management, settlement records, and integration with the Polygon blockchain environment.

As the system developed, ApeLevel faced a familiar challenge in software engineering: building something that works is only one part of making it reliable, maintainable, and suitable for wider public use.

That challenge led to an engineering review by Apesoft Canada, the software development company operating alongside ApeLevel Gaming under the broader ApeSoft business structure.

Apesoft’s assignment was to examine the existing Whisper Market infrastructure, assess the reliability of its recorded transactions, establish safer boundaries around public access, and develop a separate website capable of displaying market activity independently of the game.

The result was Whisper Market Live.

Public website:

https://whisper-market-live.whispermarketlive.workers.dev

By November 10, 2026, the engineering effort had reached 123 documented development steps, a regression suite reporting 21 passing tests with zero failures, and the successful deployment of a standalone market observatory.

But the significance of the project lies in what Apesoft reviewed, what it built, and what its testing actually established.

Phase One: Reviewing ApeLevel’s Existing Whisper Market

Apesoft did not begin with an empty project.

ApeLevel had already developed the foundations of Whisper’s trading economy, including the operational settlement ledger and mechanisms for recording resource transactions.

The first challenge was understanding whether the information inside that existing system could be safely and accurately presented to the public.

Consider a player purchasing Water from another player.

A transaction might have been initiated, but that does not necessarily mean it was successfully completed.

A payment record might exist without a corresponding resource transfer.

A resource identifier might appear in more than one place.

Or a settlement record might contain information inconsistent with its associated receipt.

If a public market website simply displayed every recorded transaction attempt, visitors could receive a misleading picture of actual trading activity.

Apesoft’s review therefore focused on identifying which records qualified as finalized transactions.

The engineering work examined settlement information, receipt consistency, resource-transfer identifiers, transaction status, and recorded execution prices.

The objective was to establish a reliable reporting boundary between completed trades and records that should not be presented as completed market activity.

What the review demonstrated

The implemented tests showed that the public-history extraction logic rejected several categories of inconsistent or manipulated records.

These included conflicting settlement information, mismatched Water identifiers, duplicate resource references, and incomplete transfers.

Pending or unverified transactions were excluded from the tested public-history results.

The review also confirmed that invalid newer records did not prevent older valid records from being retrieved.

These findings supported proceeding with the public reporting functionality.

They did not constitute an independent certification of the entire Whisper trading economy.

The testing established specific behaviours under specific conditions, rather than proving that every possible vulnerability had been eliminated.

That distinction shaped the next phase of development.

Phase Two: Separating Public Reporting From the Trading Engine

One of Apesoft’s most important engineering decisions was to avoid turning the public market website into another interface with operational control over the game economy.

The existing Whisper infrastructure performs functions that a public market observatory simply does not need.

A visitor checking historical Water prices should not require access to wallet authorization, resource transfers, or settlement execution.

Apesoft therefore developed a separate reporting architecture.

The public website would be able to display approved historical market data without exposing the original operational database directly or giving visitors trading authority.

This required work on both the existing game-side infrastructure and the new standalone application.

Establishing read-only access

Apesoft introduced a dedicated SQLite read-only database interface for reporting purposes.

The engineering tests confirmed that the interface could perform SELECT operations while rejecting attempted INSERT operations.

An initial isolation test failed because of the order in which a module path was resolved. The issue was corrected, and the relevant tests subsequently passed.

This is an example of why an engineering review should record problems as well as successes.

The corrected test demonstrated the intended application-level read-only behaviour.

However, Apesoft also documented an important limitation: software-level read-only restrictions do not replace proper filesystem permissions or infrastructure access controls.

The final public website uses a separate Cloudflare D1 database rather than exposing ApeLevel’s original operational SQLite database.

The architecture was deliberately designed to limit the public application’s authority.

Phase Three: Testing the Existing Infrastructure

Before deploying the new website, Apesoft carried out regression testing around the public-history functionality and associated request controls.

The combined suite reported:

21 tests passed. Zero failed.

The tests covered multiple areas of the system.

Settlement integrity: Could inconsistent receipt information or altered transaction details be accepted as valid history?

Resource-transfer integrity: Could duplicate or mismatched Water identifiers appear as legitimate completed transfers?

Transaction-state filtering: Would pending or incomplete activity be incorrectly displayed as finalized trades?

Price accuracy: Could the system preserve exact recorded tTILT prices rather than introduce misleading rounding?

Historical retrieval: Could a malformed newer record prevent valid older history from being displayed?

The observed results supported the reliability of the tested reporting implementation.

Apesoft also examined request-rate controls.

A simulated test confirmed that the original Node.js handler permitted the configured number of requests before returning HTTP 429 when the threshold was exceeded.

An inefficient rate-limit bookkeeping approach was identified and improved during development.

What these results mean

The testing demonstrated that the reviewed code behaved as expected across the implemented test cases.

It also provided evidence that several anticipated forms of invalid market data would be excluded from the public reporting output.

However, passing 21 tests does not mean the software is immune to attack.

The tests were not a comprehensive penetration test, independent third-party security audit, or mathematical proof of correctness.

Furthermore, the Cloudflare deployment uses a separate API implementation and does not automatically inherit every control tested in the original Node.js environment.

Apesoft’s report specifically identifies additional Cloudflare-side throttling as outstanding production-hardening work.

The successful review justified proceeding with a bounded public reporting deployment, not declaring the entire system perfectly secure.

Phase Four: Creating Whisper Market Live

After examining the existing infrastructure and establishing the reporting requirements, Apesoft moved from review into software development.

The new objective was to give ApeLevel Gaming a dedicated public market website.

Previously, historical trading information was primarily associated with the game’s operational environment.

The new application needed to make that information accessible even when the game server was not running.

Apesoft developed Whisper Market Live using Cloudflare Workers and Cloudflare D1.

The resulting website provides a responsive public interface for examining recorded Water transactions, prices, and market history.

It includes a historical price chart and transaction information presented separately from the gameplay interface.

This was an architectural change as much as a visual one.

The market observatory now operates independently of the game’s runtime for previously synchronized records.

That independence gives ApeLevel a foundation for public market transparency without requiring the game itself to remain online simply to display historical prices.

Recovering historical trading data

Apesoft recovered nine qualifying historical Water settlements from the original operational ledger.

The records were validated for internal consistency and imported into the separate reporting database.

The imported history represented:

• 9 recorded Water settlements
• 9 Water units
• 9.25 tTILT in total recorded settlement value

These were development-environment transactions associated with the Polygon Amoy testnet.

They should not be confused with real-money trading volume or production-token revenue.

The imported records were successfully displayed through the public market interface, including the historical Water price chart.

This demonstrated that Apesoft could extract qualifying records from ApeLevel’s existing system, prepare them for public reporting, and present them through independently hosted infrastructure.

There was, however, a remaining verification boundary.

The historical records passed the implemented local consistency checks, but independent live-blockchain revalidation of every historical receipt had not been completed.

That work remains part of the future engineering roadmap.

Phase Five: Deploying the New Website

On November 10, 2026, Apesoft completed deployment of Whisper Market Live to Cloudflare Workers.

The deployment connected the public website to its dedicated Cloudflare D1 database.

The engineering record confirmed that the public service returned HTTP 200 and that the interface displayed the imported market history.

The final deployment also included the RAGE REALMZ branding assets.

Live deployment:

https://whisper-market-live.whispermarketlive.workers.dev

The website is publicly accessible as a read-only market observatory.

Visitors can inspect previously synchronized historical trading information without needing access to the RAGE REALMZ game server.

They cannot use the public dashboard to sign wallet transactions, execute Water trades, or modify game inventories.

Why this is a meaningful development milestone

The achievement was not merely publishing a website.

Apesoft reviewed an existing operational system, developed reporting boundaries, tested the extraction of transaction history, migrated validated records into separate infrastructure, and deployed a functioning public interface.

The project demonstrates a practical software engineering workflow in which an existing application is examined and extended without unnecessarily exposing its operational authority.

It also creates a foundation for additional market functionality.

What Apesoft’s Reports Confirm — and What They Don’t

Engineering reports should help clients and users understand the evidence behind development claims.

For Whisper Market Live, the recorded results support several conclusions.

The existing market records could be reviewed and filtered. Apesoft’s implemented tests distinguished qualifying finalized settlements from several categories of invalid or incomplete activity.

A separate reporting architecture could be established. The public application operates without directly exposing the original operational SQLite database.

Historical market data could be migrated and displayed. Nine qualifying settlements were imported into D1 and shown through the deployed interface.

The public website could operate independently of the game server. Previously synchronized history remains available through the separate Cloudflare service.

The deployed system passed its recorded public regression suite. Twenty-one tests passed, with zero failures reported in that suite.

But these results also have limits.

They do not establish that the complete RAGE REALMZ economy is free of vulnerabilities.

They do not constitute an independent security certification.

They do not prove that every possible settlement manipulation has been anticipated.

They do not demonstrate continuous automatic synchronization of future transactions.

And they do not guarantee uninterrupted website availability.

The reports document a successful engineering and deployment milestone within a defined scope.

They are not claims of universal security or final product completion.

What Still Needs to Be Developed

Although Whisper Market Live is publicly deployed, Apesoft has identified several areas for further development.

Automatic market synchronization is one of the most important.

The current platform displays previously imported history. Future development must connect new qualifying settlements to the public reporting database through a controlled synchronization process.

Independent blockchain revalidation is another priority.

The historical records were checked for consistency within the existing ledger, but additional live-chain verification would strengthen the evidence supporting published settlement information.

Cloudflare-specific request protection remains part of production hardening.

The new deployment requires controls appropriate to its own hosting environment rather than relying on protections implemented in the original Node.js application.

Custom-domain activation is also unfinished, although the Cloudflare Workers address is operational.

These remaining tasks do not invalidate the successful deployment.

They define the next engineering milestones.

The Role of AI in Apesoft Canada’s Development Process

The Whisper Market project also illustrates how Apesoft Canada approaches AI-assisted software engineering.

We use large language models to assist with code generation, technical analysis, test design, troubleshooting, and documentation.

But our workflow does not give the language model unrestricted autonomous execution access to GitHub Codespaces.

Commands are reviewed and manually executed by a human operator.

Development decisions, testing, and deployments remain human-controlled.

This approach helps reduce certain risks associated with autonomous AI agents, including excessive permissions, unreviewed commands, and potentially unsafe execution.

It does not eliminate software supply-chain risks or guarantee that generated code is secure.

The engineering work still requires verification.

The Whisper Market reports demonstrate why.

During development, problems were identified, corrections were made, tests were repeated, and the final deployment was evaluated against the defined requirements.

AI accelerated the engineering process, but successful completion depended on testing and human-controlled implementation.

What This Project Represents for ApeLevel and Apesoft Canada

For ApeLevel Gaming, Whisper Market Live provides a new public-facing component of the RAGE REALMZ ecosystem.

The game economy now has a separately hosted historical market observatory that can be developed further as the underlying trading infrastructure evolves.

For Apesoft Canada, the project demonstrates the company’s role beyond conventional website design.

Apesoft’s work involved reviewing an existing software system, examining transaction records, implementing security-conscious access boundaries, building database-backed infrastructure, developing a public interface, conducting regression testing, and deploying the finished reporting application.

That combination of engineering review and new product development is central to the company’s intended services.

Not every software project begins from scratch.

Sometimes a client already has an application, a database, or an operational system that needs to be examined before additional functionality can be safely introduced.

Other times, the requirement is to build a separate application around existing infrastructure without interfering with its core operations.

Whisper Market Live involved both.

Conclusion: A Successful Review, a New Platform, and a Documented Roadmap

By the end of the November 10 engineering session, Apesoft Canada had completed a substantial review and development effort for ApeLevel Gaming.

The project reached 123 documented steps, produced 21 passing regression tests, recovered and imported nine qualifying historical Water settlements, and deployed an independent public market observatory.

The review identified and tested important transaction-reporting boundaries.

The development work produced a functioning Cloudflare-hosted application.

The deployment made historical market information publicly accessible independently of the game server.

And the engineering reports recorded both the successful outcomes and the remaining limitations.

The result is not a declaration that Whisper Market is finished or invulnerable.

It is evidence that Apesoft Canada successfully reviewed an existing game-economy system, developed a new public reporting platform around it, and deployed that platform with documented testing and clearly identified next steps.

For ApeLevel Gaming, that means a more accessible and transparent foundation for its developing economy.

For Apesoft Canada, it is a practical demonstration of how software engineering, testing, AI-assisted development, and controlled deployment can come together to extend an existing product.

The review informed the architecture. The testing supported the deployment. And the deployment created the foundation for what comes next.

Project Links

Whisper Market Live — Public Market Observatory

https://whisper-market-live.whispermarketlive.workers.dev

Apesoft Canada — Software Engineering & Development

https://apesoft.ca

Engineering source: Apesoft Canada — Whisper Market Live: Engineering Development & Security Report, November 10, 2026.

Engineering review, development, testing, and deployment by Apesoft Canada for ApeLevel Gaming’s RAGE REALMZ ecosystem.

Whisper Market Live currently operates as a read-only historical market observatory. The referenced tTILT transactions are associated with the Polygon Amoy testnet. Security findings are limited to the recorded tests and implementation scope.

By ApeLevel | November 6, 2026

Something interesting is happening in the gaming industry, and it has very little to do with the next PlayStation, the latest graphics card, or which studio can build the largest open world.

On November 4, 2026, Wendy’s released an actual role-playing video game.

Not an advertisement pretending to be a game. Not a promotional animation. An RPG.

WendyQuest: Legend of the Four Corner Stones features an original fantasy world, exploration, puzzles, turn-based battles, pixel artwork, and opportunities to unlock real Wendy’s food offers.

Wendy’s describes the game as having more than ten hours of content. It is available free on mobile devices and PC in the United States.

A fast-food company commissioned a full retro-inspired fantasy adventure to sell hamburgers.

And Wendy’s isn’t alone.

In September 2026, the White House launched an online arcade featuring five retro-style games designed to communicate political messaging through interactive entertainment.

In 2023, McDonald’s commissioned a Game Boy-style adventure for Grimace’s birthday.

KFC introduced its Rewards Arcade, connecting arcade-style games to customer loyalty and food rewards.

Chipotle created Burrito Builder on Roblox, allowing players to build virtual burritos and participate in promotions for real food.

IKEA created an interactive recruitment experience where players could explore working inside a virtual IKEA store.

Spotify built an explorable music world.

Delta Air Lines developed an arcade game for its SkyMiles members.

These companies operate in entirely different industries.

Yet they have arrived at a remarkably similar conclusion.

Video games are becoming a legitimate way for organizations to interact with the people they want to reach.

At ApeLevel, we believe the significance of this trend extends far beyond the corporations already participating in it.

Because another technological development is unfolding at precisely the same time.

The cost of creating software — including video games — is becoming increasingly susceptible to automation through artificial intelligence.

And when production costs fall far enough, the most important market opportunities are not always found among the existing customers.

Sometimes they emerge among the millions of potential customers who previously couldn’t afford the product at all.

The Wrong Way to Look at the Gaming Opportunity

When people hear that Wendy’s has commissioned a role-playing game, their first instinct might be to imagine competing for similar contracts.

Who built the game? How much did Wendy’s spend? Could a smaller studio create something comparable? Could we convince the next multinational corporation to hire us?

Those are reasonable questions.

But they aren’t the questions driving ApeLevel’s thinking.

We aren’t interested in trying to defeat established gaming studios at a business model they’ve spent decades perfecting.

We’re interested in what happens when the economics supporting that business model begin to change.

Consider the typical commercial game development arrangement.

A major corporation has a large marketing budget. It commissions a specialized agency or development studio. The studio assigns artists, programmers, designers, sound specialists, producers, and testers. Months or years later, the company receives its finished branded experience.

That model works for corporations with substantial budgets.

It doesn’t work particularly well for the independent restaurant, local fitness studio, neighborhood retailer, or small tourism operator.

Those businesses generally don’t commission video games because traditional development costs are difficult to justify against their available marketing budgets.

But what if the cost of production falls substantially?

What if a small development operation can accomplish work that previously required a much larger team?

What if the underlying software can be reused, modified, and customized rather than rebuilt for every customer?

Suddenly, the business opportunity looks quite different.

The objective is no longer to convince major corporations to choose a smaller game studio. It’s to make games affordable for businesses that never considered purchasing one.

That’s the market we’re interested in.

We’ve Seen This Economic Pattern Before

There is an important connection between the history of website development and what may be emerging in commercial game development.

In the early years of the commercial internet, building a professional website could require considerable technical expertise and financial investment.

A business often needed someone who understood programming, servers, databases, web design, and deployment.

As web development tools improved, production became increasingly standardized.

Content management systems, templates, hosted website builders, and eventually AI-assisted tools dramatically expanded the number of people capable of creating and maintaining websites.

The economic result was not simply that existing website developers could build cheaper websites.

It was that an entirely new customer base became viable.

Businesses that would never have commissioned an expensive custom website could suddenly establish an online presence.

Today, even the smallest business can reasonably be expected to have a website.

And that leads us to a question:

Could branded video games eventually follow a similar path?

Not because every small business needs an elaborate RPG.

But because a small business might benefit from a simple game in much the same way it benefits from a promotional video, website, social media campaign, or customer loyalty program.

Imagine a restaurant with a mascot customers can play as.

A coffee shop with a two-minute arcade challenge that unlocks a discount.

A fitness studio where customers compete on a branded obstacle-course leaderboard.

A tourism company that introduces its attractions through a playable adventure.

A local retail business where customers collect virtual items associated with seasonal products.

None of these concepts requires a major game publisher.

They require functional gameplay, engaging presentation, a clear commercial purpose, and production economics that make sense for the customer.

This is where we believe AI-assisted development can become genuinely disruptive.

AI Doesn’t Have to Replace Game Studios to Change the Industry

The conversation surrounding artificial intelligence and game development is frequently framed as a conflict between human creativity and automation.

Will AI replace artists? Will developers lose their jobs? Will computer-generated content destroy creative originality?

Those questions deserve serious consideration.

But they are not the entire economic picture.

A technological improvement can change an industry by making its products accessible to people who were previously excluded from the market, even when the established providers remain valuable.

In April and May 2026, Morgan Stanley published research estimating that AI could reduce game production costs by more than 40%, potentially creating approximately $22 billion in additional industry profits through improved production efficiency.

The projection reflects industry-wide potential, not a guaranteed saving for any particular development project.

Nevertheless, the implications are significant.

If AI allows smaller development teams to produce useful software faster and at lower cost, the industry may gain more than higher profit margins.

It may gain entirely new customers.

The 2026 Game Developers Conference State of the Game Industry report found that 36% of surveyed game industry professionals were using generative AI in their work.

Among those users, research, coding assistance, and prototyping were common applications.

The same report found substantial skepticism toward generative AI within the industry, including concerns about its effects on employment and creative work.

That skepticism shouldn’t be ignored.

But the commercial argument we’re making does not require every developer to embrace AI or every major studio to abandon traditional production.

It requires a more limited development:

A sufficiently large reduction in the effort needed to produce smaller, commercially useful games.

ApeLevel’s opportunity sits at that intersection.

Wendy’s May Have Demonstrated More Than It Intended

One detail about WendyQuest makes this especially interesting.

According to Wendy’s own November 4 announcement, the game was developed by hand over several years in collaboration with 81 Monkeys.

Wendy’s specifically emphasized that it was not built using AI shortcuts.

And there’s nothing wrong with that.

Traditional game development is an established creative discipline, and a handcrafted game can be an excellent product.

But from ApeLevel’s perspective, the more interesting question isn’t whether AI could have produced WendyQuest.

It’s whether AI-assisted development could make smaller variations of this commercial concept affordable to businesses operating on a fraction of Wendy’s budget.

Wendy’s has demonstrated a use case.

AI may eventually help make variations of that use case accessible to a much wider market.

The distinction is important.

We don’t need to build a ten-hour adventure for every restaurant.

A simple, well-designed game with fifteen minutes of replayable entertainment might be sufficient.

The game might cost considerably less to develop, be easier to maintain, and accomplish exactly what the business needs.

A smaller business doesn’t necessarily need the most sophisticated technology.

It needs an appropriate product at a justifiable price.

The Most Important Feature Might Not Be the Game

Here’s where the market becomes even more interesting.

What exactly is a restaurant purchasing when it commissions a branded game?

Is it buying entertainment?

Partly.

But from a commercial perspective, the game may be functioning as something else entirely.

It’s buying customer attention.

It’s buying an opportunity for customers to interact with the brand voluntarily.

It’s potentially buying repeat visits, promotional participation, and new ways to reward loyalty.

Consider the difference between two advertising experiences.

In one, a customer sees a restaurant advertisement for a few seconds before scrolling past it.

In the other, the customer chooses to spend several minutes playing an entertaining game featuring that restaurant’s characters, products, and branding.

Those experiences aren’t economically identical.

Traditional advertising interrupts an existing activity to deliver a message.

A branded game attempts to make interacting with the business an activity people actually want to undertake.

That doesn’t guarantee purchases or customer loyalty. Poor games can be ignored just as easily as poor advertisements.

But the potential is significant.

And there is already evidence that well-executed gaming campaigns can generate substantial participation.

According to the Interactive Advertising Bureau’s Metaverse for Brands Guide, Chipotle’s Burrito Builder recorded more than one million gameplays in under 24 hours and distributed 100,000 promotional codes in approximately 30 minutes.

IKEA reported more than 178,000 applications for ten paid virtual positions associated with its 2024 Roblox initiative.

These are corporate-scale campaign results, not forecasts for smaller businesses.

The key observation is that gameplay can become the delivery mechanism for another commercial objective.

And once we understand that, we can begin designing games around the business outcome instead of simply adding business branding to a game.

The Missing Market Between a Website and a Video Game Studio

Today, a small business owner can purchase a website, hire a photographer, commission a promotional video, establish online booking, and run targeted advertisements.

All of these services have become familiar components of small-business marketing.

But ask that same owner whether they have considered commissioning a video game.

For most, the idea would sound excessive.

Not necessarily because a game wouldn’t be useful.

Because they would assume it was expensive.

That assumption has historically been reasonable.

ApeLevel’s thesis is that it may become increasingly outdated.

As AI-assisted development improves and game components become reusable, we believe a new category of service could emerge.

Not a major game studio.

Not a generic website builder.

But an affordable provider of custom-branded interactive entertainment for small and medium-sized businesses.

The service might be as straightforward as developing a mobile-friendly browser game that runs directly from the customer’s existing website.

No expensive gaming console.

No specialized hardware.

No requirement for a customer to understand cryptocurrency, create a digital wallet, or install a complicated application.

Just a business, its customers, and a game designed around a useful commercial objective.

This is particularly attractive because web-based delivery can use infrastructure businesses already understand: websites, hosting, domains, analytics, and optional customer accounts.

The challenge becomes less about inventing an entirely new distribution industry and more about adding another useful service to the digital business ecosystem.

What We’re Learning at ApeLevel

Our perspective is informed by our ongoing development work.

Through RAGE REALMZ, ApeLevel has been working on a browser-based gaming environment involving player identities, persistent progression, inventories, resource management, marketplace interactions, and blockchain-related systems.

It’s an ambitious technical undertaking.

And developing those systems forces us to think carefully about what actually needs to be built, what can be reused, and what complexity can be eliminated.

Those lessons have applications beyond one game.

For example, a robust player-progression system might eventually be adapted into a fitness challenge.

A leaderboard system might be useful in a promotional arcade game.

A verified inventory concept might inform how a loyalty application tracks rewards, although consumer-facing rewards would generally be better served by conventional databases rather than blockchain transactions.

An administrative dashboard might be repurposed for a business owner who wants to manage a promotional campaign.

These aren’t claims that we have already commercialized every one of those systems.

They are examples of how reusable software architecture can create opportunities beyond the original application.

And that leads to another important economic connection.

The real savings may come from what you don’t have to build twice.

AI assistance is one part of the equation.

Software reuse is another.

If a development team creates every game from scratch, each new customer adds substantial production work.

But if the team owns reliable, reusable gameplay components, future projects can draw from an existing foundation.

A new client may require different characters, artwork, rewards, difficulty settings, and branding without requiring an entirely new game engine or account system.

Over time, this could reduce both development costs and delivery times.

The long-term advantage wouldn’t simply come from knowing how to use AI.

It would come from combining AI-assisted production with an increasingly valuable library of proven components.

That is a business model worth exploring.

We Don’t Need a Million Players

Another assumption deserves examination.

A major corporation might measure the success of a gaming campaign through millions of impressions, enormous player counts, and international media coverage.

But those numbers may be irrelevant to a small-business customer.

A neighborhood restaurant doesn’t need a million players.

It might need a few hundred local customers to engage with a promotion.

A fitness studio doesn’t need a global multiplayer community.

It might need fifty members participating in a monthly challenge.

A tourism operator doesn’t need to build the next worldwide gaming franchise.

It might simply want prospective visitors to explore its attractions interactively before booking.

The appropriate scale depends on the customer’s actual business.

This changes how the product should be designed, priced, and evaluated.

We’re not trying to manufacture blockbuster entertainment properties for every client.

We’re exploring small, practical games that can deliver value at small-business scale.

For some businesses, a game will make no commercial sense at all.

For others, it could become a useful differentiator.

The next step is determining which businesses benefit, what they would realistically pay, and whether those projects can be produced and maintained profitably.

That’s a market-validation question, not something that can be answered through technological optimism alone.

A Game Could Become a Business’s Digital Mascot

There’s another connection we find particularly interesting.

Many businesses have recognizable branding, but very little opportunity to bring it to life.

They have logos, colors, slogans, and occasionally mascots.

Yet much of that identity remains static.

Games offer a different possibility.

A mascot doesn’t need to remain a picture on a sign.

It can become a playable character.

A restaurant’s fictional world could become a setting customers explore.

A local company’s history could become an interactive story.

A fitness brand could turn its challenges into levels, achievements, and competitions.

This creates an opportunity to develop something businesses have traditionally associated with much larger entertainment brands: recognizable characters and interactive experiences that customers remember.

McDonald’s demonstrated the power of existing brand characters with Grimace’s Birthday.

Wendy’s has now taken its own familiar brand identity into a fantasy role-playing environment.

For smaller businesses, the opportunity could be simpler.

Give an otherwise static brand something customers can interact with.

A well-designed game could make a brand feel more distinctive without requiring an enormous advertising campaign.

And unlike a conventional advertisement, the experience can potentially remain available on the business’s website long after its initial promotion.

That continuing availability introduces an opportunity for repeated engagement, although maintaining players’ interest would still require good design and appropriate updates.

Why This Is Not an Attack on Traditional Game Development

The emergence of smaller, AI-assisted development operations doesn’t mean traditional studios have become obsolete.

Large game productions involve enormous creative, technical, operational, and artistic challenges.

Experienced developers remain essential to solving complex problems, building reliable systems, and creating compelling entertainment.

AI-generated content also raises legitimate questions about copyright, consent, consistency, security, and the professional treatment of creative workers.

Those concerns shouldn’t be dismissed just because automation creates commercial opportunities.

But an affordable product doesn’t necessarily have to replace an expensive one.

Sometimes it serves a completely different customer.

A local business purchasing a modest browser game is not necessarily choosing between ApeLevel and a major game studio.

In many cases, the realistic alternative may be purchasing no game at all.

That is the distinction behind our strategy.

We’re not necessarily trying to take work away from the established industry.

We’re interested in whether a lower-cost development model can make previously uneconomical projects viable.

The opportunity isn’t only to compete for existing demand. It’s to unlock demand that existing prices have kept out of the market.

The Next Small Business Website Might Have a Play Button

We don’t believe every business will need a custom game.

We do believe that making games easier and less expensive to produce could change how businesses think about interactive marketing.

There was a time when online video production was a specialized, expensive service.

Today, businesses routinely use video across websites, advertising, and social media.

There was a time when professional websites were technically intimidating and financially inaccessible to many independent businesses.

Today, they are ordinary commercial infrastructure.

Game production may be moving toward a similar economic transition.

Not because developing a great game has suddenly become effortless.

But because the minimum resources required to develop a useful, limited-scope game may continue to fall.

That creates room for an entirely different category of customer.

At ApeLevel, that’s the future we find interesting.

A small restaurant shouldn’t need a multinational corporation’s marketing budget to let customers play a branded arcade game.

A gym shouldn’t need to hire a conventional game studio to offer a digital fitness challenge.

A local retailer shouldn’t need an entertainment division to experiment with interactive promotions.

And a business owner shouldn’t need to understand complex software architecture to commission something engaging for customers.

If AI-assisted production and reusable game systems can make those experiences sufficiently affordable, the potential customer base could expand dramatically.

Of course, accessibility alone doesn’t establish demand.

We still need to prove that smaller businesses want these products, that customers will engage with them, and that the economic returns justify the investment.

But the direction of the opportunity is becoming increasingly clear.

Wendy’s is building fantasy worlds to promote hamburgers.

McDonald’s brought Grimace into a video game.

Chipotle turned preparing burritos into an interactive promotional experience.

IKEA transformed recruitment into virtual gameplay.

Even the White House has experimented with games as a communication medium.

These are different organizations pursuing different objectives.

The common thread is that they see value in making their message interactive.

Now consider what happens when that capability no longer requires a corporate-sized budget.

That’s the opportunity ApeLevel is positioning itself to explore.

Not the next $100 million game.

Not the next blockbuster franchise.

The next restaurant, fitness studio, retailer, tourism company, or independent business that realizes its customers might actually enjoy pressing Play.

Because the future of commercial gaming may not belong exclusively to the companies that can afford the biggest games.

It may also belong to the businesses that can finally afford a game at all.

Research and Sources

The following sources support the industry examples and economic discussion. The small-business opportunity described in this article is ApeLevel’s strategic thesis, not an established forecast of customer demand.

1. Wendy’s — WendyQuest: Legend of the Four Corner Stones, November 2026.
2. Wendy’s — WendyQuest Development and Release Announcement, November 4, 2026.
3. McDonald’s — Grimace’s Birthday Campaign, June 2023.
4. Chipotle — Burrito Builder on Roblox, April 2022.
5. IKEA — The Co-Worker Game, June 2024.
6. Spotify — Spotify Island, May 2022.
7. Delta Air Lines — Sky Hopper, October 2024.
8. KFC — Rewards Arcade.
9. Associated Press — White House Launches Five Retro Arcade Games, September 2026.
10. Interactive Advertising Bureau — Metaverse for Brands Guide, November 2022.
11. Morgan Stanley — The $22 Billion Profit Opportunity in AI and Gaming, May 2026.
12. Game Developers Conference — 2026 State of the Game Industry, January 2026.

Published from the perspective of ApeLevel, an independent development initiative exploring browser-based entertainment, interactive digital experiences, and AI-assisted software production.

Suggested Medium tags: Artificial Intelligence, Game Development, Small Business, Entrepreneurship, Marketing

Cloudflare Workers, persistent databases, authenticated administration, AI integration, and production verification — the engineering behind a white-label application delivery.

By ApeLevel Engineering | November 6, 2026

There is a significant difference between building a chatbot that looks functional and engineering an application that a business can actually operate.

A chatbot demonstration might need little more than a text field, a Send button, and a connection to a language model.

A deliverable business application requires considerably more.

Where does its information come from? Who decides whether that information is accurate? What happens when a third-party API fails? How are administrator credentials protected? Where are decisions stored? Can the application continue operating when the developer closes their laptop?

And perhaps most importantly: Can the development team demonstrate which parts of the system actually work, rather than simply claiming the application is finished?

Over a concentrated 48-hour development period, ApeLevel provided SkuxxBuilds with the engineering infrastructure necessary to move a conversational AI application beyond the prototype stage.

The assignment covered serverless deployment, persistent data storage, administrator authentication, source-controlled knowledge approval, AI service integration, application security, production debugging, and release verification.

The client and its commercial strategy remain confidential. This article concerns the engineering work ApeLevel delivered to SkuxxBuilds, not the identity or operations of the underlying customer.

The problem wasn’t building a chatbot

The original application already had the beginnings of a customer-facing conversational interface.

What it lacked was the infrastructure required to support it as a dependable, independently hosted service.

A demonstration can return a predefined response and still appear functional. An application intended for business use has to manage real requests, authentication, persistent state, third-party failures, and the possibility that its underlying information may be incorrect.

ApeLevel’s responsibility was to address those engineering requirements while allowing SkuxxBuilds to retain ownership of the customer relationship and delivery process.

The work was organized around five practical objectives: establish permanent hosting, separate public and administrative access, build a controlled information-approval system, prepare the OpenAI integration, and verify the resulting deployment.

1. Moving from a local prototype to Cloudflare Workers

The first major infrastructure decision was to move application execution away from a temporary local development environment.

GitHub Codespaces provides an excellent environment for software development, but a customer’s application should not depend on a particular development session remaining open.

ApeLevel implemented a Cloudflare Workers architecture to provide an independently hosted execution environment.

The deployed system separates several responsibilities:

Architecture layerEngineering purposeBrowser interfaceDisplays conversations and submits customer questionsCloudflare WorkerHandles HTTP requests and application routingCloudflare D1Stores structured application and authorization recordsAuthentication modulesProtects administrative access and sessionsOpenAI adapterPrepares authorized knowledge and processes model responsesGitHubPreserves source code and release history

This architecture allows the customer-facing application to operate independently of the development computer.

The public homepage and application stylesheet were integrated into the Worker build, and successful production requests were subsequently verified over HTTPS.

The result was a deployed web application, not simply a local preview.

2. Building a persistent data layer

A conversational interface is only one component of a system that manages approved business information.

The application also needed to retain source material, administrator decisions, historical records, and authentication state.

ApeLevel implemented this through Cloudflare D1.

The database architecture included separate tables for source claims, authorization decisions, audit events, administrator sessions, and login-attempt restrictions.

Each component serves a distinct purpose.

Source records preserve the information presented for review. Decision records establish what an authorized administrator accepted or rejected. Audit events provide an additional historical record of administrative activity.

Authentication sessions and failed-login records are maintained separately from customer-facing information.

During development, ApeLevel also resolved differences between local SQLite workflows and Cloudflare’s hosted D1 execution environment, including import and migration behaviour.

The practical achievement was persistent, structured state that survived independently of the development environment.

3. Giving the customer control over AI knowledge

One of the most important design decisions involved the relationship between website information and AI-generated answers.

It is technically possible to collect information from a website and immediately supply it to a language model.

That does not necessarily make the information appropriate for a business to publish through its own AI assistant.

A statement might be outdated, incomplete, incorrectly extracted, or simply not something the customer has authorized the system to repeat.

ApeLevel therefore developed a review-first knowledge architecture.

Source material could be collected and prepared for inspection, but it would not automatically become approved AI knowledge.

Each review record was designed to preserve supporting evidence, including the exact quotation, original source, webpage title, direct URL, collection timestamp, and previous quotation where applicable.

An administrator could then independently decide whether to accept or reject that information.

Only approved material would become eligible for use by the AI receptionist.

Pending and rejected material would remain excluded.

Why preserve the original source?

Because an approval record should document what was actually reviewed.

If the underlying website changes later, the system needs to distinguish between the original approved statement and a newer version requiring separate review.

ApeLevel implemented database constraints and triggers to prevent ordinary application workflows from modifying or deleting historical decision records.

The decision API also uses transactional database operations to associate an authorization decision with its corresponding audit event.

These measures support accountability and historical traceability. They do not make the underlying database immune to privileged infrastructure-level changes.

The design principle is straightforward: discovering information is not the same as authorizing an AI to repeat it.

4. Engineering a separate administrative environment

The system required an administrative interface, but that interface could not simply be part of the publicly accessible chatbot.

ApeLevel implemented separate public and administrative routes, supported by password authentication and database-backed sessions.

The security architecture included:

• bcrypt password verification;
• cryptographically generated session tokens;
• SHA-256 session identifiers stored in the database;
• secure, HttpOnly, SameSite cookies;
• expiring and revocable sessions;
• CSRF token verification and renewal;
• origin checks for state-changing requests;
• failed-login tracking and temporary lockouts.

A randomized administrator entrance was also implemented as an additional measure against casual discovery.

However, a difficult-to-guess URL is not authentication. The actual protection remains the verified administrator session and authorization controls.

Testing the access boundaries

ApeLevel tested multiple unauthorized access scenarios, including missing credentials, invalid sessions, forged cookies, and incorrect login credentials.

Production route checks verified that the private entrance responded successfully, the predictable login page was unavailable, and the dashboard rejected unauthenticated visitors.

A subsequent administrator login was confirmed successful.

The tests demonstrated that the specified controls behaved as expected.

They were not represented as an independent penetration test or a universal guarantee against security vulnerabilities.

5. Connecting the application to OpenAI

Once the application infrastructure and knowledge controls were established, ApeLevel implemented the AI integration layer.

Rather than placing an API key in public-facing JavaScript, the application sends customer questions to a server-side endpoint.

That endpoint is designed to retrieve approved information from the database, assemble an authorized reference context, communicate with OpenAI’s Responses API, and return the generated text to the browser.

The initial integration uses GPT-4.1 mini.

A typical request follows this sequence:

Customer question → input validation → request-rate protection → approved knowledge retrieval → OpenAI request → response extraction → browser reply

The AI instructions require the assistant to work from approved information, avoid unsupported claims, communicate uncertainty, and direct users to the business when sufficient verified information is unavailable.

External source content and customer questions are treated as data rather than trusted system instructions.

Handling service failures

Third-party APIs do not always respond successfully.

ApeLevel implemented a 15-second timeout and controlled error handling for unavailable or unsuccessful OpenAI responses.

The public interface can display an appropriate fallback instead of exposing internal errors or leaving the visitor waiting indefinitely.

Simulated integration tests verified successful model-response parsing and expected behaviour when the upstream service failed.

An important qualification

At the end of the development window, the OpenAI integration code was deployed, and its simulated success and failure pathways had been tested.

However, live paid inference remained pending because API billing had not been successfully activated.

The application also required authorized knowledge approvals before it could generate answers from customer-approved information.

ApeLevel did not represent simulated integration testing as proof that paid AI responses were already operating in production.

That is an essential difference between engineering readiness and final service acceptance.

6. Introducing operational safeguards

Publicly accessible AI applications introduce risks that ordinary demonstration software may never encounter.

A visitor may submit repeated requests, trigger unnecessary third-party API usage, or attempt to exploit administrative functionality.

ApeLevel implemented initial public request-rate protection through Cloudflare, together with input validation, controlled error responses, and server-side credential handling.

The rate-limit configuration established an initial threshold of ten requests per minute per visitor identifier.

This provides a first layer of protection against excessive requests. It is not a substitute for provider billing limits or ongoing usage monitoring.

For administrative operations, the system maintains separate login-attempt restrictions and session controls.

The objective was to provide practical safeguards without making the infrastructure unnecessarily complex for a small-business application.

7. Debugging the issues that appeared during deployment

Infrastructure development rarely follows a straight line from writing code to publishing a website.

This engagement involved several issues that required direct investigation.

Cloudflare build compatibility

The Worker entry point and module configuration required adjustments before the application could be bundled correctly.

ApeLevel corrected the module structure and verified the resulting build.

Database migration differences

Hosted D1 did not accept certain transaction-wrapper conventions used in the local SQL workflow.

The import process was adapted, and successful execution was verified.

Missing application routes

The initial Worker did not serve the public homepage.

ApeLevel connected the existing interface to the correct route instead of rebuilding it unnecessarily.

Missing styling assets

The public interface depended on a stylesheet that was not initially being served by the Worker.

The stylesheet was bundled and delivered with the correct content type.

HTTPS provisioning

The newly created deployment address initially produced a browser-level secure-connection error.

Network diagnostics subsequently confirmed successful TLS negotiation, valid certificate verification, and working HTTPS delivery.

Development proxy authentication

The local development preview used an HTTPS forwarding address that differed from the Worker’s internal origin.

That mismatch caused the security layer to reject legitimate development requests.

The issue was isolated through request-status testing, and a development-specific origin exception enabled local verification.

That exception remained a documented item for removal before final security sign-off.

Verification instead of assumptions

These were not abstract improvements inferred from source code.

The engineering process repeatedly used HTTP responses, database checks, test output, and deployment results to establish whether each change had the intended effect.

The ability to identify a failure, isolate its cause, correct it, and verify the result was a substantial part of the delivery.

8. Preserving the work through version control

The completed application needed to remain maintainable after the development session ended.

ApeLevel organized the implementation within a GitHub repository, including the Worker, security modules, database migration files, AI integration, and automated test code.

Before the release checkpoint was pushed, local development files and sensitive data were excluded from version control.

A pre-commit scan inspected 58 candidate files without identifying matches to the specified credential patterns.

The completed engineering checkpoint was successfully committed and pushed to the primary branch.

The repository and deployment identifiers are deliberately omitted from this article to preserve the confidentiality of the specific client installation.

9. What was actually delivered within 48 hours?

The development window produced a substantial application foundation.

CapabilityVerified resultIndependent cloud hostingPublic application deployed successfullyHTTPS availabilityValid certificate and successful production requestsPersistent databaseHosted relational records configured and verifiedAdministrator securityProtected access and successful login confirmedKnowledge approval architectureReview, decision and audit mechanisms implementedOpenAI integrationServer-side integration deployed and simulated-testedRequest resilienceAPI timeout and controlled failure handling implementedSource-control deliveryEngineering checkpoint committed and pushed

The work did not establish that every operational requirement had been completed.

Live paid AI inference, final customer authorization of source information, and additional acceptance and hardening activities remained outstanding.

The report therefore distinguishes between infrastructure delivered, functionality tested, and features awaiting activation.

10. Why this matters for smaller businesses

Historically, custom software projects involving databases, secure administrative systems, hosted application infrastructure, and AI integrations could require substantial development budgets.

Modern tooling is reducing some of those barriers.

Cloudflare Workers, managed databases, established authentication techniques, modern JavaScript tooling, and hosted AI APIs make it possible to construct sophisticated application foundations without operating a traditional fleet of servers.

But lower infrastructure costs do not eliminate engineering responsibility.

Someone still has to design how information is authorized, how sessions are protected, how failures are handled, how records are preserved, and how the application is tested before release.

That is the engineering layer ApeLevel supplied to SkuxxBuilds.

11. A white-label engineering collaboration

This delivery also illustrates a practical model for smaller digital businesses.

SkuxxBuilds manages its customer-facing work and commercial relationships.

ApeLevel provides specialized engineering support behind the application.

That division allows a digital services business to pursue more technically demanding projects without necessarily building every infrastructure capability internally.

ApeLevel’s contribution was not the client’s business concept or customer strategy.

It was the implementation of cloud infrastructure, persistent data systems, access controls, governed AI integration, testing, and deployment procedures.

The client remains confidential because the purpose of this article is to describe the capability delivered, not to use the customer’s identity as a marketing asset.

12. The next stage

The next milestone is completing the remaining acceptance conditions.

An authorized representative must review the relevant knowledge records and decide which information is approved.

AI provider billing must become operational, allowing a genuine model request to be tested against approved content.

The team must then verify response quality, unsupported-question handling, operating costs, and remaining production-security requirements.

Those activities are separate from the foundational engineering already completed.

The architecture is designed to support them without rebuilding the application from the beginning.

Conclusion: 48 hours, measured by what can be verified

The most useful result of this engagement was not simply that a chatbot appeared on a webpage.

Within a concentrated 48-hour engineering window, ApeLevel supplied SkuxxBuilds with a deployed application foundation incorporating cloud execution, persistent records, protected administration, source-governed information, AI integration, and reproducible technical checks.

The work demonstrates what a small engineering collaboration can accomplish when modern infrastructure is combined with disciplined implementation and verification.

It also illustrates an important standard for AI application delivery:

A product should not be described as fully operational merely because its interface looks finished.

Infrastructure, authorization, resilience, integration, and observed behaviour all contribute to whether a business can rely on the system.

For ApeLevel, those engineering responsibilities are the work behind the interface.

And for SkuxxBuilds, they provide a stronger technical foundation for delivering custom digital applications to its customers.

Written by ApeLevel Engineering.

ApeLevel provides software engineering, application infrastructure, and technical development support for independent digital projects and white-label collaborations.

This article describes an anonymized engineering engagement. It does not identify the end customer, disclose confidential business strategy, reveal administrator access information, or claim independent security certification. Functional AI activation remained subject to the outstanding requirements identified above.

Inside ApeLevel’s 103-step development process: cryptographic voting, permanent usernames, historical blockchain reconstruction, and a competitive leaderboard — all designed around free-tier infrastructure.

By ApeLevel Gaming & Branding — Senior Software Engineering
November 4, 2026 | Software Engineering, Blockchain Infrastructure & Web3 Development

Engineering a Governance Platform Without Passing Infrastructure Costs to the Client

At ApeLevel Gaming & Branding, we believe that developing blockchain-integrated software should not automatically require expensive servers, monthly infrastructure subscriptions, commercial indexing platforms, or proprietary backend services.

This philosophy was central to our development of PARLAY Governance, a custom blockchain-integrated application commissioned for Skuxx and the PARLAY community.

Following a development program documented across 103 steps, ApeLevel successfully deployed a platform combining cryptocurrency wallet authentication, token-weighted governance, permanent player identities, historical blockchain verification, and a public prediction leaderboard.

But the application itself is only part of the engineering story.

One of our primary objectives was to develop and maintain PARLAY using infrastructure that could operate without recurring hosting or blockchain-data subscription charges to the client.

Instead of provisioning a continuously running virtual private server, paying for a dedicated database host, or purchasing a commercial blockchain indexing service, ApeLevel designed the application around services with free usage allowances.

Our infrastructure combines:

• GitHub Codespaces for cloud-based software development.
• Cloudflare Workers for application hosting and server-side execution.
• Cloudflare D1 for persistent database storage.
• GitHub Actions for scheduled blockchain verification and background processing.
• Robinhood Chain’s public RPC for blockchain data retrieval.

This architecture is intended to keep PARLAY’s routine infrastructure costs at $0 under applicable free-tier allowances and ordinary usage conditions.

That qualification matters: these services have limits, and costs or service interruptions may arise if quotas are exceeded, plans change, or additional paid capacity becomes necessary. The architecture does not require the client to purchase those services simply to maintain the currently deployed application at a modest scale.

The result is a functioning governance platform designed for low operating costs without compromising the distinction between blockchain verification, authenticated voting, and independently authorized wager execution.

Live application: https://parlay.apelevel.workers.dev

Public source code: https://github.com/apelevel/parlay

1. What ApeLevel Built

PARLAY Governance operates on Robinhood Chain and uses the PARLAY ERC-20 token to determine weighted governance participation.

The platform allows holders to connect compatible wallets and submit gasless, cryptographically signed votes.

It also provides eligible participants with a permanent username-registration system and introduces a public leaderboard designed to recognize consecutive correctly predicted wager outcomes.

The main capabilities include:

Cryptographically authenticated voting. Participants authorize their votes using signatures generated by their connected wallets.

Closing-block voting weights. Voting influence is calculated from PARLAY ownership at a defined historical blockchain block rather than simply relying on the balance displayed when a ballot was submitted.

Permanent usernames. Wallets holding at least 1,000 PARLAY can register unique player identities, protected by case-insensitive database constraints and signed registration evidence.

Deferred blockchain verification. Requests encountering RPC rate limits can enter a processing queue instead of being automatically rejected.

Public voting evidence. The application provides mechanisms for presenting finalized voting records and independently examinable proof data.

PARLAY Streak Leaderboard. Registered participants can be ranked according to consecutive correct predictions once the relevant real-world outcomes have been authoritatively confirmed.

Together, these capabilities establish a bridge between cryptocurrency ownership, community participation, and persistent player reputation.

Importantly, the voting system does not require holders to transfer custody of their PARLAY tokens to the application merely to participate.

2. Why We Chose GitHub Codespaces Instead of Maintaining a Development Server

Conventional software development often involves maintaining local development environments, dedicated servers, or specialized hosted infrastructure.

ApeLevel selected GitHub Codespaces because it provides a development environment accessible directly through a browser.

This allowed our engineers to work with the PARLAY repository, run Node.js commands, execute TypeScript builds, develop Cloudflare Worker APIs, test database migrations, and deploy application updates without requiring a permanently running development machine.

GitHub Codespaces provides included compute and storage allowances for eligible personal accounts.

For example, GitHub currently documents monthly free allowances for individual accounts, with the applicable amount depending on the account plan. These allowances are not unlimited, and organization-owned development usage may have different billing rules.

The important engineering distinction is that Codespaces is a development environment, not PARLAY’s production server.

Once the application is deployed, the public website continues operating through Cloudflare even when the development environment is stopped.

This means the client does not need to fund a continuously running Codespace simply to keep the governance website online.

It also allows ApeLevel to reduce unnecessary development compute consumption by stopping inactive environments.

Why this matters commercially

By separating development infrastructure from production hosting, ApeLevel avoided creating a permanent operational dependency on a paid development machine.

The application can be maintained through repository-based updates rather than an always-running developer workstation.

That reduces operating overhead and helps prevent development convenience from becoming a recurring cost imposed on the client.

3. Cloudflare Workers: Hosting Without a Dedicated Server

One of PARLAY’s most consequential architectural decisions was to use Cloudflare Workers.

Traditional applications often require a dedicated backend server running around the clock.

That introduces costs for compute resources, system administration, software updates, monitoring, and infrastructure availability.

PARLAY instead deploys its frontend assets and backend request handlers through Cloudflare’s serverless infrastructure.

When a participant connects a wallet, requests a username, submits a signed ballot, or retrieves the leaderboard, the application uses the appropriate web and backend services without requiring ApeLevel to maintain a traditional dedicated server.

Cloudflare’s free Workers plan currently provides a substantial daily request allowance, subject to execution and resource limits.

For a developing governance community operating at modest traffic levels, this creates an opportunity to run the website without separate hosting charges.

The deployment also uses Cloudflare’s scheduled triggers for recurring application maintenance.

The practical result is that Skuxx does not need to rent a dedicated server merely to host PARLAY Governance.

There is no requirement for a continuously running VPS, paid container host, or conventional application-server subscription under the current architecture.

The limitation is that free-tier Workers are subject to request, CPU, and other resource quotas. If future activity exceeds those limits, the application may require optimization, reduced workloads, or a different hosting plan.

We designed the system to minimize that possibility, not to pretend infrastructure capacity is infinite.

4. Cloudflare D1: Persistent Records Without a Conventional Database Subscription

A governance application cannot operate reliably using frontend state alone.

It needs durable records of proposals, voting options, wallet signatures, accepted ballots, registered usernames, verification states, and finalized results.

ApeLevel implemented these records using Cloudflare D1.

D1 provides a serverless SQL database integrated with the Cloudflare Workers environment.

PARLAY uses the database to preserve information such as:

• Proposal creation and closure records.
• Signed voting ballots.
• Historical voting-weight calculations.
• Username ownership records.
• Registration nonces and proof receipts.
• Pending verification requests.
• Processing leases and retries.
• Confirmed prediction outcomes.
• Public leaderboard data.

A key engineering advantage is that the application does not need a separately hosted SQL server operating continuously.

D1’s free plan includes database storage and daily query allowances appropriate for development and smaller-scale applications.

Cloudflare currently documents free-tier limits that include millions of daily rows read and a bounded number of rows written.

These limits provide considerable flexibility for a platform at PARLAY’s present development stage.

However, D1 does impose quota enforcement. If the account exceeds its free read, write, or storage limits, operations may fail until those limits reset or capacity is increased.

ApeLevel’s position is therefore that D1 can support PARLAY without recurring database charges under present-scale assumptions, not that the service provides unlimited free storage or processing.

This distinction is part of responsible infrastructure planning.

5. Our Most Significant Challenge: Historical Blockchain Data

During development, ApeLevel encountered an issue that went beyond ordinary website construction.

PARLAY’s voting methodology requires token ownership to be measured at a specific historical blockchain snapshot.

The governing rule is:

One PARLAY token equals one unit of voting weight at the proposal’s closing block.

A holder who submits a ballot while owning 10,000 PARLAY and subsequently increases their holdings to 50,000 before the deadline may be entitled to 50,000 units of closing-snapshot weight.

Conversely, a holder who transfers tokens away before closing may receive less weight.

This means the application cannot safely substitute a participant’s current balance for their historical balance.

Unfortunately, Robinhood Chain’s public RPC infrastructure did not consistently make the necessary historical ERC-20 contract-state information available.

Some historical block data could be retrieved, while historical token-balance queries failed because the requested contract state was unavailable.

This presented two alternatives.

We could abandon the historical voting methodology, or we could develop a different way to reconstruct the relevant information.

ApeLevel chose the latter.

Reconstructing historical ownership

Our engineers developed a transfer-based balance reconstruction mechanism.

The process begins with a known later token balance and examines relevant ERC-20 Transfer events occurring after the governance deadline.

Incoming transfers are reversed.

Outgoing transfers are added back.

The result is a reconstructed balance for the historical closing block.

Mathematically:

Closing balance = Later reference balance − subsequent incoming transfers + subsequent outgoing transfers.

For example:

A wallet holds 15,000 PARLAY at a later reference block.

Following the proposal’s deadline, the wallet received 8,000 PARLAY and sent 3,000 PARLAY elsewhere.

Its historical balance is reconstructed as:

15,000 − 8,000 + 3,000 = 10,000 PARLAY.

The implementation uses exact integer arithmetic, bounded blockchain-log processing, and persistent checkpoints.

This approach depends on complete accessible transfer history and standard token-accounting behaviour. It is not appropriate to claim that it can reconstruct arbitrary nonstandard token behaviour without additional analysis.

Nevertheless, it allowed ApeLevel to preserve PARLAY’s intended closing-snapshot governance system without purchasing a commercial historical blockchain indexing subscription.

This was a major achievement: we developed the accounting method ourselves rather than making the client dependent on an expensive external indexing service.

6. Robinhood RPC Rate Limits — Why We Built Our Own Recovery System

Access to a publicly available RPC endpoint does not mean unlimited access.

Robinhood’s public documentation expressly identifies its public endpoints as rate-limited and recommends third-party providers for production workloads.

During PARLAY development, ApeLevel encountered HTTP 429 errors while retrieving blockchain data.

These errors interfered with the timely execution of historical verification jobs.

Our response was not to relax the integrity of the voting calculation or substitute inaccurate data.

Instead, we introduced a more resilient processing architecture.

The public website remained hosted on Cloudflare.

Heavier processing tasks were relocated to GitHub Actions, where they could execute independently from ordinary website requests.

The resulting architecture uses:

Bounded workloads, preventing a single job from attempting an uncontrolled volume of blockchain requests.

Retry logic, allowing transient RPC throttling to be handled without automatically treating the request as invalid.

Database checkpoints, preserving completed processing work.

Independent scheduled execution, allowing background verification to continue without requiring a developer’s Codespace to remain active.

Conditional database updates, reducing conflicting processing operations.

The same design principles were later applied to permanent username verification.

Why this matters to the client

Many blockchain applications solve rate-limit problems by purchasing access to dedicated RPC providers or specialized indexing infrastructure.

Those services can be appropriate and may become necessary as an application scales.

But ApeLevel demonstrated that PARLAY’s present verification requirements could be addressed using public blockchain data and carefully designed recovery logic, without making a paid RPC subscription a prerequisite for deployment.

That is an engineering cost reduction, not a guarantee of unlimited throughput.

If public RPC reliability or demand changes substantially, the project may eventually require alternative providers or additional capacity.

7. GitHub Actions: Automating Verification at No Routine Compute Charge

A particularly important component of PARLAY is GitHub Actions.

GitHub Actions allows software-defined jobs to run on GitHub-hosted infrastructure according to a schedule or authorized manual trigger.

ApeLevel implemented verification processors that use this mechanism to perform work outside the public website’s request lifecycle.

The username-verification workflow is configured to run approximately every five minutes, subject to GitHub’s scheduling behaviour.

It checks pending requests, attempts independent wallet-signature and blockchain-balance verification, and finalizes eligible registrations through the Cloudflare database.

GitHub Actions is especially useful to PARLAY because standard GitHub-hosted runners are free for public repositories, under GitHub’s current billing rules.

That means the application can use scheduled background processing without maintaining a continuously active server or development Codespace.

The source repository and workflow configuration are publicly accessible, while the Cloudflare API token needed for authorized database operations is supplied through an encrypted GitHub repository secret rather than hardcoded into the application.

This separation is important for both security and cost management.

The verification jobs execute only when scheduled or triggered.

They do not require a rented machine sitting idle between runs.

A significant distinction

GitHub Actions and GitHub Codespaces are separate services.

Codespaces is primarily used to develop, edit, build, and deploy the software.

GitHub Actions executes automated jobs after the code is committed.

The public PARLAY website does not depend on someone leaving Codespaces open.

This allows its routine hosting and automated verification to operate independently of ApeLevel’s active development sessions.

8. Permanent Usernames Without Token Transfers or NFT Registration Fees

PARLAY also introduces permanent wallet-linked usernames.

To register an ordinary username, a participant must hold at least 1,000 PARLAY in the connected wallet.

The registration process uses a cryptographically signed message to establish the wallet’s authority over the request.

The application checks the relevant token holdings before confirming permanent ownership.

Cloudflare D1 enforces case-insensitive uniqueness, preventing separate wallets from claiming conflicting versions of the same username.

The design also incorporates registration nonces, expiration checks, deferred verification, processing leases, and cryptographic proof receipts.

Importantly, registering a username does not require minting a separate NFT or submitting an on-chain registration transaction.

The identity record is stored and verified off-chain, with wallet signatures and blockchain eligibility providing the supporting evidence.

This avoids introducing an unnecessary transaction-fee requirement simply to establish a persistent player name.

During production testing on November 4, 2026, the application successfully confirmed the permanent registration of parlaymod.

The frontend was also developed to recognize completed registrations and display the registered username rather than an abbreviated wallet address.

As with the other subsystems, production evidence demonstrates a successful registration rather than an unconditional promise that every future attempt will be immune from outages.

9. The PARLAY Streak Leaderboard

The public leaderboard introduces a competitive identity layer to the governance application.

Registered players can earn rankings based on their consecutive correctly predicted outcomes.

A player qualifies for the leaderboard after one correctly predicted, independently confirmed result.

Additional consecutive successful predictions increase the player’s current streak.

An incorrect confirmed prediction resets that streak.

Voided outcomes are excluded from the calculation.

The public ranking interface displays the player’s username, current streak, and total correct predictions.

It is designed to update automatically as qualifying records become available.

The production leaderboard endpoint successfully returned HTTP 200 during deployment testing.

At that time, the leaderboard contained no qualifying records.

That is an important distinction: the application can calculate and display rankings, but it cannot responsibly create actual winning results without authoritative confirmation of the corresponding wagers.

10. Why Skuxx Must Independently Authorize Wager Outcomes

PARLAY governance and real-world wagering are separate processes.

ApeLevel is responsible for developing the application infrastructure.

Skuxx, as the client and designated wagering decision-maker under the communicated operating model, retains independent authority over actual wager execution and outcome confirmation.

The application can establish which option holders preferred.

It cannot independently prove that a bookmaker accepted a wager, that particular odds were secured, or that a specific betting ticket was ultimately settled as a win.

Those facts arise outside the application.

ApeLevel’s position is that the relevant outcome declarations must be independently authorized by Skuxx in accordance with the applicable client arrangements.

The backend includes an administrator-signed prediction-outcome confirmation mechanism.

However, the presently documented deployment does not establish that a separate Skuxx-controlled signature has already been implemented or that every outstanding client-side signing obligation has been completed.

We therefore distinguish between the software’s ability to process an authenticated outcome and the client’s responsibility to supply authoritative evidence.

The leaderboard infrastructure is available, but actual winning streaks cannot be represented as independently verified until the necessary outcome authorization and evidence exist.

This is a deliberate boundary of responsibility.

11. Why ApeLevel Advises Against Automatic Real-Money Bet Placement

During development, ApeLevel advised Skuxx against automatically placing real-money wagers solely because a particular option received the greatest governance support.

Our concerns fall into three categories.

Legal discretion and manipulation protection

The client must retain discretion to reject a proposed wager that presents legal, integrity, manipulation, or other operational concerns.

A cryptographically authenticated voting majority does not necessarily establish that the underlying wager is appropriate or free from manipulation.

Cryptocurrency governance versus regulated fiat wagering

A blockchain governance decision does not automatically provide legal authorization, compliant payment infrastructure, or guaranteed acceptance by an external regulated sportsbook.

The systems operate under different technical and regulatory conditions.

Banking hours, settlement, and execution constraints

Payment availability, compliance checks, changing odds, market suspensions, sportsbook restrictions, and external processing delays can prevent an actual wager from being accepted at the expected terms.

Blockchain automation cannot eliminate those real-world constraints.

For these reasons, ApeLevel advises that governance remain advisory and that Skuxx independently exercise the necessary judgment over actual wager execution.

This is not an assertion that every form of automated betting is universally illegal or technically impossible.

It is a determination that PARLAY’s currently deployed governance infrastructure should not be represented as a guaranteed automated real-money wagering system.

12. What Does PARLAY Actually Cost to Maintain?

One of the strongest aspects of this project is its cost-conscious architecture.

ApeLevel intentionally avoided establishing permanent reliance on expensive services that the client would need to pay for each month merely to keep the governance application available.

The current infrastructure model can be summarized as follows:

InfrastructurePurposeCost-conscious designGitHub CodespacesDevelopment and deploymentIncluded usage for eligible personal accounts; not needed continuouslyCloudflare WorkersPublic website and backend APIsFree-tier hosting within applicable quotasCloudflare D1Username, ballot, and leaderboard recordsFree-tier database capacity within limitsGitHub ActionsScheduled background verificationStandard runners free for public repositoriesRobinhood public RPCBlockchain reads and verificationPublic endpoint access without a dedicated paid RPC subscriptionCustom historical reconstructionHistorical voting-weight verificationAvoids requiring a commercial blockchain indexing subscription

Estimated routine platform infrastructure expense under the intended current-scale, free-tier configuration: $0 per month.

This is an architectural estimate, not a verified statement about the client’s current billing account or an unconditional contractual guarantee.

It assumes the applicable services remain on eligible free plans, usage stays within their limits, the repository remains public for free GitHub Actions execution, and no additional paid services are introduced.

It also excludes software-development labour, legal and compliance expenses, possible third-party wagering costs, transaction fees for activities outside the gasless voting process, and any future infrastructure upgrades.

At higher levels of traffic, database activity, blockchain verification demand, or operational complexity, additional capacity may become necessary.

Why this is an important engineering achievement

ApeLevel did not eliminate the underlying costs of cloud computing.

Cloudflare, GitHub, and blockchain node operators still incur infrastructure expenses.

Instead, our engineers designed PARLAY to fit within the usage allowances and publicly accessible infrastructure made available by those providers.

That is the difference between claiming that software is magically free to operate and engineering a system to avoid unnecessary recurring client expenditure.

Our goal was to deliver the required application functionality without creating a permanent monthly hosting obligation where none was technically necessary.

This is particularly valuable for an emerging community project that wants to develop its governance infrastructure before committing to substantial ongoing operational expenses.

13. Development Evidence and Public Accountability

ApeLevel’s development and deployment work is documented through the public PARLAY repository and recorded execution evidence.

The development program included local security and database tests examining competing processing leases, wallet-signature verification, exact token-balance calculations, invalid registration evidence, atomic database finalization, and recovery from RPC failures.

The deployment record includes the successful publication of the updated Cloudflare application and database migrations.

The November 4 release was associated with Cloudflare Worker deployment:

6ea00397-d4ba-4473-a4d1-5e89c50dff0c

The application release was committed to GitHub under:

5a8299e

A subsequent username-verification reporting correction was published under:

9369a57

The development process also included successful execution of a GitHub Actions username-verification workflow, though the initial run recorded a deferred-finalization diagnostic.

The live application subsequently confirmed one permanent username registration, and the processor’s success-detection logic was revised to improve future reporting.

These records support the claimed deployment milestones.

They should not be treated as evidence of an independently completed penetration test or a guarantee that every possible future failure mode has been eliminated.

ApeLevel believes transparent engineering requires clearly documenting both successful results and known limitations.

14. An Invitation to PARLAY Holders

We encourage eligible PARLAY holders to connect their wallets and reserve their preferred usernames while available.

A minimum of 1,000 PARLAY is required for ordinary permanent username registration.

Participants should choose their names carefully, because usernames are intended to remain permanently associated with their verified wallets unless an authorized administrative change is approved.

Holders may also participate in available governance proposals and follow the development of the leaderboard as independently confirmed prediction outcomes become available.

The application is publicly accessible at:

https://parlay.apelevel.workers.dev

Its source code is available at:

https://github.com/apelevel/parlay

We also invite holders and interested developers to report problems involving wallet connections, username registration, voting verification, delayed processing, missing records, or leaderboard discrepancies.

Technical issues can be reported directly to ApeLevel, while client-controlled wagering and outcome questions should be directed to Skuxx, with both parties involved where appropriate.

Never share private keys or wallet recovery phrases when submitting support requests.

Final Engineering Perspective

The significance of PARLAY is not simply that holders can connect a wallet and select a voting option.

It is that ApeLevel developed a custom system combining cryptographically authenticated governance, historical token-ownership verification, persistent player identities, deferred blockchain processing, and public prediction rankings.

We addressed unavailable historical state by developing transfer-based reconstruction.

We addressed public RPC throttling by separating verification workloads and implementing retries and persistent checkpoints.

We addressed username conflicts with wallet signatures, database uniqueness constraints, and transaction-level registration safeguards.

We addressed ongoing infrastructure expenses by designing the platform around Cloudflare’s free services, standard GitHub Actions runners, GitHub Codespaces’ included development allowances, and public blockchain RPC access.

And we preserved the fundamental distinction between technical governance records and the independent authority necessary to confirm real-world wagering decisions.

Our engineering objective was straightforward: build a capable blockchain governance platform without requiring the client to maintain expensive, unnecessary infrastructure.

That objective has guided PARLAY throughout its 103-step development program.

The application is deployed. Permanent username registration has been demonstrated. The public leaderboard infrastructure is operational. Actual prediction rankings remain dependent upon independently authorized wager outcomes.

PARLAY demonstrates what can be achieved through careful software architecture, public blockchain infrastructure, and disciplined engineering — without making recurring infrastructure expenditure the starting assumption.

ApeLevel Gaming & Branding
Senior Software Engineering

Developed for Skuxx and the PARLAY community.

PARLAY Governance: https://parlay.apelevel.workers.dev

Source repository: https://github.com/apelevel/parlay

Engineering disclosure: This article describes ApeLevel’s documented software-development work and the project’s intended operating model. Free-tier allowances, service availability, and operating costs may change. The application is not independently certified as immune to errors or manipulation. Governance participation does not guarantee the execution or success of any wager, and no investment or financial return is promised.

By Ape Level | November 2, 2026

Building a blockchain-integrated video game is one thing. Building an economy where every resource is accounted for, every transaction can be independently verified, and players cannot manipulate the marketplace through duplicated or unverified assets is an entirely different challenge.

That is precisely what we are developing with Whisper, Ape Level’s custom-built blockchain settlement and verification infrastructure for RAGE REALMZ.

During our latest development session on November 1–2, 2026, we made substantial progress toward that objective.

We completed another round of Water capacity and recovery engineering, successfully passed 21 automated regression tests, and advanced the integration of automated resource trading using testnet TILT (tTILT) on Polygon Amoy.

We also encountered an important technical challenge while testing our first live Water sale.

The result revealed why reliable blockchain settlement requires more than successfully submitting a transaction.

It requires a system capable of recovering when the blockchain and the game’s internal records temporarily disagree.

Here’s what we built, what we tested, and what happened next.

1. Introducing Whisper: Ape Level’s Custom Blockchain Infrastructure

Whisper is the internal technology being developed to manage verified in-game resources and blockchain-based settlements within RAGE REALMZ.

It is not a separate cryptocurrency or blockchain network.

Instead, Whisper combines our own resource ownership records, verification processes, and settlement infrastructure with transactions executed on Polygon.

The architecture deliberately separates two responsibilities.

The blockchain verifies payment. Whisper verifies the resource.

For example, when a player sells a Water resource inside the game, the Polygon settlement contract processes the corresponding tTILT payment.

Whisper then independently verifies the transaction before updating ownership of the Water resource in its internal registry.

That separation means players cannot simply claim to own resources because a wallet transaction occurred, nor can the game recognize a payment merely because a browser reports success.

Both sides must agree.

This principle is central to our approach to building a marketplace where resources remain scarce, traceable, and protected against duplication.

2. Every Drop Counts: Protecting the Water Economy

Water is one of the first resources being introduced to Whisper Market.

Players can construct Water Wells within their personal Homesteads, collect Water, and save their progress through Whisper’s blockchain-confirmed Homestead system.

Each verified Water unit receives its own unique identifier.

That identifier follows the resource through its lifecycle, including ownership, listing, reservation, transfer, and eventual consumption.

Unlike an NFT, the Water itself is not minted as a blockchain token. Its ownership is maintained within Whisper’s verified in-game resource registry.

That allows us to develop a resource economy without requiring a separate blockchain transaction for every ordinary gameplay action.

But it also creates a responsibility: the resource registry must be exceptionally careful about what it recognizes.

The 100-Water capacity limit

Our current Water system imposes a maximum holding capacity of 100 units per player.

That limit is designed to prevent excessive accumulation and marketplace flooding.

However, enforcing a capacity limit is more complicated than simply checking a number.

Consider a player who already has 99 Water.

What happens if they collect another Water from their well at the same moment they attempt to purchase Water in the marketplace?

If both operations independently observe the same starting inventory, each could incorrectly conclude that additional capacity is available.

This is known as a concurrency problem.

During this development session, we strengthened Whisper’s handling of these competing operations using a shared wallet-level operation lock, trusted inventory synchronization, and database-backed verification.

The goal is straightforward:

Two individually valid operations must never combine to produce an invalid resource balance.

3. Whisper Passes Its Capacity-Competition Tests

One of the most important milestones from this session was the completion of our latest automated testing round.

Whisper has now passed its capacity-competition tests.

The development checkpoint reported:

21 tests executed. 21 tests passed.

Our work covered coordinated Water collection, purchase preparation, resource capacity enforcement, persistence, and recovery.

We also strengthened the underlying system with several components.

Durable Water collection

Water collection is now supported by persistent operation records.

Instead of relying exclusively on temporary server memory, Whisper can retain validated collection activity through its durable storage system.

This is important because a server interruption should not silently erase legitimate resource progress or manufacture additional resources during recovery.

Restart recovery

We also introduced recovery functionality designed to reconcile outstanding collection records after a server restart.

If a collection operation is incomplete or its records are inconsistent, Whisper is designed to fail conservatively rather than simply invent replacement Water.

Wallet-level coordination

Sensitive Water operations are coordinated to reduce conflicts between collection and market activity involving the same wallet.

The result is a stronger foundation for a resource economy in which holding limits actually mean something.

These passing tests represent a meaningful development milestone, although further live multiplayer and wallet testing remains necessary before broader deployment.

4. Moving From Resource Collection to Automated Trading

With the Water economy becoming more robust, we turned our attention to the next major objective:

Allowing a player to sell a verified Water resource directly through Whisper Market and receive tTILT through Polygon Amoy.

Our settlement contract uses EIP-712 signed checkout authorizations.

Each authorization includes important details such as the player’s wallet, the resource manifest, the payment amount, a unique checkout nonce, and an expiry deadline.

This allows the contract to validate the exact transaction being authorized.

It also prevents the same signed checkout from being executed repeatedly.

The intended process is:

1. The player selects Water to sell.
2. Whisper verifies ownership and reserves the resource.
3. The server prepares a signed checkout.
4. The player approves the blockchain transaction through their wallet.
5. The smart contract transfers tTILT and emits a settlement event.
6. Whisper independently verifies the transaction.
7. The game’s resource registry finalizes the sale.

The distinction between steps five and seven is important.

An on-chain payment is not the same thing as a completed resource transfer in the game.

The two must be reconciled securely.

5. Our Live Test: Selling One Water for One tTILT

We initiated a live test using one confirmed Water resource.

The proposed transaction was simple:

Sell 1 Water → Receive 1 tTILT.

The server successfully prepared the checkout and bound it to the intended Polygon Amoy settlement contract.

However, during subsequent inspection, we discovered that the local Whisper settlement database still marked the transaction as:

RESERVED

The database also contained no transaction hash.

Ordinarily, that could suggest the checkout had not progressed to the blockchain confirmation stage.

But we did not want to make that assumption.

A wallet could successfully submit a transaction while an interruption prevents the game server from recording the resulting hash.

Simply cancelling the reservation might therefore create a discrepancy between blockchain payments and off-chain resource ownership.

Rather than forcing the sale through or changing inventory records manually, we investigated the original checkout.

6. The Blockchain Revealed Something Important

Whisper’s settlement contract maintains a nonce registry.

Every successful checkout consumes a unique nonce associated with the player’s wallet.

We inspected the relevant Solidity implementation and then queried the deployed contract directly on Polygon Amoy.

The result was significant:

nonceUsed(player, nonce) = true

The original checkout nonce had been consumed.

In the inspected contract, nonce consumption occurs during successful checkout execution, alongside the token-transfer operation.

That provides strong evidence that the original checkout executed on-chain.

Yet Whisper’s database still showed the settlement as reserved.

We had identified an important reconciliation issue:

The blockchain appeared to recognize the checkout, but Whisper had not completed the corresponding off-chain settlement.

This is exactly the sort of scenario that a blockchain-integrated game must be designed to handle.

A resource should not disappear merely because a server loses connectivity.

A player should not be paid twice because a transaction confirmation is delayed.

And the game should never duplicate resources simply to reconcile incomplete records.

The correct response is to recover the original blockchain evidence and finalize the corresponding settlement only after verification.

7. The Recovery Challenge: Unexpected Polygon Amoy RPC Errors

Our next task was to retrieve the original transaction hash.

The settlement contract emits a CheckoutSettled event containing the wallet, manifest hash, nonce, and payment amounts.

With those details, we could identify the precise checkout, retrieve its transaction receipt, and complete reconciliation.

However, repeated event-log requests through our configured Polygon Amoy RPC provider, dRPC, failed.

The first errors reported:

ranges over 10000 blocks are not supported on free plan

We reduced the requested search ranges and disabled automatic request batching.

The errors persisted.

We then bypassed the ethers.js event retrieval process entirely and submitted a direct JSON-RPC request covering only 100 blocks.

This time, the provider returned:

Temporary internal error. Please retry

The diagnostic trace was:

d9800fc92eb3945c2efb8e52607e9592

The request covered Polygon Amoy blocks 51793193 through 51793292.

A 100-block search was considerably smaller than the provider’s stated 10,000-block restriction.

At this stage, the exact underlying cause of those failures remains undetermined.

Importantly, dRPC is a third-party infrastructure provider. These errors do not, by themselves, establish a defect in the Polygon blockchain.

Nor do they prove that dRPC caused the original missing transaction hash in Whisper’s database.

But they did expose an operational concern: we were unable to retrieve the historical event needed to reconcile a transaction that appeared to have executed successfully.

8. Why We Refused to Force the Settlement

It would have been relatively simple to manually adjust the Water inventory and declare the test complete.

We deliberately chose not to do that.

Whisper’s entire purpose is to maintain a verifiable relationship between resources and settlement evidence.

If we begin manually changing ownership because a transaction looks successful, we undermine that objective.

Our recovery process needs to establish that the blockchain transaction actually succeeded, that the correct wallet received the correct payment, that the transaction corresponds to the original signed resource manifest, and that the settlement has not already been finalized.

Only then should the Water registry be updated.

Until that verification is complete, the original sale remains unresolved within Whisper’s accounting system.

The consumed nonce is strong evidence of execution, but the transaction receipt and independent payment verification are still outstanding.

That is not a result we intend to conceal.

It is a development finding we intend to address.

9. Engineering the Next Layer of Whisper’s Reliability

This incident has helped identify several additional safeguards needed as Whisper progresses.

We intend to strengthen interrupted-checkout recovery, particularly when a transaction executes but its hash is not captured by the application.

We also intend to expand regression testing around expired reservations, preventing resource locks from being released when an executed settlement may still require reconciliation.

Another priority is reducing reliance on a single blockchain RPC provider.

A game economy cannot reasonably assume that every infrastructure request will always succeed.

Whisper must distinguish between a transaction that actually failed and a transaction whose status cannot currently be verified.

Those are two very different circumstances.

A failed transaction may allow a reservation to be released.

An unverified transaction requires further investigation before the corresponding resources can safely move.

Our objective is to make that distinction enforceable through code, not dependent on manual judgment.

10. Ape Level Escalates the RPC Issue to dRPC

Following the unsuccessful recovery attempts, Ape Level prepared a formal technical complaint addressed to dRPC Support.

The complaint documents the repeated eth_getLogs failures, the unexpected error returned for the 100-block request, and the engineering impact on our settlement recovery testing.

We are requesting a substantive explanation of the errors, clarification of the provider’s free-tier limitations, guidance on reliable historical event retrieval, and escalation to its infrastructure engineering team.

We are also seeking to establish whether the problems are isolated to the Polygon Amoy testnet service or could affect other supported environments.

This is a technical concern, not an allegation that dRPC caused our original transaction-recording issue.

Our interest is ensuring that the infrastructure supporting Whisper is sufficiently reliable for the security and reconciliation requirements of a blockchain-integrated game.

11. A Meaningful Development Milestone for RAGE REALMZ

The November 1–2 development session has demonstrated two things.

First, Whisper’s Water resource management is becoming substantially more robust.

The latest capacity-competition tests passed, wallet operations are better coordinated, and durable collection recovery is being incorporated into the game infrastructure.

Second, our settlement testing has exposed a real challenge that cannot be addressed through ordinary inventory logic alone.

Blockchain transactions and off-chain resource ownership operate in separate systems.

Connecting them securely requires careful verification, reliable persistent records, and recovery paths for interrupted operations.

This latest test has provided a concrete scenario against which those protections can be developed.

The goal is not simply to make Whisper process transactions. The goal is to make Whisper account for them correctly, including when something goes wrong.

That remains the standard guiding our development.

What’s Next for Whisper Market?

The immediate priority is recovering the original one-Water checkout transaction, independently verifying its receipt, and reconciling the corresponding resource ownership record.

From there, development will continue toward more resilient settlement recovery, additional regression coverage, and further controlled marketplace testing on Polygon Amoy.

The broader vision remains unchanged.

RAGE REALMZ is being built as a multiplayer world where resources are earned through gameplay, securely recorded, and exchanged through an economy that respects genuine scarcity.

Whisper is the infrastructure we’re building to make that possible.

And as this session demonstrated, the most important engineering progress does not always come from a flawless test.

Sometimes it comes from discovering exactly where the system needs to become stronger.

RAGE REALMZ — By Ape Level

Development continues on Polygon Amoy. tTILT is a testnet asset used for development and testing. The marketplace’s future production functionality remains subject to additional testing, security review, and explicit deployment authorization.

By Ape Level Gaming | October 31, 2026

A New Chapter for RAGE QUITTERS

Today, Ape Level Gaming is announcing a significant restructuring of the RAGE QUITTERS NFT roadmap.

What began as a collection of 500 Ethereum NFTs has evolved into RAGE REALMZ, a multiplayer gaming universe featuring interconnected realms, exclusive NFT-linked gameplay, private Homesteads, resource harvesting, and a blockchain-integrated marketplace powered by UNINSTALL ($TILT).

At the centre of this expansion is Whisper, Ape Level’s custom-built blockchain oracle infrastructure, developed to verify transactions, support resource settlement, and maintain the integrity of the game’s internal economy.

As our technical capabilities have expanded, so too have our responsibilities.

We have concluded that the original roadmap’s emphasis on token liquidity, yield-generating investments, and recurring financial distributions no longer appropriately reflects the purpose of our gaming ecosystem.

More importantly, we recognize that certain elements of the original financial arrangements could foreseeably create expectations resembling those associated with investment contracts under Canadian securities law.

For these reasons, Ape Level is restructuring its roadmap around a fundamentally different commitment:

We are building and maintaining a gaming ecosystem, not offering financial security or investment returns through TILT.

Our updated roadmap is available on the official RAGE QUITTERS OpenSea collection overview:

View the Official RAGE QUITTERS Roadmap

Why the Original Financial Roadmap Is Being Revised

The original RAGE QUITTERS roadmap contemplated directing proceeds from NFT mints toward several financial initiatives.

Those included a substantial locked TILT liquidity pool, yield-generating assets, a staked treasury, and future token distributions intended to benefit holders.

Although these initiatives were originally proposed as mechanisms for supporting the ecosystem, we now recognize that the manner in which they were structured and communicated could create an unintended regulatory issue.

Canadian securities regulators have repeatedly emphasized that the legal characterization of a cryptocurrency token depends on the economic substance of the arrangement — not simply what its developer calls it.

In particular, CSA Staff Notice 46–308 explains that describing a token as a utility token does not automatically remove an offering from the scope of securities legislation.

The circumstances of distribution, representations made to purchasers, potential expectations of profit, and reliance on the developer’s efforts may all be relevant.

This is a distinction Ape Level takes seriously.

A gaming token can have practical utility while still being offered under arrangements that potentially engage securities legislation.

We therefore believe it is prudent to discontinue financial commitments that could be reasonably interpreted as promising token-price support, investment returns, or yield generated through Ape Level’s treasury management.

What This Means for Previous Commitments

Ape Level is discontinuing the original liquidity-support and yield-oriented model as the basis for future NFT mint allocations and promotional commitments.

This decision reflects our intention not to offer or maintain arrangements that may create unintended investment-related obligations.

We also recognize that regulatory concerns do not automatically extinguish contractual rights arising from earlier representations.

Accordingly, previously published commitments will be reviewed to determine their enforceability, regulatory implications, and appropriate treatment under applicable Canadian law.

To the extent a provision is legally unenforceable, Ape Level reserves its position concerning any obligation to perform it. Any enforceable outstanding commitments will be addressed through an appropriate process.

Ape Level does not undertake to guarantee, maintain, or increase the external market price of TILT.

Our future roadmap will instead focus on the delivery of actual gaming services and functionality.

Development First: A Sustainable Funding Model

Building a multiplayer gaming universe involves significantly more than deploying an NFT collection or cryptocurrency token.

RAGE REALMZ now incorporates multiplayer networking, wallet authentication, realm-specific access controls, persistent game state, private Homesteads, blockchain transaction verification, and a growing resource economy.

Maintaining and expanding this infrastructure requires considerable development work.

Our revised roadmap therefore prioritizes using future NFT mint proceeds for reasonable developer compensation, server hosting, technical infrastructure, software development, security, maintenance, and operational reserves.

These are the resources required to build and sustain the game.

Ape Level may also allocate a limited, discretionary portion of available funds toward external TILT liquidity.

However, the purpose of such a contribution is not to establish financial security for token holders.

Rather, it is intended as a reasonable, good-faith effort to discourage excessive dependence on outside liquidity providers whose concentrated positions could potentially disadvantage ordinary participants in the gaming economy.

We recognize that a liquidity contribution cannot prevent all market manipulation or guarantee fairness.

For that reason, our primary safeguards will be implemented within the game itself.

Our development funding exists to support the game — not to guarantee the market valuation of its currency.

Whisper: Ape Level’s Custom-Built Oracle

One of the most important distinctions in our revised economic policy concerns how TILT is used inside RAGE REALMZ.

Whisper Market is designed to facilitate transactions involving in-game resources such as Water, Wood, Ore, Wheat, and other resources introduced through continued development.

These resources are not independently issued NFTs.

They exist within the game’s internal inventory, resource, and persistence systems.

Players acquire and use them according to the game’s established rules.

A Strict Separation From External Token Markets

Ape Level is expressly assuming responsibility for ensuring that its internal Whisper resource-pricing algorithms remain independent of external cryptocurrency market valuations.

Whisper’s algorithms must not incorporate, reference, or rely upon externally reported TILT prices, token market capitalization, exchange rates, trading-pair valuations, or external financial price feeds when determining the TILT prices of in-game resources.

Instead, resource prices will be determined strictly through the relationship between TILT and the resources available within RAGE REALMZ.

Relevant considerations may include resource availability, inventories, permitted transactions, completed in-game trades, production, consumption, and established marketplace rules.

For example, the amount of TILT required to purchase Water inside Whisper Market will not automatically change because an external decentralized exchange reports a different monetary valuation for TILT.

An external financial market may value TILT very differently from the way Whisper prices game resources.

That difference is an intentional feature of the proposed economic architecture.

Although outside trading conditions may influence individual players’ purchasing decisions, they will not serve as algorithmic pricing inputs controlled by Ape Level.

This separation will be treated as a technical requirement subject to testing before production marketplace deployment.

What Ape Level Actually Guarantees

Our marketplace commitments concern the delivery of in-game resources, rather than the financial value of the token used to purchase them.

When a player makes a valid, authorized TILT payment for an in-game resource, Ape Level’s intended obligation is to ensure that the corresponding resource is delivered according to the marketplace’s published terms and applicable law.

We do not guarantee that the resource will possess any independent external monetary value.

We do not guarantee that TILT can be exchanged at a particular price on decentralized exchanges.

And we do not guarantee profits, price appreciation, liquidity, or investment returns.

Introducing Transaction Dispute Protection

As part of this commitment, we intend to introduce an integrated Whisper transaction dispute system.

Players who pay TILT but experience missing or incorrect resource delivery will be able to submit a support ticket referencing their blockchain transaction hash.

Whisper’s settlement records will support verification of the transaction, its associated order, and the player’s resource-delivery history.

Where a valid completed purchase has not been fulfilled, Ape Level will provide the missing resources or another appropriate remedy consistent with its published terms and applicable law.

The system is intended to provide practical accountability for in-game transactions without transforming Ape Level into a guarantor of external cryptocurrency-market losses.

Building a Fairer Economy: Treasury Protection and Human Verification

Ape Level has also been reviewing the distribution and custody of the existing TILT supply.

TILT operates on Polygon Mainnet with a fixed total supply of 500,000 tokens.

Our October 2026 blockchain verification confirmed approximately 334,000 TILT in Ape Level’s development wallet at the block checked.

Under the proposed revised treasury framework, Ape Level is evaluating a protected strategic reserve of 275,000 TILT.

This would represent 55% of the total token supply.

The objective is to maintain a majority reserve larger than all TILT holdings outside that protected reserve combined, subject to the final treasury structure and existing commitments.

This is a supply-management safeguard, not a promise of price stability or protection against every possible market advantage.

One Human, One Account

Ape Level also intends to implement a verified-human account system within RAGE REALMZ.

Each verified person will be permitted one active game account.

Creating additional cryptocurrency wallets will not grant additional resource-harvesting allowances, inventory limits, or independent marketplace privileges.

We also intend to impose reasonable limits on the quantity of resources a player can accumulate and harvest.

These systems are intended to reduce automated resource farming, excessive resource concentration, and attempts to exploit the gaming economy through multiple wallets.

Players who lose access to their original wallet will be able to request manually reviewed account recovery through Ape Level.

An approved recovery will preserve legitimate internal account progress while preventing duplicate economic privileges.

These safeguards are being developed to support a fairer gaming environment, without claiming that exploitation can be completely eliminated.

Recognizing the Original 44

The first 44 RAGE QUITTERS NFTs established the collection’s foundational milestone.

These original supporters participated before RAGE REALMZ evolved into its current multiplayer development architecture.

Stage 1 of the revised roadmap recognizes their early participation and the initial TILT allocations associated with development and testing.

NFT-linked gameplay benefits remain an important part of our direction, including exclusive character skins, access to designated holder-only realms, and planned resource-harvesting privileges.

Our objective is to make NFT ownership meaningful through gameplay rather than promises concerning financial-market performance.

Stage 1 — The Original 44: Complete.

Stage 2: Protectors of the New Age

With the original 44 mints established, the next phase of the roadmap is officially underway.

Stage 2 — Protectors of the New Age covers mints 45 through 100.

This phase focuses on expanding RAGE REALMZ and continuing development of the systems that support its multiplayer world.

Our objectives include expanding Ragehaven and connected realms, introducing additional NFT-linked character skins, developing private Homesteads and resource-harvesting mechanics, advancing Whisper Market, and implementing stronger player-verification and marketplace protections.

This stage is not defined by a promised increase in TILT’s external trading value.

It is defined by the continued development of the game itself.

Our Position Going Forward

Ape Level believes there is a fundamental distinction between developing a virtual gaming economy and offering a financial investment arrangement.

We intend to maintain that distinction through the actual design and operation of RAGE REALMZ.

That means prioritizing gameplay functionality, independently governed resource prices, verified transaction settlement, transparent technical development, and reasonable operational sustainability.

It also means avoiding representations that TILT holders should expect profits or financial security through Ape Level’s development efforts.

Our revised roadmap reflects those priorities.

We recognize that the project’s historical commitments must be handled responsibly and that no roadmap announcement alone determines their legal enforceability.

But we also believe there is a compelling reason to move forward with a business model centred on the delivery of gaming services rather than financial-market performance.

Ape Level’s responsibility is to develop the game, operate its systems responsibly, and fulfil valid in-game resource transactions — not guarantee what unrelated markets may decide TILT is worth.

The Next Chapter Begins

RAGE QUITTERS began with 44 original NFTs.

RAGE REALMZ is developing into a broader gaming universe supported by multiplayer infrastructure, persistent Homesteads, resource economies, and Ape Level’s custom-built Whisper Oracle.

The revised roadmap reflects where the project stands today and the direction in which we intend to develop it.

The original supporters remain part of that foundation.

The next generation of players will help shape what comes next.

STAGE 1 — THE ORIGINAL 44: COMPLETE.

STAGE 2 — PROTECTORS OF THE NEW AGE: IN PROGRESS.

RAGE REALMZ — BY APE LEVEL.

Explore the Official Roadmap

The revised RAGE QUITTERS roadmap, collection overview, and upcoming mint milestones can be viewed directly on OpenSea:

RAGE QUITTERS — Official Collection & Roadmap

Additional Project Resources

RAGE REALMZ — GitHub Development Repository

Ape Level’s Whisper Oracle — Public Repository

UNINSTALL ($TILT) — Polygon Mainnet Contract

Regulatory and development notice: This article explains Ape Level’s proposed revised business and development policies. It is not a legal determination that any existing purchaser obligation has been voided, nor a representation that applicable securities legislation cannot apply. Proposed treasury arrangements, verification systems, and gameplay features remain subject to implementation and applicable legal requirements. No external token price, liquidity, or investment return is guaranteed.

Ape Level Gaming

Build the game. Protect the players. Let gameplay define the economy.