webgoex
Table of contents

webgoex Whitepaper

Wallet-Verified AI Access and Optional On-chain Proof on BOT Chain

Version: 1.1
Publication date: August 29, 2026
Network: BOT Chain
Status: Foundation Product and Technical Framework

Important Notice

This Whitepaper describes the intended foundation release of webgoex. It is informational and may change after technical, security, operational, ecosystem, and legal review.

webgoex does not issue or announce an ERC-20 token, token sale, tokenomics model, snapshot, allocation, conversion ratio, investment product, or guaranteed airdrop through this document.

Webgoex Points are non-transferable application participation records. They are not currency, securities, ownership, debt, governance rights, revenue rights, claims on assets, or promises of future value. They have no cash redemption value.

The optional 0.01 BOT Boost is a user-confirmed blockchain transaction. It is not a deposit, stake, investment, token purchase, or promise of return. Network gas is paid separately.

Nothing in this document is financial, investment, legal, tax, regulatory, brokerage, trading, cybersecurity, or professional AI advice.

1. Executive Summary

webgoex is an open AI access and participation gateway built on BOT Chain.

The long-term direction is to coordinate access to AI services, contributed compute, workload requests, and verifiable execution evidence. The foundation release deliberately starts with a smaller product that can be implemented and inspected honestly.

A user connects a compatible self-custodial wallet, switches to BOT Chain, and signs one readable, gas-free verification message. The application verifies wallet control through a short-lived, one-time nonce. A first-time verified wallet receives one 100-Point Genesis record in the webgoex application database.

The user may keep the 100-Point record without paying BOT. The user may also choose an optional Boost. The Boost sends exactly 0.01 BOT through the configured WebgoexBoostRegistry contract, plus network gas. After a successful receipt and strict server-side reconciliation, the wallet reaches 200 total Webgoex Points.

The foundation flow is:

Connect wallet
→ switch to BOT Chain
→ request a one-time challenge
→ sign a readable verification message
→ receive 100 application Points
→ optionally review a 0.01 BOT Boost
→ confirm in the wallet
→ wait for a successful receipt
→ verify sender, contract, function, value, event, block, and contract state
→ record 200 total Points
→ inspect the account and BOT Explorer evidence

The foundation release does not claim that all Points are on-chain. The base 100-Point record is an application record created after cryptographic wallet verification. The optional Boost is publicly evidenced by BOT Chain transaction and contract state. The interface must label these sources clearly.

2. The Problem

2.1 AI access is often account-bound

Many AI products rely on closed accounts, platform-controlled permissions, and private usage records. Users and developers may be unable to inspect how access status is created or whether a participation claim has independent evidence.

2.2 Participation claims can be vague

Projects may describe compute contribution, model hosting, node activity, or community participation without a reliable record of the underlying action.

2.3 Web3 interfaces can overstate decentralization

Connecting a wallet does not automatically create a decentralized compute network, verifiable inference system, or open AI marketplace. Honest products should distinguish a live primitive from a future architecture.

2.4 Points can become speculative

Points are often marketed as if they guarantee future tokens or rewards. This can cause users to spend money based on unsupported expectations.

2.5 Client-side status is not trustworthy proof

A website can display a success animation or store a value in a browser without establishing who controls the wallet or whether a paid transaction actually succeeded.

webgoex begins with a narrower question:

Can wallet control, a fixed participation record, and an optional paid Boost be implemented with explicit consent, clear source labels, and independently inspectable on-chain evidence?

3. Product Principles

User control

The user keeps control of the wallet. webgoex never requests a seed phrase, private key, wallet password, or keystore file.

Wallet connection does not move funds. The verification signature is readable and scoped to wallet control. The paid Boost requires a separate review and wallet confirmation.

Verify before recording

The application records the first 100 Points only after verifying a cryptographic signature over a one-time, expiring challenge.

Fixed rules

A verified wallet receives 100 base Points once. A successful Boost adds 100 once. The maximum is 200. The Boost value is exactly 0.01 BOT.

Clear source labels

