commonspot

WHITEPAPER · VERSION 1.0

The system, before the action.

The points model, contract boundaries, payment path, risks, and what commonspot does not promise.

Version 1.0 Publication date: September 4, 2026

commonspot is an experimental Web3 participation protocol. This document describes the intended first release, its contract boundaries, and its limitations. It is not investment, financial, legal, tax, accounting, or security advice.

1. Executive Summary 2. Context and Problem 3. Vision and Principles 4. First-Release Scope 5. User Experience 6. commonspot Points 7. Smart Contract Architecture 8. Settlement Environment 9. Public Data and Verification 10. Signal Boost and Treasury 11. Security Model 12. Privacy and Data Boundaries 13. Administration and Operations 14. Roadmap 15. Risks and Limitations 16. No Token or Airdrop Commitment 17. No Financial Advice 18. Conclusion

---

1. Executive Summary#

commonspot is a lightweight public participation layer for wallet-owned records. It allows a user to connect a self-custodial wallet, create a one-time participation record, receive non-transferable points, and verify the confirmed result through public transaction evidence.

The first release has two clear paths:

  • Standard Spot: a zero-BOT-value contract action that records 100 commonspot points after a successful receipt. Network gas is still required.
  • Signal Boost: an optional action using exactly 0.01 BOT that brings the wallet to a maximum of 200 points. Network gas is separate.

Points are records, not assets. They cannot be transferred, sold, withdrawn, redeemed, or represented as money. commonspot does not promise a token, airdrop, allocation, snapshot, exchange listing, financial return, or future benefit.

The first release intentionally avoids token approvals, swaps, staking, deposits, custody, bridge integrations, yield strategies, upgradeable contract complexity, and broad administrative control. Its value is a legible, verifiable participation record rather than a financial product.

---

2. Context and Problem#

Many Web3 onboarding experiences are difficult to trust. A user may be asked to connect a wallet, complete a long task list, approve tokens, deposit assets, join multiple social channels, and accept unclear reward language before understanding what the product actually does.

At the same time, many points systems are stored in private databases. Users cannot independently verify when a record was created, whether the rules were applied consistently, or whether a displayed balance is durable.

commonspot addresses a narrower problem:

How can a wallet create one clear, public participation record without turning that record into a tradable financial asset?

The first release answers with a small contract surface, fixed rules, receipt-based confirmation, and direct access to public evidence.

---

3. Vision and Principles#

3.1 Wallet ownership first#

A commonspot record belongs to the connected address. The website does not require a legal name, password, private key, seed phrase, or custodial account.

3.2 Public proof before private promises#

Points are read from contract state. A wallet prompt, loading animation, local browser value, or submitted transaction hash is not treated as final success. The interface waits for a successful receipt and then rereads the contract.

3.3 One clear action at a time#

The Standard Spot is the default path. The optional Signal Boost is visible but not preselected, forced, or framed with urgency.

3.4 Fixed rules#

The first-release point amounts, maximum, and Boost value are fixed in the contract. The interface does not offer an arbitrary amount field.

3.5 Non-transferable by design#

Points cannot be moved between wallets and are not implemented as an ERC-20 or NFT. They are a record of participation, not a market instrument.

3.6 Limited administration#

The owner may pause or unpause new actions in an emergency and may transfer ownership through a two-step process. The owner cannot rewrite individual point balances.

3.7 Honest uncertainty#

Future product directions are described as possibilities, not commitments. No token or airdrop is promised.

---

4. First-Release Scope#

The first release includes:

  • self-custodial wallet connection;
  • supported-network validation and switching;
  • Standard Spot eligibility and claim;
  • direct Signal Boost for a new wallet;
  • Signal Boost upgrade after Standard Spot;
  • account state reads;
  • aggregate protocol counters;
  • a bounded recent-activity view;
  • transaction receipt and evidence links;
  • pending-transaction recovery;
  • a public whitepaper, privacy policy, and terms;
  • responsive deployment through Vercel.

The first release does not include:

  • a token;
  • an NFT;
  • transfers of points;
  • a points marketplace;
  • token approvals;
  • swaps, bridges, staking, lending, or yield;
  • deposits or custody;
  • referral rewards;
  • an airdrop claim;
  • a guaranteed roadmap;
  • a DAO or governance token;
  • a full historical indexer.

---

5. User Experience#

5.1 Standard path#

Open commonspot
→ connect a wallet
→ switch to the supported network when needed
→ review Standard Spot
→ confirm a zero-BOT-value contract transaction
→ pay the separate network gas shown by the wallet
→ wait for a successful receipt
→ reread contract state
→ view 100 confirmed points and public evidence

A wallet connection alone does not silently submit a transaction. After connection, commonspot may open the Standard Spot review immediately, but the user still makes an explicit wallet confirmation.

5.2 Direct Signal Boost#

