Doublesize Whitepaper

Version 1.0
Publication date: August 29, 2026
Network: BOT Chain

Doublesize is an experimental on-chain participation protocol. This document describes the intended foundation release and its boundaries. It is not investment, financial, legal, tax, accounting, or security advice.

---

Table of Contents

1. Executive Summary
2. Background and Problem
3. Vision and Principles
4. Foundation Release
5. Product Experience
6. Doublesize Points
7. Smart Contract Architecture
8. BOT Chain Integration
9. Public Data and Verification
10. Payment and Treasury Model
11. Security Model
12. Privacy and Data Boundaries
13. Operations and Governance
14. Roadmap
15. Risks
16. No Token or Airdrop Commitment
17. No Financial Advice
18. Conclusion
19. References

---

1. Executive Summary

Doublesize is a BOT Chain-native participation protocol designed around one narrow idea: a wallet's first on-chain action should be easy to understand, deliberately confirmed, and publicly verifiable.

The foundation release gives an eligible wallet two clear entry paths and one optional upgrade path:

• Standard Access: confirm a zero-value contract transaction and receive 100 non-transferable Doublesize Points. The wallet pays network gas, but the contract receives 0 BOT.
• Direct Boosted Access: confirm a contract transaction with exactly 0.01 BOT and receive 200 total non-transferable Doublesize Points.
• Standard Upgrade: a wallet that already holds 100 Standard points may confirm exactly 0.01 BOT once and move to 200 total points.

The contract limits each wallet to a maximum of 200 points. Points cannot be transferred, traded, sold, redeemed, or converted through the foundation protocol.

Doublesize does not promise a token, airdrop, allocation, conversion ratio, return, reward, or future benefit. The value of the foundation release depends on transparent rules, correct contract behavior, clear wallet review, reliable status handling, and independently inspectable BOT Chain records.

---

2. Background and Problem

Many Web3 landing pages ask users to connect a wallet without explaining what happens next. Others present points or rewards before defining whether the state is on-chain, who controls it, what a payment does, or whether a displayed success can be independently verified.

This creates recurring problems.

2.1 Wallet Connection Without a Durable Outcome

A connected state is temporary browser context. It does not create a public record and may disappear after a refresh, device change, wallet change, or storage reset.

2.2 Ambiguous Points

Points may be presented as if they imply future token value, guaranteed eligibility, or a contractual right. Users may act based on an expectation the product never formally defined.

2.3 Hidden Transaction Terms

A network, contract, treasury, native-token value, or gas requirement may remain unclear until the wallet prompt appears.

2.4 Front-End-Only Success

An interface may show success after a transaction is submitted but before a successful blockchain receipt exists.

2.5 Fabricated Activity

Static counters, random hashes, fake user names, and invented transaction rows can make a new protocol appear active.

2.6 Complex First Actions

Users may be asked to complete many tasks before understanding the core product.

2.7 Wallet and Person Confusion

A wallet count can be incorrectly described as a count of unique verified people. One person may control many wallets, and one wallet may be used by multiple people.

2.8 Indexing Assumptions

A product may promise complete historical activity even when the selected public RPC does not support the required log queries.

Doublesize addresses these problems by starting with a small, inspectable contract, fixed outcomes, explicit transaction review, and visible limitations.

---

3. Vision and Principles

Doublesize's longer-term vision is to become a simple participation layer for communities, applications, and software agents operating on BOT Chain. The foundation release does not attempt to deliver a complete campaign network. It establishes the trust boundary first.

3.1 Clear Choice

An eligible wallet sees two understandable outcomes: 100 Standard points or 200 Boosted points.

3.2 Deliberate Confirmation

No transaction is submitted automatically. The user reviews the wallet, network, contract, value, treasury, expected points, and gas context before confirming.

3.3 Verifiable State

The contract is the source of truth for tier, points, aggregate counts, pause state, and bounded recent activity.

3.4 Fixed Rules

The first-release points and boost amount are constants. The interface does not calculate speculative value or change the amount dynamically.

3.5 No Speculation Required

The product remains understandable without a token price, yield, APY, cash prize, lottery, or airdrop promise.