The product distinguishes application records from public BOT Chain proof. It does not describe an off-chain database value as an on-chain token balance.

Honest AI scope

Compute routing, model hosting, provider rewards, decentralized training, and verifiable inference remain roadmap directions until real infrastructure, security assumptions, and operational evidence exist.

No unsupported reward promise

Points do not guarantee a token, allocation, snapshot, conversion, financial return, or airdrop.

4. Foundation Release

4.1 Wallet connection

The user connects a compatible EVM wallet and switches or adds BOT Chain. Connection exposes the selected public address and network to the interface. It does not itself authorize a transaction.

4.2 Wallet verification

The application creates a short-lived, high-entropy nonce and a human-readable message containing the domain, URI, wallet address, purpose, version, Chain ID, nonce, issuance time, and expiration time.

The user signs the message. The signature costs no gas and sends no BOT.

The server verifies:

  • the message structure;
  • the actual production domain and URI;
  • the expected Chain ID;
  • nonce existence, expiry, purpose, and one-time use;
  • the recovered signing address;
  • the connected wallet address.

After successful verification, the server creates or restores a secure session and creates the wallet's 100-Point Genesis record if it does not already exist.

4.3 Base Points

A verified wallet receives:

Base Points: 100
Protocol BOT payment: 0
Network gas: 0
Limit: once per wallet
Source: webgoex application record

The base Points are stored in the application database. They are not an ERC-20 balance and are not claimed to be fully on-chain.

4.4 Optional Boost

A verified wallet may keep the base record or activate the optional Boost:

Boost Points: +100
Final total: 200
BOT value: exactly 0.01 BOT
Network gas: paid separately
Limit: once per wallet
Source: BOT Chain transaction and contract state

The interface shows the wallet, network, contract, treasury, exact BOT value, expected result, and gas disclosure before submission.

4.5 Account and proof

The Account page displays:

  • wallet address;
  • BOT Chain network;
  • verification status and time;
  • base Points and application source label;
  • Boost status;
  • total Points;
  • Boost transaction hash and block;
  • contract and treasury;
  • BOT Explorer links.

5. System Architecture

The foundation release contains six layers.

5.1 Frontend

The frontend provides template-based brand presentation, wallet connection, network switching, signature review, Boost review, transaction status, Account state, Whitepaper, and legal pages.

5.2 Challenge and verification service

The service creates one-time nonces, validates signed messages, prevents replay, and establishes a secure session.

5.3 Profile database

The database stores one deterministic Genesis profile per wallet, including base Points, Boost Points, total Points, timestamps, and the verified Boost transaction reference.

Database constraints should keep the allowed totals at 100 or 200 and prevent duplicate wallet or transaction records.

5.4 Boost contract

WebgoexBoostRegistry accepts exactly 0.01 BOT through activateBoost(), records one Boost per wallet, exposes aggregate counters, and emits a public event.

It does not issue a token and does not manage the base 100 Points.

5.5 Reconciliation service

The service receives a transaction hash only from an authenticated wallet session. It retrieves and verifies the transaction, receipt, event, deployment boundary, and contract state before updating the application profile from 100 to 200.

The process is idempotent. A transaction hash cannot be replayed for another wallet or counted twice.

5.6 Public verification

The product links paid actions to BOT Chain Explorer. The interface treats a success animation as insufficient proof by itself.

6. Points Model

6.1 Base record

Action: Verify wallet control
Points: 100
BOT value: 0
Gas: 0
Limit: once per wallet
Storage: application database

6.2 Boost

Action: activateBoost()
Additional Points: 100
Final Points: 200
BOT value: exactly 0.01 BOT
Gas: paid separately
Limit: once per wallet
Proof: BOT Chain receipt, event, and contract state

6.3 Maximum

A wallet cannot exceed 200 Points in the foundation release.

6.4 Non-transferability

Points cannot be transferred, sold, approved, bridged, staked, redeemed, or withdrawn.

6.5 No guaranteed future rights

Points do not establish eligibility for a token, airdrop, snapshot, allocation, conversion ratio, governance right, service entitlement, or financial return.