Open commonspot
→ connect a new wallet
→ choose Signal Boost
→ review exactly 0.01 BOT plus separate network gas
→ confirm in the wallet
→ wait for a successful receipt
→ reread contract state
→ view 200 confirmed points and public evidence

5.3 Upgrade after Standard#

Wallet already holds 100 points
→ choose Signal Boost
→ review exactly 0.01 BOT plus separate network gas
→ confirm
→ wait for a successful receipt
→ reread contract state
→ view 200 total points

5.4 Failure behavior#

If a request is rejected, reverted, times out, or cannot be verified, the interface does not add points. A pending transaction hash remains available so the user can check the public result before retrying.

---

6. commonspot Points#

6.1 First-release rules#

Standard Spot: 100 points
Signal Boost: +100 points
Maximum per wallet: 200 points
Standard Spot limit: one per wallet
Signal Boost limit: one per wallet

6.2 What points are#

commonspot points are non-transferable contract records associated with a public wallet address. They may help the product display whether an address completed the Standard Spot or Signal Boost path.

6.3 What points are not#

Points are not:

  • tokens;
  • money;
  • securities;
  • equity;
  • debt;
  • ownership rights;
  • governance rights;
  • deposits;
  • yield-bearing assets;
  • a claim on Treasury funds;
  • a guaranteed airdrop allocation;
  • a promise of future access or value.

6.4 No transfer or redemption#

The contract does not expose point transfer, approval, withdrawal, sale, burn-for-value, or redemption functions.

6.5 No hidden balance source#

The browser may cache a transaction hash for recovery, but it does not define a wallet's point balance. The contract remains the source of truth.

---

7. Smart Contract Architecture#

The reference first-release contract uses:

  • Solidity 0.8.x;
  • fixed point and fee constants;
  • mappings for Standard and Boost state;
  • aggregate counters;
  • public events;
  • a fixed-capacity recent-activity ring buffer;
  • pausing;
  • two-step ownership transfer;
  • reentrancy protection;
  • an immutable Treasury;
  • direct-transfer and fallback reverts.

7.1 Standard Spot#

claimStandard() accepts zero BOT value only. It rejects duplicate claims and non-zero values. On success, it records 100 points, updates aggregate counters, stores timestamps and block numbers, writes a recent-activity item, and emits an event.

7.2 Signal Boost#

claimBoosted() accepts exactly 0.01 BOT. For a new wallet, it records both the base state and Boost state, producing 200 total points. For a wallet that already holds Standard Spot, it adds the remaining 100 points. Duplicate Boosts and incorrect values revert.

7.3 Treasury forwarding#

A successful Boost forwards the exact protocol value to the immutable Treasury. If delivery fails, the entire transaction reverts and no new points remain recorded.

7.4 Owner powers#

The owner may:

  • pause new Standard and Boost actions;
  • unpause them;
  • begin and complete a two-step ownership transfer.

The owner may not:

  • edit a wallet's points;
  • claim on behalf of a wallet;
  • transfer user assets;
  • change the fixed first-release point amounts;
  • change the fixed first-release Boost value;
  • withdraw user tokens;
  • approve third-party spending.

7.5 Ring buffer#

The recent-activity ring buffer makes a bounded set of newest records available through a read method. It is not a complete historical archive. Events remain available for compatible indexers and archival infrastructure.

7.6 Direct transfers#

Direct BOT transfers and unknown calls revert. The intended paid path is the explicit Signal Boost function so value and state changes remain atomic.

---

8. Settlement Environment#

commonspot runs on an EVM-compatible public settlement environment and uses BOT as the native asset for network gas and the optional Signal Boost value.

The website uses generic public labels such as Supported network, Public ledger, and View transaction. Detailed environment configuration belongs to engineering and deployment documentation rather than the public marketing surface.

A test environment must be used first. A production release may only follow successful contract tests, wallet tests, Treasury validation, legal-copy review, security review, and explicit deployment authorization.

A Preview must not silently represent test activity as production activity.

---

9. Public Data and Verification#

Wallet addresses, transaction hashes, contract addresses, block numbers, timestamps, BOT values, and contract state are public blockchain data.

The website may display:

  • the connected public address;
  • BOT balance;
  • whether the wallet is on the supported network;
  • Standard and Boost state;
  • current points;
  • timestamps and blocks;
  • aggregate counters;
  • bounded recent activity;
  • transaction and address evidence links.

A submitted transaction hash is evidence of submission, not confirmation. The interface waits for a receipt and rereads state.

When the current session or a trusted data source has a transaction hash, commonspot may show it. When a transaction hash is not available from contract reads, the website must not invent one.

---

10. Signal Boost and Treasury#

10.1 Optional value#

Signal Boost is optional. Standard Spot remains available as the default path.

10.2 Exact value#

The first release accepts exactly 0.01 BOT for Signal Boost. Values below or above that amount revert. Network gas is separate.

10.3 Purpose#

The protocol value supports commonspot operations, infrastructure, maintenance, security work, and future product research. This statement does not create a right to services, profit, ownership, reimbursement, or future rewards.