3.6 Template-Respecting Product Design

The public application is implemented inside the complete website template supplied by the project owner. Doublesize content and interactions adapt to that system instead of replacing it with a generic Web3 interface.

3.7 Honest Unavailability

When a contract, RPC, Explorer, indexer, wallet provider, or data source is unavailable, the interface states that the information is unavailable instead of displaying an invented result.

---

4. Foundation Release

The foundation release is expected to include:

• an English public website;
• an original Doublesize identity;
• self-custodial wallet connection;
• BOT Chain Mainnet and Testnet definitions;
• network detection, add, and switch flows;
• Standard, Direct Boosted, and Standard Upgrade actions;
• a maximum of 200 points per wallet;
• an Account view;
• a public wallet-address checker;
• live protocol statistics;
• bounded recent contract activity;
• transaction, block, wallet, contract, and treasury evidence;
• this Whitepaper;
• Privacy and Terms pages;
• smart-contract and frontend testing;
• BOT Chain Testnet deployment and verification;
• a separate authorization gate for Mainnet;
• Vercel Preview and Production publication.

The foundation release does not include:

• a transferable token;
• token sale;
• NFT mint;
• staking;
• yield or APY;
• cash prize;
• lottery, raffle, or draw;
• referral commission;
• guaranteed financial return;
• guaranteed reward;
• guaranteed airdrop;
• token allocation;
• complex campaign administration;
• custody;
• automatic trading;
• token approvals.

---

5. Product Experience

5.1 Wallet Connection

Users enter Doublesize through an EVM-compatible self-custodial wallet.

Connecting a wallet:

• exposes the selected public address to the interface;
• permits public contract and balance reads;
• does not move funds;
• does not authorize a transaction;
• does not give Doublesize the private key;
• does not prove that the wallet represents one unique person.

The interface must not automatically open a transaction prompt on initial load.

5.2 Why a Standard Transaction Is Required

A wallet connection is not a durable public record. Standard Access therefore uses a contract call with 0 BOT value. Once a successful receipt exists, the points can be read independently from the contract.

The user still pays the network gas required by BOT Chain. Standard Access must not be described as completely free.

5.3 Network Selection

The user must be on the configured BOT Chain environment.

When the wallet is connected to another network, the interface may request a switch after a deliberate user action. If BOT Chain is unknown to the wallet, the interface may request permission to add the official network values.

Preview deployments should use BOT Chain Testnet unless explicitly configured otherwise. Production Mainnet requires separate authorization, reviewed bytecode, and confirmed production addresses.

5.4 Standard Access

An eligible wallet may call claimStandard.

The transaction:

• sends 0 BOT value to the contract;
• requires BOT for network gas;
• records the wallet as Standard;
• records 100 Doublesize Points;
• records an activation timestamp;
• updates aggregate contract state;
• emits a public event;
• writes a bounded recent-activity record.

A wallet may complete Standard Access once.

5.5 Direct Boosted Access

An eligible wallet may call claimBoosted with exactly 0.01 BOT.

The transaction:

• requires exactly 0.01 BOT plus network gas;
• records the wallet as Boosted;
• records 200 total Doublesize Points;
• records activation and boost timestamps;
• updates aggregate contract state;
• emits a public event;
• writes a bounded recent-activity record;
• forwards the exact 0.01 BOT to the immutable treasury.

Underpayment and overpayment revert.

5.6 Standard Upgrade

A Standard wallet may call upgradeToBoosted with exactly 0.01 BOT.

The transaction:

• moves the wallet from Standard to Boosted;
• adds 100 points for a final total of 200;
• does not increase the participant count a second time;
• updates Standard and Boosted aggregate counts;
• records the boost timestamp;
• emits a public event;
• writes a recent-activity record;
• forwards exactly 0.01 BOT to the treasury.

The upgrade is available once.

5.7 Transaction Review

Before a transaction, the interface should display:

• connected wallet;
• target network;
• contract address;
• treasury address;
• function or action;
• contract value;
• expected points;
• maximum points;
• network gas context;
• one-time rule;
• no-airdrop disclosure.

The interface should simulate the exact contract call when supported.

