Responcoin Whitepaper v1.1

A Wallet-Native Response and Participation Layer on BOT Chain

Version: 1.1 Network: BOT Chain Status: Public Product and Technical Framework Last Updated: September 18, 2026

Important Notice

This Whitepaper describes the current product direction and intended technical framework of Responcoin. It is provided for informational purposes and may change as the product, technical environment, security requirements, ecosystem conditions, and applicable rules evolve.

“Responcoin” is the name of the application. This Whitepaper does not announce or issue an ERC-20 token, a sale, tokenomics, a snapshot, or an airdrop.

Respon Points are non-transferable participation records. They are not tokens, currency, securities, investments, ownership interests, governance rights, claims on project assets, or promises of future value. No token launch, reward distribution, allocation, conversion ratio, financial return, or airdrop is guaranteed.

Nothing in this document constitutes financial, investment, legal, tax, regulatory, brokerage, or trading advice.

1. Abstract

Responcoin is a wallet-native response and participation layer built on BOT Chain.

The first release establishes a narrow public primitive. A self-custodial wallet may complete one Standard Claim to receive 100 non-transferable Respon Points. The same wallet may optionally complete a fixed 0.01 BOT Boost to reach 200 total points. A previously unclaimed wallet may choose the Boosted path directly and establish both the base and boost records through one confirmed transaction.

Each successful action can be inspected through the wallet, contract, transaction receipt, block, and BOT Chain Explorer. The application does not require custody of user assets, a deposit, an ERC-20 approval, a private key, or a seed phrase.

The first release does not attempt to score every response, determine whether one wallet represents one human, or measure a person's social value. It creates a deterministic and inspectable foundation that future community interfaces may read without taking control of user funds.

The first-release flow is:

Connect wallet
→ Switch to BOT Chain
→ Read contract status
→ Select Standard or Boosted
→ Review the exact action
→ Confirm in the wallet
→ Wait for a successful receipt
→ Re-read contract state
→ View 100 or 200 Respon Points
→ Verify through the BOT Chain Explorer

1.1 Public release status

The public website, wallet connection path, account surface, Whitepaper, privacy notice, terms, contract source, ABI, deployment tooling, and automated contract tests form the current verifiable product package.

Live claims are available only when the production environment displays a configured registry address for the active network. If the registry is not configured, the interface must state that clearly and keep claim actions disabled. A public domain, polished interface, local test result, or roadmap statement must never be presented as proof of a Mainnet deployment.

The /status page is the public release checkpoint. It separates completed product evidence from activation dependencies and must be updated when the contract, network, legal review, or live transaction evidence changes.

2. The Problem

Digital participation creates value, but the record of that participation is often fragmented or controlled by one platform.

People answer questions, review products, support communities, verify information, provide feedback, and help ideas move forward. Those contributions may be reduced to temporary feed activity, screenshots, private forms, opaque campaign databases, or platform-owned counters.

This produces several problems.

First, users may see a points balance without knowing which action created it, whether the action can be independently verified, or whether an administrator can change the balance without notice.

Second, projects frequently combine points with speculative language about future tokens, allocations, or rewards. This blurs the boundary between a participation record and a financial promise.

Third, applications that may want to read participation status later often depend on screenshots, private spreadsheets, or undocumented APIs rather than a deterministic public state.

Fourth, Web3 interfaces may request signatures, approvals, deposits, or transactions before explaining the purpose, amount, and risk in plain language.

Responcoin begins with a smaller and clearer question:

Can a response or participation action be represented through a fixed, public, wallet-bound record without taking custody of user assets or promising financial value?

The Genesis Registry is the first answer to that question.

3. Vision

Responcoin's long-term vision is to provide a verifiable response layer for communities, creators, protocols, and applications.

The intended progression has four layers:

1. Wallet identity — a self-custodial wallet is the public account for the action.
2. Participation — a user explicitly chooses and confirms a readable action.
3. Proof — BOT Chain records the transaction and contract state.
4. Application access — future approved interfaces may read deterministic participation status under documented rules.

Responcoin does not claim that all responses should be public, that blockchain proves identity, or that participation automatically equals reputation. The product should distinguish:

• wallet ownership from human identity;
• participation from endorsement;
• public proof from quality judgment;
• a points record from a token;
• current functionality from future exploration.

The first release focuses on fixed participation rather than feature volume.

4. Why BOT Chain

Responcoin uses BOT Chain as the settlement and verification network for the Genesis Registry.

BOT Chain is EVM-compatible, allowing the application to use familiar Ethereum development standards, Solidity contracts, EVM wallets, transaction receipts, and established developer tooling.

The configured networks are:

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

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

BOT is used for network gas. The optional Boost also transfers a fixed 0.01 BOT amount defined by the contract.