7. Smart-Contract Architecture

The recommended foundation contract is intentionally small and non-upgradeable.

Contract: WebgoexBoostRegistry.sol
Constant: BOOST_FEE = 0.01 ether
One Boost per wallet
Exact-value enforcement
Pausable emergency control
Reentrancy protection
Two-step ownership transfer
Treasury update with event
Direct transfers revert

The owner may pause, unpause, update the treasury, and transfer ownership through a documented two-step flow. The owner cannot edit application Points through the contract or create Boost records for users.

The contract forwards the exact BOT value to the configured treasury. If forwarding fails, the entire transaction reverts and the Boost state does not persist.

8. Transaction Reconciliation

A successful receipt alone is not enough to update Points. The service verifies:

  • authenticated session wallet;
  • supported Chain ID;
  • configured contract address;
  • transaction sender;
  • activateBoost() selector;
  • exactly 0.01 BOT value;
  • successful receipt;
  • expected BoostActivated event;
  • matching wallet in the event;
  • block at or after the deployment block;
  • unique, unused transaction hash;
  • boosted(wallet) == true in contract state.

Only after all checks pass does a database transaction add 100 Boost Points and set the total to 200.

Pending, reverted, replaced, mismatched, replayed, or unverifiable transactions do not increase Points.

9. Treasury and BOT Flow

The Boost transaction sends exactly 0.01 BOT through the configured contract flow, plus network gas.

The treasury address is visible before confirmation and documented with the deployment. A production treasury should be a formal project-controlled address rather than an undocumented developer wallet. A multisignature arrangement may be appropriate after operational review.

The Boost fee is not a deposit, stake, investment, token sale, yield product, or refundable account balance.

10. BOT Chain

BOT Chain is the execution and public verification layer for the optional Boost.

The intended Mainnet configuration is:

  • Chain ID: 677;
  • native token: BOT;
  • RPC: https://rpc.botchain.ai;
  • Explorer: https://scan.botchain.ai.

Testing uses:

  • Testnet Chain ID: 968;
  • native test token: tBOT;
  • RPC: https://rpc.bohr.life;
  • Explorer: https://scan.bohr.life;
  • faucet: https://faucet.botchain.ai/basic.

Network values must be re-verified immediately before deployment.

The public Mainnet RPC may not support historical eth_getLogs. The foundation release therefore relies on current receipts, contract view functions, and the application's verified reconciliation records rather than a full-chain event scan.

11. Data and Privacy

11.1 Public blockchain data

Boost wallet addresses, contract addresses, transaction hashes, blocks, timestamps, BOT values, and contract state are public blockchain information.

11.2 Application data

The foundation application may process:

  • public wallet address;
  • Chain ID;
  • nonce metadata and secure hashes;
  • signed verification message and verification result as operationally required;
  • secure session data;
  • base and Boost Points;
  • verification timestamps;
  • Boost transaction and reconciliation status.

The production implementation should minimize retention of raw signatures and nonces, define retention periods, and protect server-side data through access controls and secure infrastructure.

11.3 Data not required

The foundation release does not require seed phrases, private keys, wallet passwords, identity cards, passport scans, biometric templates, legal names, home addresses, phone numbers, or email accounts.

11.4 Browser recovery

The browser may store limited pending transaction metadata so confirmation can resume after a refresh. Browser storage is not an authoritative Points ledger.

11.5 Infrastructure

Wallet providers, RPC providers, Explorer services, database providers, rate-limit services, WalletConnect, hosting providers, and Vercel may process technical requests under their own terms and policies.

12. Security Model

Security depends on the wallet, browser, frontend deployment, challenge service, session implementation, database, RPC, BOT Chain network, contract, treasury, Explorer, and third-party infrastructure.

Important controls include:

  • high-entropy, short-lived, one-time nonces;
  • domain, URI, Chain ID, purpose, and time validation;
  • secure HttpOnly sessions;
  • origin and CSRF checks;
  • rate limits;
  • database uniqueness and value constraints;
  • exact contract fee;
  • transaction simulation;
  • strict receipt and event reconciliation;
  • replay protection;
  • pending transaction recovery;
  • verified contract source;
  • documented owner and treasury.