5.8 Confirmation and Evidence

The interface displays success only after a successful transaction receipt.

A confirmed result should expose:

• action type;
• wallet;
• points after confirmation;
• BOT value;
• transaction hash;
• block number;
• contract;
• relevant Explorer links.

Pending transactions may be recovered after refresh using only non-sensitive local fields.

---

6. Doublesize Points

6.1 Definition

Doublesize Points are non-transferable participation records maintained by the Doublesize smart contract.

6.2 Initial Rules

| Wallet state | Contract value | Points | Repeatable | |---|---:|---:|---| | No record | — | 0 | — | | Standard | 0 BOT | 100 | No | | Direct Boosted | 0.01 BOT | 200 | No | | Standard Upgrade | 0.01 BOT | 200 total | No |

Network gas is paid separately.

6.3 Maximum

A wallet cannot exceed 200 points in the foundation release.

6.4 What Points Are Not

Doublesize Points are not:

• an ERC-20 token;
• an NFT;
• cash;
• a deposit;
• a security;
• equity;
• debt;
• protocol revenue rights;
• a claim on treasury assets;
• a governance right;
• a transferable credential;
• guaranteed token eligibility;
• guaranteed airdrop eligibility;
• proof of unique personhood;
• an estimate of future financial value.

6.5 Future Programs

Doublesize may evaluate additional community uses. Any future program would require separate public rules, security review, technical implementation, operational design, and legal review.

A foundation-release points balance creates no contractual right to participate in or benefit from a future program.

---

7. Smart Contract Architecture

7.1 Reference Contract

The reference contract is named DoublesizeGenesis.

7.2 Tier Model

None
Standard
Boosted

7.3 Constants

Standard points: 100
Boosted points: 200
Boost fee: 0.01 BOT
Recent activity capacity: 50

7.4 Stored Member State

For each wallet, the contract stores:

• tier;
• points;
• activation timestamp;
• boost timestamp.

7.5 Aggregate State

The contract stores:

• total participating wallets;
• total Standard wallets;
• total Boosted wallets;
• total points issued;
• total BOT collected;
• total recent-activity record count.

7.6 Administration

The owner may:

• pause;
• unpause;
• use a two-step ownership-transfer process.

The owner may not:

• arbitrarily add user points;
• remove user points;
• transfer user points;
• repeat a user's boost;
• change a confirmed wallet's tier through an administrator method.

7.7 Treasury

The treasury is immutable after deployment in the reference design.

The production project owner must approve:

• treasury address;
• owner address;
• whether the treasury is an externally owned account, multisignature wallet, or contract;
• operational controls;
• accounting and legal treatment.

The contract forwards successful 0.01 BOT payments. A treasury-transfer failure reverts the entire user action.

7.8 Direct Transfers

Unrecognized direct native-token transfers revert. Funds should enter only through a reviewed payable function with an exact value.

7.9 Events

The contract emits events for:

• Standard claim;
• Direct Boosted claim;
• Standard-to-Boosted upgrade.

Events support future indexers, but the foundation public Mainnet interface should not depend on the listed public endpoint for eth_getLogs.

7.10 Invariants

The implementation should preserve:

points ∈ {0, 100, 200}
None → 0 points
Standard → 100 points
Boosted → 200 points
Standard wallets + Boosted wallets = participants
BOT collected = 0.01 BOT × Boosted wallets

---

8. BOT Chain Integration

BOT Chain is presented in its official materials as an EVM-compatible Layer 1. The application uses standard Ethereum-compatible wallets and tools.

8.1 Mainnet

Chain ID: 677
Native token: BOT
RPC: https://rpc.botchain.ai
Explorer: https://scan.botchain.ai

8.2 Testnet

Chain ID: 968
Native token: BOT
RPC: https://rpc.bohr.life
Explorer: https://scan.bohr.life

8.3 RPC Limitation

The official BOT Chain developer documentation states that eth_getLogs is disabled on the listed public Mainnet endpoint.

The foundation release therefore separates:

• direct view calls and receipt reads;
• bounded recent activity stored by the contract;
• future complete event history through an approved indexer, third-party RPC, or WebSocket provider.