Responcoin is an independent application built on BOT Chain. References to BOT Chain, its explorer, wallets, developer tools, or ecosystem products do not imply endorsement, partnership, or official status unless separately announced by the relevant parties.

The listed public Mainnet RPC disables eth_getLogs. Responcoin therefore should not depend on broad historical log scans through that endpoint. Account state and aggregate values should be read from contract view functions. Current transactions should be verified through receipts. Public activity should use a bounded contract-readable record or a separately verified indexer.

5. First-Release Product

A wallet has three possible first-release states.

5.1 Unclaimed

The wallet has not completed a Responcoin Genesis action.

Available choices:

Standard
100 Respon Points
0 BOT contract value
Network gas paid separately

Boosted
200 Respon Points total
Exactly 0.01 BOT
Network gas paid separately

5.2 Standard

The wallet has completed the Standard Claim and holds 100 Respon Points.

The wallet may later complete the optional fixed Boost to add the remaining 100 points and reach the first-release maximum of 200.

5.3 Boosted

The wallet holds the maximum 200 Respon Points available under the first-release rules.

No additional Standard or Boost claim is available.

5.4 Explicit confirmation

Connecting a wallet does not automatically create a transaction or transfer assets.

The application reads the public address and network, then presents the available action. The user must review and explicitly confirm the contract call in the wallet. Points are displayed as confirmed only after a successful receipt and a new contract-state read.

6. The Response Model

The first-release product is organized around a simple response flywheel:

Prompt → Response → Proof → Reputation

6.1 Prompt

A community, creator, protocol, or application opens a question, task, campaign, or participation moment.

The Genesis release does not itself operate a full campaign platform. The Prompt stage represents the broader direction in which a deterministic participation registry may be used.

6.2 Response

A wallet chooses to participate through an explicit, readable, self-custodial action.

The action is not automatically triggered. The user sees the network, contract, BOT value, expected points, gas context, and treasury destination where applicable.

6.3 Proof

A successful BOT Chain transaction creates a public receipt and contract-state change.

The record may include:

• wallet address;
• contract address;
• action type;
• transaction hash;
• block number;
• block timestamp;
• BOT value;
• points added;
• resulting account tier.

6.4 Reputation

Future applications may use a verified participation record as one input into community access, credentials, feedback programs, or other interfaces.

A Responcoin record is not proof of identity, expertise, quality, honesty, endorsement, or financial creditworthiness. Any future reputation interpretation must define its methodology, limitations, permissions, and dispute process separately.

7. Respon Points

Respon Points are non-transferable participation records stored by the Responcoin Genesis Registry.

The first-release rules are:

Base points: 100
Boost points: 100
Maximum points per wallet: 200
Boost payment: exactly 0.01 BOT
Standard limit: once per wallet
Boost limit: once per wallet

Points are not implemented as an ERC-20 token.

They cannot be:

• transferred to another wallet;
• sold;
• withdrawn;
• redeemed for cash;
• deposited;
• staked;
• used as collateral;
• treated as a claim on project assets;
• treated as ownership or governance rights;
• assumed to create eligibility for a future token.

The contract should not expose an administrator function to add, remove, edit, import, or transfer the points of an individual wallet.

The website must use the contract as the source of truth. Browser storage may retain limited pending-transaction metadata, but it must not be the source of truth for a points balance.

8. Optional 0.01 BOT Boost

The Boost is an optional fixed-value participation action.

It is not:

• a deposit;
• a stake;
• a loan;
• an investment;
• a yield product;
• a purchase of a promised token;
• a purchase of a guaranteed future benefit.

The contract accepts exactly 0.01 BOT for a successful Boost. A lower or higher value causes the transaction to revert.

If the wallet has not completed a Standard Claim, the same successful Boosted transaction establishes the base and boost records and results in 200 total points.

If the wallet already holds 100 points, the successful Boost adds the remaining 100 points.

The 0.01 BOT amount is forwarded to the immutable project treasury configured at deployment. The treasury address is public and should be displayed before confirmation. Network gas is paid separately by the wallet.

A confirmed blockchain transfer may be irreversible. Users are responsible for checking the wallet, network, contract, treasury, BOT value, and gas before confirming.

9. Smart Contract Architecture

The proposed contract is:

ResponcoinGenesisRegistry

The contract is intentionally narrow.

9.1 Core state

The registry stores:

• whether a wallet has completed the Standard record;
• whether a wallet has completed the Boost record;
• current points;
• claim timestamps;
• claim block numbers;
• total participating wallets;
• total boosted wallets;
• total points issued;
• total BOT recorded;
• a bounded recent-activity record where implemented.

9.2 Core functions

claimStandard()
claimBoosted()
accountOf(address)
canClaimStandard(address)
canBoost(address)
protocolStats()

9.3 Fixed permissions

The owner may:

• pause new claims during an emergency;
• unpause claims;
• transfer ownership through a two-step process.

The owner should not be able to:

• edit an individual wallet's points;
• award arbitrary points;
• remove points;
• bypass the one-time rules;
• change the fixed Boost fee through a hidden interface;
• silently replace the treasury;
• withdraw a custodial balance from the registry.

9.4 Treasury

The treasury is set at deployment and treated as immutable in the first release.

A successful Boost forwards the exact 0.01 BOT to the treasury. If the transfer fails, the entire transaction should revert and no points should be added.

9.5 Direct transfers

Direct BOT transfers and unknown function calls should revert. Users should interact only through the documented contract functions.

9.6 Events and read functions

The contract emits action events for independent verification.

Because the listed public Mainnet RPC disables eth_getLogs, the first release should not rely on scanning all historical events through that endpoint. Current account state and totals remain available through view functions. A fixed-capacity ring buffer or verified external indexer may provide recent public activity.

10. User Experience and Verification

The product should make transaction intent readable before the wallet confirmation.

10.1 Standard review

The interface displays:

Wallet
Network
Contract action: Standard Claim
BOT value: 0 BOT
Expected points after confirmation: 100
Network gas: estimated in the wallet
Contract address

10.2 Boost review

The interface displays:

Wallet
Network
Contract action: Boosted Claim
BOT value: exactly 0.01 BOT
Expected points after confirmation: 200 total
Network gas: estimated in the wallet
Treasury address
Contract address

10.3 Transaction state

The interface distinguishes:

reviewing
wallet confirmation
submitted
confirming
confirmed
rejected
reverted
insufficient balance
RPC unavailable
contract paused
confirmation timeout

The product must not use a timer to simulate success.

10.4 Receipt verification

A successful state requires:

• a successful receipt;
• the expected sender;
• the configured contract as recipient;
• the expected action;
• the expected BOT value;
• a new contract-state read showing the correct account tier and points.

10.5 Explorer access

After confirmation, the interface provides direct access to the transaction, block, wallet, and contract in the BOT Chain Explorer.

11. Data and Privacy

Wallet addresses, contract calls, transaction hashes, blocks, timestamps, and balances are public blockchain information.

Responcoin may query and display this public information.

The first release does not require Responcoin to collect or store:

• private keys;
• seed phrases;
• keystore files;
• unrestricted token approvals;
• custodial deposits.

For pending-transaction recovery, the browser may temporarily store:

transaction hash
wallet address
chain ID
action type
submission time

It must not store:

• private keys;
• seed phrases;
• wallet signatures;
• authentication secrets;
• deployment credentials.

RPC providers, wallet providers, WalletConnect, explorers, hosting providers, analytics providers, and browsers may process technical information under their own policies.

Any analytics, cookies, logging, account feature, email collection, or third-party tracking must be disclosed before use.

Disconnecting a wallet from the website does not remove public blockchain records.

12. Security Principles

12.1 Self-custody

Users retain control of their wallets and assets. Wallet confirmations occur in the user's wallet interface.

12.2 Minimal permissions

The first release does not require ERC-20 approval, NFT approval, token allowance, deposit, swap, staking, lending, or custody.

12.3 Fixed scope

The registry limits the maximum first-release balance to 200 points and limits each action to one completion per wallet.

12.4 Simulation before submission

The frontend should simulate the contract call before requesting a wallet transaction where supported.

12.5 Confirmation before credit

Points are shown as confirmed only after a successful receipt and state read.

12.6 Failure transparency

RPC, wallet, browser, explorer, contract, indexer, or hosting failures must produce explicit unavailable or failed states. Missing data must not be replaced with a fabricated result.

12.7 Secret management

Deployment keys, owner keys, treasury controls, WalletConnect secrets, and server credentials must not be included in the public frontend bundle or repository.

12.8 Testing and deployment

The contract should be:

• unit tested;
• fuzz or invariant tested where practical;
• deployed to BOT Chain Testnet first;
• exercised through real Testnet transactions;
• reviewed before Mainnet;
• deployed to Mainnet only after explicit authorization;
• accompanied by the real contract address, deployment transaction, block, and Explorer link.

12.9 No absolute security claim

No smart contract, wallet, RPC endpoint, indexer, browser, or application is risk-free. Responcoin must not describe itself as fully secure, guaranteed safe, or immune to failure.

13. Future Response Interfaces

A deterministic participation registry may support future interfaces, subject to separate design, testing, security review, data policy, and legal review.

Potential directions include:

13.1 Community campaigns

Communities may publish clear participation definitions with fixed rules, start and end conditions, and public contract references.

13.2 Creator feedback

Creators may explore wallet-verifiable feedback or access programs without requiring the application to custody user assets.

13.3 Protocol participation

Protocols may expose documented read-only interfaces for approved applications to inspect participation status.