No review or test guarantees that software is defect-free.

13. AI and Compute Direction

webgoex may explore three future coordination layers.

Access

Model catalogs, service adapters, explicit permissions, usage limits, pricing disclosures, and application interfaces.

Compute

Provider registration, declared hardware, benchmark evidence, availability, workload requests, routing, service quality, and dispute boundaries.

Proof

Signed receipts, execution provenance, result attestations, privacy-preserving proofs, and machine-readable evidence.

These capabilities are not live in the foundation release. Hardware identity can be spoofed, benchmarks can be manipulated, workloads may contain sensitive data, providers can fail, and efficient verification may be difficult. Future claims must be supported by real infrastructure and evidence.

14. Roadmap

Foundation

Template-based website, original brand, wallet verification, 100 application Points, optional 0.01 BOT Boost, Account proof, Whitepaper, legal pages, testing, and Vercel deployment.

AI Gateway

Explore service catalogs, model adapters, explicit permissions, and transparent hosted-versus-third-party disclosures.

Compute Coordination

Research provider registration, benchmark evidence, uptime, workload requests, service terms, and operational disputes.

Verifiable Execution

Evaluate signed receipts, provenance, attestations, privacy-preserving techniques, and machine-readable proof formats.

Ecosystem Access

Explore integrations for AI agents, developer tools, community applications, and documented read interfaces.

Roadmap items are directions, not delivery promises. They may change.

15. Administrative Boundaries

The application database and verification service are centrally operated in the foundation release. This boundary must be disclosed.

The contract owner has limited emergency and treasury controls. The owner cannot use the contract to edit application Points.

The application should avoid an unrestricted administrator endpoint that can arbitrarily assign Points. Any exceptional correction process should require documented authorization, audit logs, reason codes, and a separate policy before use.

16. Risks

Signature and phishing risk

Users may sign a malicious or misleading message on a compromised website. Users should verify the domain and message purpose.

Session and database risk

The application database or session system may be compromised, unavailable, corrupted, or incorrectly configured.

Smart-contract risk

Contract code may contain defects or behave differently from expectations.

Wallet risk

Users may confirm the wrong transaction, use a compromised wallet, or lose access to keys.

Network risk

BOT Chain, RPC services, Explorers, and infrastructure may be delayed, unavailable, or inconsistent.

Treasury risk

The treasury may be incorrectly configured, compromised, or unavailable.

Frontend risk

A compromised frontend may display the wrong contract, amount, message, or destination.

AI expectation risk

Users may assume that model inference, compute rental, node income, or verified execution is already available when it is not.

Points expectation risk

Users may incorrectly assume that Points guarantee an airdrop or financial benefit.

Privacy risk

Public wallet activity and application records may be linked with other information.

Regulatory risk

Rules governing digital assets, points, AI services, privacy, consumer disclosures, and online services vary and may change.

17. Token and Airdrop Policy

webgoex has not announced a token through this Whitepaper.

No airdrop is promised.

Webgoex Points do not establish eligibility, snapshot status, allocation, conversion ratio, token supply, vesting, reward date, expected value, or financial return.

Users should not complete the Boost based on an expectation of future financial value.

18. Conclusion

webgoex begins with a limited and testable promise.

A user proves control of a self-custodial wallet through a readable, gas-free signature and receives one fixed application record. The user may optionally confirm an exact 0.01 BOT transaction, after which the application verifies public BOT Chain evidence before updating the total record.

This foundation does not solve every decentralized AI problem. It establishes the behavior required for a credible future coordination layer:

  • explicit consent;
  • cryptographic wallet verification;
  • fixed rules;
  • honest data-source labels;
  • strict transaction reconciliation;
  • self-custody;
  • public paid-action proof;
  • clear AI scope boundaries;
  • no unsupported token promise.

The long-term opportunity is to connect AI access, compute participation, and execution proof. The first responsibility is to make the current layer real.