When no approved history source is configured, the application must not fabricate a complete historical feed.

8.4 Network Risk

RPC providers, Explorers, wallets, block production, finality, reorganization, congestion, and external infrastructure may affect reads and transactions.

---

9. Public Data and Verification

9.1 Contract State

The interface may display:

• member tier;
• member points;
• timestamps;
• aggregate counts;
• paused state;
• bounded recent activity;
• contract and treasury addresses.

9.2 Explorer Evidence

The interface may link to:

• wallet;
• contract;
• treasury;
• block;
• transaction.

An Explorer link improves inspectability but does not constitute an audit or guarantee that a contract is safe.

9.3 Wallet Checker

A public checker may read any valid address without requiring wallet connection. A check reveals only public chain state and does not prove ownership of the entered address.

9.4 Data Failure

Failed reads must produce an unavailable or retry state. A successful zero read may display zero.

9.5 No Fake Activity

The interface must not seed transaction rows, random hashes, names, avatars, or balances to make the protocol appear active.

---

10. Payment and Treasury Model

10.1 Standard

Standard sends no BOT value to the contract, but network gas is required.

10.2 Boost

Direct Boosted and Standard Upgrade require exactly 0.01 BOT.

The 0.01 BOT is:

• a fixed protocol action value;
• not a deposit;
• not principal;
• not staked;
• not invested;
• not interest-bearing;
• not the purchase of a transferable token;
• generally irreversible after successful confirmation.

10.3 Gas

Gas is paid to the network and is separate from the fixed 0.01 BOT contract value. A final wallet estimate may differ from an earlier interface estimate.

10.4 Treasury Transparency

The interface should display the configured treasury and link it to the Explorer.

Doublesize does not guarantee how legal, tax, or accounting rules apply to a user or treasury operator.

---

11. Security Model

11.1 Self-Custody

Doublesize does not request private keys, seed phrases, or keystore files.

11.2 Exact Values

Payment functions reject values other than exactly 0.01 BOT.

11.3 Reentrancy Protection

Payable paths should use checks-effects-interactions and a reentrancy guard.

11.4 Pause

The owner may pause new actions in response to an incident. A pause does not erase existing records and does not prove that every risk has been resolved.

11.5 Immutable Treasury

The reference design avoids an owner function that silently changes the treasury after deployment.

11.6 No Arbitrary Points Administration

The reference design provides no function for the owner to grant or remove individual user points.

11.7 Testing

Tests should cover:

• deployment;
• zero addresses;
• every successful path;
• duplicate claims;
• underpayment;
• overpayment;
• treasury failure;
• pause;
• ownership;
• direct transfers;
• bounded activity;
• invariants;
• reentrancy attempts.

11.8 External Review

A public Mainnet launch should receive independent smart-contract, operational, and legal review. Publishing source code is not equivalent to an audit.

11.9 Frontend Integrity

A malicious or compromised frontend can misrepresent a contract request even when the contract code is correct. Production should use reviewed configuration, protected deployment access, dependency and secret scanning, appropriate security headers, minimal third-party scripts, and post-deployment checks.

Users should verify the network, contract, function, and value in their wallet.

---

12. Privacy and Data Boundaries

12.1 Public Blockchain Data

Wallet addresses, contract calls, transferred BOT values, blocks, timestamps, and transaction records may be public and permanent.

Disconnecting a wallet does not erase blockchain data.

12.2 Wallet and Infrastructure Providers

Wallet applications, WalletConnect when enabled, RPC providers, Explorers, Vercel, domain providers, analytics, and browsers may process technical metadata under their own terms.

The production Privacy Policy should describe the providers actually used and must not claim that Doublesize controls their independent practices.

12.3 Local Pending State

The application may store a pending transaction hash, wallet, chain ID, action type, and submission time so the interface can recover after refresh.

It must not store private keys, seed phrases, raw signatures, or secret authentication material.

12.4 Analytics

Analytics should be disabled by default unless deliberately configured and disclosed.

12.5 One Wallet Is Not One Person

Address counts must not be described as verified unique humans.

---

13. Operations and Governance

The foundation release uses narrow owner controls for incident response.

