1. Abstract
barkerapp is a wallet-native participation layer built on BOT Chain. It gives users a simple way to create a public, verifiable participation record without creating a custodial account or transferring control of their wallet.
In the first release, a wallet may complete one standard contract call to receive 100 non-transferable Barkerapp Points. The same wallet may optionally pay a fixed 0.01 BOT participation fee to receive an additional 100 points, bringing the maximum first-release balance to 200 points. A new wallet may select the boosted path directly and receive both the base and boost points in one confirmed transaction.
barkerapp does not issue a token, promise an airdrop, route yield, execute trades, custody deposits, or offer an investment product. The first release establishes a narrow public primitive that can be inspected by users and, in later stages, read by controlled software interfaces and agents.
2. The Problem
Web3 participation is often represented through private databases, browser state, screenshots, campaign forms, or unclear eligibility language. Users may see a points balance without knowing which action created it, whether the record can be independently verified, or whether the project can modify it without notice.
Projects also frequently combine points with speculative language about future tokens or rewards. This creates ambiguity between a participation record and a financial promise. A useful on-chain participation layer should make the current rule simple, the transaction visible, the maximum balance clear, and the limits explicit.
The agent economy adds another requirement. As applications and autonomous agents interact with on-chain systems, they need deterministic records that can be read through a contract or a documented interface. A public record is more useful than an unverifiable claim stored only inside one website.
3. Vision
barkerapp aims to become a lightweight access primitive for the BOT Chain agent economy: one wallet, one public participation profile, and a clear path for future applications to read verified status without taking custody of user assets.
- Self-custodial wallet access.
- Deterministic points rules.
- An optional fixed-value on-chain boost.
- Contract-based account status.
- Public transaction verification.
- An explicit boundary between live functionality and future exploration.
Future versions may explore controlled agent access, ecosystem campaigns, participation credentials, or verified protocol integrations. These directions are not promises and will require separate technical, security, product, and legal review.
4. Product Principles
Public proof before private promises.
A displayed balance must be supported by contract state and a confirmed transaction.
Fixed rules before flexible marketing.
The base allocation, boost allocation, maximum points and boost fee are defined by the contract rather than an editable campaign interface.
Self-custody before convenience.
barkerapp does not request seed phrases, private keys, token approvals or custody of user deposits.
Clear limits before speculation.
Points are participation records. The current product does not define a token conversion, airdrop formula, financial return, governance right or ownership claim.
Live functionality before roadmap language.
Features that are not deployed and verified must be presented as exploration, not as active capabilities.
5. First-Release Product
Connect wallet → Switch to BOT Chain → Read current contract status → Choose a standard or boosted claim → Review the exact transaction → Confirm in the wallet → Wait for a successful receipt → Read the updated points balance → Verify in the BOT Chain Explorer
Unclaimed
The wallet may claim 100 points with a zero-value contract call or select the 0.01 BOT boosted path and receive 200 total points.
Standard
The wallet holds 100 points and may still pay 0.01 BOT to add the remaining 100 boost points.
Boosted
The wallet holds the maximum 200 points available under the first-release rules. No further claim is available.
6. BOT Chain Integration
barkerapp uses BOT Chain as the settlement and verification network for the participation record. BOT is the native network asset used for gas and for the optional fixed boost payment.
The application is designed for BOT Chain Mainnet and Testnet through explicit environment configuration. The frontend verifies the connected chain, offers a network switch when required, simulates contract calls before requesting confirmation, waits for a successful receipt, and exposes direct links to the BOT Chain Explorer.
The wallet remains self-custodial. barkerapp never asks the user to disclose a private key, seed phrase or unrestricted token approval.
7. Barkerapp Points
Barkerapp Points are non-transferable participation records stored by the Barkerapp Genesis Registry contract.
Base points: 100 Boost points: 100 Maximum points per wallet: 200 Boost payment: exactly 0.01 BOT Base claim limit: once per wallet Boost claim limit: once per wallet
Points are not implemented as an ERC-20 token. They cannot be transferred, sold, withdrawn, redeemed for cash, used as a deposit balance, or treated as a claim on Barkerapp ownership.
The contract does not expose an administrator function to add, remove or edit the points of an individual wallet. Points change only through the fixed standard and boost functions.
8. Optional 0.01 BOT Boost
The boost is an optional participation action. It is not a deposit, stake, yield product, loan, investment or purchase of a promised financial return.
The contract accepts exactly 0.01 BOT for the boost. A lower or higher value causes the transaction to revert. After a successful transaction, the wallet receives 100 additional points. If the wallet had not already claimed its base points, the same transaction also creates the 100-point base record, resulting in 200 total points.
The 0.01 BOT payment is forwarded to the project treasury configured when the contract is deployed. The treasury address is public and can be inspected on-chain. Network gas is paid separately by the wallet.
9. Smart Contract Architecture
The Barkerapp Genesis Registry is intentionally narrow. It stores claim status, points, timestamps, block numbers, protocol totals and a bounded list of recent activity.
The contract uses fixed rules for base and boost participation. It emits events for independent indexing and exposes view functions for the website to read account status and aggregate statistics.
The owner may pause or unpause new claims during an emergency and may transfer ownership through a two-step process. The owner cannot manually change user points. The treasury is set at deployment and is not silently replaced through the website.
The contract does not route assets to external yield protocols, perform swaps, mint tokens, custody stablecoin deposits or execute agent strategies.
10. Security and User Control
The frontend must simulate the contract call before requesting a wallet transaction. It must display the network, contract action, BOT value, expected points and treasury destination before the user confirms a boosted claim.
Points are displayed as confirmed only after the transaction receipt reports success and the application re-reads the contract state. Rejected, reverted, timed-out or failed transactions do not increase the balance.
Blockchain and wallet software can fail. RPC endpoints, explorer services, wallets, browsers and third-party infrastructure may be unavailable. Users are responsible for reviewing the connected wallet, network, contract address, payment amount and transaction details before signing.
11. Data and Privacy
Wallet addresses, contract calls, transaction hashes, block numbers and block timestamps are public blockchain data. barkerapp may read and display this information to the connected user and in the public activity interface.
The first release does not require a traditional account database, custody of personal funds, collection of private keys, or storage of seed phrases. Basic analytics may be used only when disclosed in the Privacy Policy.
Pending transaction recovery may store a transaction hash, wallet address, chain ID, action type and submission time in local browser storage. It must not store private keys, seed phrases, signatures or authentication secrets.
12. Agent-Ready Direction
A deterministic participation registry can become useful to software applications and agents because the status can be read through contract view functions instead of interpreted from an image or private campaign spreadsheet.
Future work may explore read-only APIs, controlled agent access, signed participation credentials, ecosystem campaign interfaces or verified protocol adapters. Before any such capability is represented as live, barkerapp must define authentication, permissions, rate limits, reliability, failure states, data provenance and security boundaries.
No autonomous financial execution is included in the first release.
13. Roadmap
Foundation
Template-based public website, original Barkerapp brand, BOT Chain wallet connection, standard points claim, optional 0.01 BOT boost, account profile, public activity, Whitepaper, legal pages, contract tests and Vercel deployment.
Participation Interfaces
Improved account portability, read-only status endpoints, campaign configuration with fixed and publicly disclosed rules, and stronger observability.
Agent Access
Controlled read interfaces for approved applications and agents, with permissions, rate limits, monitoring and documented failure behavior.
Verified Ecosystem Integrations
Integrations may be considered only when protocol addresses, data sources, security assumptions and user risks can be independently verified. This roadmap expresses direction and does not promise delivery dates, token rewards or future benefits.
14. Token and Airdrop Policy
barkerapp has not announced a token through this Whitepaper. Barkerapp Points are not a token and do not establish eligibility for a future token.
No airdrop is promised. No snapshot date, allocation formula, conversion ratio, expected token value, reward schedule, governance right or financial return is defined. A points balance does not create a contractual right to any future benefit.
Any future change would require a separate public announcement, updated rules, technical review and legal review. Such a change must not be inferred from the first-release points balance.
15. Risks and Disclaimers
Blockchain transactions may be irreversible. Users must review the wallet, network, contract address, treasury address, BOT value and gas estimate before signing.
The optional 0.01 BOT payment is not refundable after a successful irreversible transaction unless the project publishes a separate policy. It is not a deposit and does not earn interest or financial return.
Smart contracts may contain defects. Wallets, RPC providers, explorers, browsers and infrastructure may fail or become temporarily unavailable. A contract pause, network issue or treasury transfer failure may prevent a claim.
barkerapp does not provide brokerage, investment, financial, legal or tax advice. Nothing in the interface or Whitepaper should be interpreted as a promise of profit, token value, airdrop eligibility or protocol ownership.
16. Conclusion
barkerapp begins with a narrow and inspectable foundation: a self-custodial wallet, a fixed participation rule, an optional fixed BOT boost, a maximum points balance and a public transaction record.
The value of the first release depends on accurate contract behavior, honest product boundaries, clear transaction review, reliable status handling and a website that distinguishes what is live from what is only being explored.