10.4 No investment relationship#

Signal Boost is not an investment, deposit, stake, token purchase, loan, yield product, or claim on Treasury assets.

10.5 Finality#

A confirmed public transaction generally cannot be reversed by the website. Users should review the action and value before confirming.

---

11. Security Model#

11.1 Limited scope#

The contract avoids token approvals, arbitrary token transfers, external DeFi integrations, user deposits, upgradeable proxies, and complex accounting.

11.2 Exact-value enforcement#

The paid path enforces a fixed value. Incorrect values revert.

11.3 Duplicate protection#

Standard and Boost state are recorded per wallet and enforced by the contract.

11.4 Receipt-based success#

The interface does not display success before a successful receipt and state reread.

11.5 Pausing#

Emergency pausing stops new actions but does not delete existing public records.

11.6 Treasury failure#

If the Treasury cannot receive the Boost value, the complete transaction reverts.

11.7 Environment safety#

Missing contract addresses disable transactions. The website does not fall back to a fabricated address or random hash.

11.8 Secret handling#

Deployment private keys are not committed, exposed to the browser, or stored in public Vercel variables. commonspot never requests a user's private key or seed phrase.

11.9 Audit language#

The product must not claim to be audited unless a real, identifiable, publicly available audit has been completed. Testing and limited scope reduce risk but do not remove it.

---

12. Privacy and Data Boundaries#

commonspot does not require a legal name, phone number, profile biography, password, private key, seed phrase, or keystore file.

The application may store non-sensitive pending-recovery data in the browser, including:

  • public wallet address;
  • transaction hash;
  • action type;
  • submission time;
  • expected points;
  • environment identifier.

This local data is not the source of truth for points.

Privacy-conscious analytics should avoid transmitting full wallet addresses. Third-party wallet providers, RPC services, public explorers, analytics providers, and Vercel may apply their own policies.

Because transactions are public, commonspot cannot make a public wallet address or transaction private after confirmation.

---

13. Administration and Operations#

Operational responsibilities include:

  • maintaining the website and Vercel project;
  • verifying current network configuration;
  • approving owner and Treasury addresses;
  • deploying and verifying contracts;
  • monitoring contract and RPC availability;
  • pausing in an emergency;
  • publishing truthful deployment information;
  • maintaining legal and privacy copy;
  • responding to security reports.

Administrative control does not include changing individual points.

Production deployment requires explicit authorization and a documented contract version, owner, Treasury, deployment transaction, verification status, and source commit.

---

14. Roadmap#

The roadmap is directional and may change.

Phase 1 — Public participation record#

  • Standard Spot;
  • Signal Boost;
  • account view;
  • recent activity;
  • public evidence;
  • responsive Vercel release.

Phase 2 — Community spaces#

Potential research may include optional community spaces, richer read-only context, and anti-abuse analysis. Any new mechanism would require product, legal, privacy, and security review.

Phase 3 — Portable integrations#

Potential integrations may allow approved products to read commonspot state through documented, read-only interfaces.

The roadmap does not promise a token, airdrop, snapshot, redemption rate, exchange listing, financial return, or delivery date.

---

15. Risks and Limitations#

Users should understand:

  • smart contracts may contain defects;
  • RPC or wallet providers may be unavailable;
  • transaction fees may change;
  • public transactions cannot be made private;
  • transaction confirmation may be delayed;
  • user error can send a transaction from the wrong wallet;
  • the Treasury address may be externally controlled and must be independently verified by the project;
  • a bounded recent-activity feed is not a full historical index;
  • browser recovery data may be lost;
  • future product direction may change or stop;
  • laws and regulatory interpretations may differ by jurisdiction;
  • no website or contract can guarantee security or future value.

Users should only interact after reviewing the transaction in their own wallet.

---

16. No Token or Airdrop Commitment#

commonspot may explore future community programs. However:

  • no token is promised;
  • no airdrop is promised;
  • no snapshot is promised;
  • no allocation is promised;
  • no eligibility is promised;
  • no conversion rate is promised;
  • no exchange listing is promised;
  • no financial return is promised;
  • points do not create a legal or economic claim.

No statement in the website, roadmap, community channel, interface, or this whitepaper should be interpreted as a commitment to issue or distribute an asset.

---

17. No Financial Advice#

commonspot is not an investment platform, broker, exchange, bank, custodian, portfolio manager, or financial adviser.

Nothing in the product or this document is investment, financial, legal, tax, accounting, or security advice. Users are responsible for their own wallet security, transaction review, legal obligations, and risk decisions.

---

18. Conclusion#

commonspot begins with a deliberately small idea: one wallet should be able to create one clear, public participation record without being pushed into a complex financial product.

The first release prioritizes fixed rules, explicit confirmation, non-transferable points, public evidence, limited administration, and honest language. Its success should be measured by whether a user can understand the action, verify the result, and know exactly what has—and has not—been promised.