13.4 Credentials

Signed or contract-readable credentials may represent selected participation categories under versioned schemas.

13.5 Agent-readable access

Software applications or agents may read deterministic status through documented interfaces with authentication, permissions, rate limits, reliability targets, schema versioning, monitoring, and explicit unavailable states.

These directions are not live capabilities or delivery promises in the Genesis release.

14. Roadmap

The roadmap describes intended direction and may change.

Phase 1 — Genesis Registry

• template-based public website;
• original Responcoin brand;
• BOT Chain wallet connection;
• network switching;
• Standard Claim;
• optional 0.01 BOT Boost;
• Account;
• public verification;
• Whitepaper;
• Privacy and Terms;
• tests;
• Vercel deployment.

Phase 2 — Response Interfaces

Potential work:

• versioned campaign definitions;
• response categories;
• improved account portability;
• public read APIs;
• stronger observability;
• explicit provider-health states.

Phase 3 — Verified Credentials

Potential work:

• signed credentials;
• permissioned application access;
• schema versioning;
• credential revocation or migration rules;
• privacy and disclosure controls.

Phase 4 — Ecosystem Integrations

Potential work:

• verified protocol adapters;
• source-linked response records;
• approved application interfaces;
• agent-readable status;
• documented security and failure assumptions.

Roadmap items do not guarantee delivery dates, token rewards, or future benefits.

15. Token and Airdrop Policy

Responcoin has not announced a token through this Whitepaper.

Respon Points:

• are not a token;
• do not establish eligibility for a future token;
• do not establish a contractual right to an airdrop;
• do not have a conversion ratio;
• do not have an announced market value;
• do not create governance rights;
• do not create ownership rights;
• do not create a promise of financial return.

No snapshot date, allocation formula, reward schedule, token value, or guaranteed benefit is defined.

A future change, if any, would require a separate public announcement, updated rules, technical review, security review, and legal review. It must not be inferred from the first-release points balance.

16. Governance and Operations

The Genesis release is operated as an application and contract, not as a decentralized governance protocol.

Operational decisions may include:

• security fixes;
• service suspension;
• contract pause;
• frontend updates;
• RPC changes;
• explorer changes;
• legal-text updates;
• roadmap prioritization;
• contract migration where necessary.

The contract owner should be a project-controlled address confirmed before Mainnet deployment. A developer's personal wallet should not be substituted as the permanent owner without explicit project authorization.

Any material contract migration or points-rule change should be announced with the relevant addresses, versions, effective date, and user impact.

17. Risk Factors

17.1 Smart contract risk

Code defects may cause a claim to fail, a transfer to revert, or state to be recorded incorrectly.

17.2 Wallet risk

Users are responsible for wallet security and for reviewing transaction prompts.

17.3 Network risk

BOT Chain congestion, reorganization, RPC outages, protocol changes, or explorer outages may affect the application.

17.4 Treasury risk

The Boost forwards BOT to the configured treasury. A wrong treasury configuration, unavailable recipient, or transfer failure may affect the action. A successful irreversible transfer may not be refundable.

17.5 Data risk

RPC, indexer, explorer, or browser data may be delayed, incomplete, inconsistent, or unavailable.

17.6 Application risk

Hosting, frontend, dependency, wallet connector, or software failures may prevent access.

17.7 Privacy risk

Wallet activity is public. Linking a wallet to external identities may reduce privacy.

17.8 Sybil and identity risk

One wallet does not necessarily represent one human. One human may control multiple wallets. The Genesis Registry does not solve identity verification or Sybil resistance.

17.9 Interpretation risk

A Responcoin record proves a defined contract action, not expertise, honesty, quality, endorsement, creditworthiness, or human value.

17.10 Regulatory risk

Rules affecting digital assets, points programs, wallets, payments, privacy, and decentralized applications may change.

17.11 Roadmap risk

Planned features may be delayed, changed, or cancelled.

17.12 Points risk

Points may never be associated with any additional use or benefit.

18. No Financial Advice

Responcoin does not provide investment, trading, brokerage, legal, tax, or financial advice.

Nothing in the application or Whitepaper is a recommendation to purchase BOT or any other asset. Users should independently evaluate blockchain transactions, network fees, contract risk, wallet risk, applicable law, and tax treatment.

References to BOT Chain or ecosystem products do not constitute endorsement.

19. Conclusion

Responcoin begins with a narrow and inspectable foundation:

one self-custodial wallet
one Standard record
one optional fixed Boost
a maximum of 200 non-transferable points
a public BOT Chain receipt
a readable product boundary

The value of the first release depends on accurate contract behavior, honest marketing, clear transaction review, reliable status handling, transparent points rules, and a website that distinguishes live functionality from future exploration.

Responses matter. The first step is to record participation without taking control away from the user.