Operational decisions may include:

• pausing and unpausing;
• deploying a corrected contract version;
• updating the application to a newly reviewed contract;
• changing infrastructure providers;
• correcting frontend defects;
• publishing revised policies;
• suspending unavailable features.

A contract migration cannot silently rewrite the state of the original immutable contract. The application must disclose the active contract and version.

A future community-governance model, if explored, requires separate design and must not be implied by foundation points.

---

14. Roadmap

14.1 Foundation

• complete template-based website;
• original brand;
• Standard and Boosted Access;
• Account;
• public checker;
• Activity;
• Whitepaper;
• legal pages;
• Testnet validation;
• Vercel release.

14.2 Campaign Registries

Explore transparent registries where communities define additional actions and publish their rules.

14.3 Participation Identity

Explore non-transferable badges, richer participation histories, and portable views of confirmed records.

14.4 Agent-Readable Coordination

Explore structured interfaces that allow software agents to inspect participation rules and public states.

All roadmap items are exploratory. They may be changed, delayed, or cancelled. They do not promise a token, airdrop, reward, or delivery date.

---

15. Risks

15.1 Smart Contract Risk

Defects may cause transactions to fail, state to be incorrect, or funds to be routed unexpectedly.

15.2 Treasury Risk

The treasury may be compromised, unavailable, incorrectly configured, or subject to legal and operational obligations.

15.3 Wallet Risk

Users are responsible for wallet security and reviewing transaction prompts.

15.4 Network Risk

BOT Chain, RPC providers, Explorers, wallets, and indexers may be unavailable or inconsistent.

15.5 Irreversibility Risk

Successful blockchain transactions and payments are generally irreversible.

15.6 Data Risk

Public reads may be delayed, unavailable, cached, incomplete, or inconsistent.

15.7 Interface Risk

A browser, dependency, Vercel deployment, configuration error, or frontend defect may display stale or incorrect information.

15.8 Regulatory Risk

Rules affecting digital assets, points programs, native-token payments, wallets, and decentralized applications may change.

15.9 Roadmap Risk

Planned features may not be delivered.

15.10 Name and Brand Risk

The project owner must perform domain, social-handle, trademark, and prior-project review. This document does not establish global legal clearance for the name Doublesize.

---

16. No Token or Airdrop Commitment

Doublesize has not promised a token or airdrop through this Whitepaper.

A Doublesize Points balance does not create:

• a right to receive tokens;
• a right to receive money;
• a right to receive protocol ownership;
• a right to governance;
• a minimum allocation;
• a conversion ratio;
• a snapshot entitlement;
• a guaranteed reward;
• an expectation of profit;
• a contractual right to a future program.

Any future announcement would require separate public terms, implementation, and review.

Users should not pay transaction fees or 0.01 BOT based on speculation about an unannounced token or reward.

---

17. No Financial Advice

Doublesize does not provide investment, trading, financial, legal, tax, accounting, or security advice.

References to BOT Chain, wallets, contracts, infrastructure, or possible future integrations do not constitute an endorsement or recommendation.

Users must independently evaluate whether they understand and accept the transaction and its risks.

---

18. Conclusion

Doublesize begins with a deliberately small foundation:

one wallet
Two clear paths
one maximum points balance
one fixed optional boost
public BOT Chain evidence

The foundation release succeeds only when the displayed state is accurate, transaction terms are clear, contract rules are tested, the user remains in control, missing data remains visibly missing, and no speculative promise is used to disguise the product's limited scope.

Doublesize's operating principle is:

Make one verified action count twice — without doubling the ambiguity.

---

19. References

• Reference product reviewed for public-site rhythm: https://joinbundle.com/
• BOT Chain official website: https://www.botchain.ai/en
• BOT Chain developer quick guide: https://dev-docs.botchain.ai/docs/Developers/quick-guide/
• BOT Chain JSON-RPC endpoint documentation: https://dev-docs.botchain.ai/docs/Developers/json-rpc-endpoint/
• BOT Chain Mainnet Explorer: https://scan.botchain.ai
• BOT Chain Testnet Explorer: https://scan.bohr.life