TESTNET-READY BUILD — NO TOKEN OR AIRDROP HAS BEEN ANNOUNCED
vdecoty
Connect Wallet

WHITEPAPER // VERSION 0.1

Read the model.

Profile rules, contract architecture, security assumptions, privacy boundaries and risks—presented in full, without investment language.

← Back to App
Table of contents

VDECOTY WHITEPAPER#

A Wallet-Native Identity and Participation Layer on BOT Chain#

**Version:** 0.1 **Publication date:** 29 August 2026 **Status:** Product and technical specification; not a token offering **Language:** English

---

Important Notice#

This document describes the intended design of Vdecoty. It is provided for product, technical, and community information only. It is not investment advice, legal advice, tax advice, a prospectus, an offer to sell, or a solicitation to buy any security, token, financial instrument, or investment product.

Vdecoty Points are non-transferable participation records. They are not cryptocurrency, securities, equity, debt, deposits, stored value, money, or claims against Vdecoty, BOT Chain, or any third party. They have no cash value and do not guarantee access, allocation, conversion, governance, yield, reimbursement, an airdrop, or any other future benefit.

No Vdecoty token or airdrop is announced or promised by this whitepaper. Vdecoty may research future community programs, but such research does not create an obligation to launch a program, use points as eligibility, recognize past activity, apply a particular formula, serve any jurisdiction, or provide economic value.

Blockchain transactions are public and generally irreversible. Users are responsible for reviewing the network, contract address, payment amount, and gas estimate shown by their wallet. Smart-contract interaction involves technical and operational risk. Until a public independent audit report exists, the website must state that the contract has not been independently audited.

---

Abstract#

A blockchain wallet is a strong ownership primitive, but a wallet address alone provides little human-readable context. Communities often rely on fragmented transaction histories, centralized campaign databases, unverifiable screenshots, or speculative point systems to understand participation. This makes it difficult for users to know what a score means and difficult for communities to distinguish a real onchain action from a frontend claim.

Vdecoty is a wallet-native identity and participation layer built for BOT Chain. Its initial product is intentionally narrow: a user connects an EVM-compatible wallet, reviews a transparent activation choice, completes a transaction, and receives a simple public profile state with non-transferable participation points.

The base path records a Standard profile with 100 points through a zero-value contract call for which network gas still applies. The optional Boosted path requires exactly 0.01 BOT plus gas and records 200 points. A Standard profile may upgrade once by paying 0.01 BOT plus gas, bringing the same wallet to 200 points. Each address can activate once and can boost at most once.

The contract, rather than the interface alone, is the source of truth for profile tier and points. A final balance appears only after a successful confirmation. Points cannot be transferred, approved, sold, withdrawn, or exchanged through the contract. This design focuses on verifiable participation instead of financial speculation.

---

1. Context#

1.1 Wallets prove control, not context#

A public address can demonstrate control over assets and show a history of transactions, but it does not automatically explain why those transactions matter. Raw histories are difficult to read, may contain unrelated activity, and usually require an explorer or indexer to interpret. A community may know that an address exists without knowing whether it completed a defined product action.

Vdecoty introduces a minimal profile record that answers four narrow questions:

  1. Has this wallet activated a Vdecoty profile?
  2. Is the profile Standard or Boosted?
  3. How many Vdecoty Points are recorded for the wallet?
  4. Which BOT Chain transaction produced the state?

The system does not attempt to score a person’s identity, reputation, wealth, social value, creditworthiness, or legal status. It records only defined interactions with the Vdecoty contract.

1.2 The problem with opaque points#

Many digital point systems are easy to display but difficult to verify. A frontend can show a number without explaining whether it came from a database, a signed message, a transaction, an administrator, or a marketing campaign. Rules may change silently, and users may assume a point has future value even when no such value exists.

Vdecoty addresses this problem with a deliberately limited model:

  • the initial issuance rules are public;
  • the state transition is enforced by a contract;
  • final points require a successful transaction;
  • each wallet has a capped path;
  • points are not transferable;
  • no conversion or airdrop is promised;
  • live statistics must come from contract state or remain zero.

1.3 Why a narrow first release#

A profile layer can become complex quickly. Social graphs, account recovery, attestations, messaging, reputation, privacy, sybil resistance, governance, and cross-chain identity each introduce distinct risks. Vdecoty begins with one small, understandable primitive rather than presenting an unfinished feature set as a complete identity protocol.

The initial release is therefore an onchain profile activation and points registry, accompanied by clear receipts, disclosures, and a public whitepaper. Future capabilities remain research topics unless separately shipped and documented.

---

2. Vision and Design Principles#

2.1 Vision#

Vdecoty aims to make wallet participation easier to understand without taking custody, creating a tradable point asset, or relying on speculative promises. The long-term product direction is a portable profile that can expose user-approved, verifiable records to communities and applications.

The phrase “turn a wallet into a signal” describes this goal: a wallet remains an address controlled by its owner, while a small number of explicit records make selected participation easier to interpret.

2.2 User control#

Vdecoty is non-custodial. It connects to a user’s existing compatible wallet and asks the wallet to sign a specific transaction. Vdecoty must never request a seed phrase, recovery phrase, private key, keystore file, remote-control session, or unrestricted token approval.

The user chooses whether to activate, which tier to select, and whether a Standard profile should later be boosted. Wallet disconnection does not delete onchain state, because confirmed blockchain records remain public.

2.3 Visible rules#

The interface must show the following before opening a transaction prompt:

  • selected network;
  • connected address;
  • published contract address;
  • selected action;
  • contract payment amount;
  • estimated gas, shown separately where available;
  • expected profile tier;
  • expected points after confirmation;
  • points and airdrop disclosures.

The wallet prompt remains the final transaction review. Users should reject any prompt that differs from the application’s review screen.

2.4 Contract-confirmed state#

A submitted transaction is not a confirmed result. Vdecoty distinguishes at least the following states:

  • prepared;
  • awaiting wallet approval;
  • rejected by the user;
  • submitted;
  • pending;
  • confirmed;
  • reverted or failed;
  • contract state refreshed.

The final profile and points display must be derived from a contract read after confirmation. A transaction hash alone is not sufficient if the transaction reverted.

2.5 Minimal economic claims#

The optional 0.01 BOT payment is a product interaction that selects or upgrades the Boosted profile tier. It is not an investment and must not be described as purchasing a token, equity, ownership, yield, a guaranteed allocation, or access to an airdrop.

No chart, countdown, scarcity meter, price appreciation claim, estimated reward, annual percentage yield, return calculation, or token-conversion preview belongs in the initial product.

2.6 Originality and independence#

Vdecoty is an original product and brand. Reference products may inform general interaction patterns, but Vdecoty must not copy another project’s source code, logo, protected artwork, proprietary copy, or trade dress. Vdecoty must not imply official affiliation with BOT Chain or any reference product without written permission.

---

3. Product Scope#

3.1 Initial product surfaces#

The first release contains four primary surfaces:

  1. **Public landing page** — explains the model, points, network, risks, roadmap, and frequently asked questions.
  2. **Activation application** — connects a wallet, reads profile state, presents Standard and Boosted paths, submits a transaction, and displays a receipt.
  3. **Public profile view** — displays a wallet’s Vdecoty tier, points, activation block or transaction, network, and last refreshed state.
  4. **Whitepaper and legal pages** — document architecture, points limitations, transaction risk, privacy, and terms.

3.2 Explicitly out of scope for the initial release#

The following are not part of the first release unless later approved through a separate specification and security review:

  • custody of user assets;
  • creation of embedded wallets;
  • seedless or social recovery;
  • a Vdecoty fungible token;
  • NFT minting or sale;
  • token swaps, bridges, staking, lending, leverage, or yield;
  • automatic trading or financial advice;
  • guaranteed rewards or airdrops;
  • transferable points;
  • administrative editing of user points;
  • biometric identity, KYC, credit scoring, or legal identity verification;
  • private messaging or a full social feed;
  • cross-chain state synchronization;
  • permissionless third-party writes to profiles.

3.3 Optional profile metadata#

A future release may allow a user to add optional public fields such as a display name, avatar, short biography, or public social links. Such fields should remain separate from the immutable activation record and must have clear privacy, moderation, storage, deletion, and verification rules.

An unverified social link must never be presented as a verified identity. Verification should require an explicit proof flow, not a text field alone.

---

4. User Journey#

4.1 Connection#

The user selects “Connect Wallet” and chooses an approved EVM-compatible connector. Connection exposes the currently selected wallet address and chain to the application. It does not itself transfer funds.

The application immediately checks:

  • whether the connected chain is BOT Chain;
  • whether the configured contract address contains bytecode;
  • whether the ABI and expected contract version match;
  • the wallet’s current profile tier;
  • the wallet’s current points;
  • whether activation or boost remains available.

A connected wallet may be shown “100 points available,” but this is only a preview of the Standard path. It must not be displayed as a final points balance until activation is confirmed.

4.2 Network switching#

If the wallet is on another network, the interface requests a switch to BOT Chain. If the network is absent from the wallet, the interface may offer an add-network request using current official values.

The application must never silently submit to another chain, and production must never fall back to Testnet settings.

4.3 Standard activation#

The Standard path calls `activateStandard()` with no contract payment. The user still pays the network gas estimated by the wallet.

Upon a successful transaction, the contract records:

  • tier: Standard;
  • points: 100;
  • participant count: incremented once;
  • total points issued: increased by 100.

A duplicate Standard activation reverts.

4.4 Direct Boosted activation#

The direct Boosted path calls `activateBoosted()` with exactly 0.01 BOT. Gas is additional.

Upon success, the contract records:

  • tier: Boosted;
  • points: 200;
  • participant count: incremented once;
  • boost count: incremented once;
  • total points issued: increased by 200;
  • payment forwarded to the configured treasury.

An incorrect payment or duplicate activation reverts.

4.5 Standard-to-Boosted upgrade#

A wallet with a Standard profile may call `boost()` once with exactly 0.01 BOT plus gas.

Upon success:

  • tier changes from Standard to Boosted;
  • points increase from 100 to 200;
  • boost count increases once;
  • total points issued increases by 100;
  • payment is forwarded to the configured treasury.

A wallet with no profile or an already Boosted profile cannot call the upgrade successfully.

4.6 Confirmation and receipt#

The interface waits for transaction confirmation, then reads the contract again. The result screen displays:

  • confirmed tier;
  • confirmed points;
  • transaction hash;
  • block explorer link;
  • contract address;
  • network;
  • block number where available.

The interface must not award points in local storage, analytics, or a database as a substitute for contract confirmation.

---

5. Points Model#

5.1 Definition#

Vdecoty Points are non-transferable integers stored as part of the profile contract state. They summarize only the wallet’s Vdecoty activation path.

Let:

  • `S = 100`, the Standard points total;
  • `B = 200`, the Boosted points total;
  • `P = 0.01 BOT`, the Boosted contract payment, excluding gas.

The permitted state transitions are:

None     -> Standard  : payment 0 BOT + gas; points 100
None     -> Boosted   : payment P + gas; points 200
Standard -> Boosted   : payment P + gas; points +100, total 200
Boosted  -> no further tier transition

There is no transition from Standard or Boosted back to None, and no repeated issuance path.

5.2 Non-transferability#

The contract exposes no `transfer`, `transferFrom`, `approve`, allowance, market, withdrawal, or redemption function for points. Points cannot be sent to another address and do not follow assets transferred between wallets.

This means a user should choose the wallet carefully. Losing access to the wallet does not create a right to move the points to another address.

5.3 No cash value#

Points are not denominated in currency and have no contractual redemption value. The number 100 or 200 reflects a product state, not a price, account balance, or claim.

The optional payment does not establish a conversion rate. It would be incorrect to state that one point is worth any fraction of BOT or that 200 points represent a 0.01 BOT asset.

5.4 No promised future utility#

Vdecoty may research future community experiences. However:

  • no future program is required to use points;
  • a future program may use criteria unrelated to points;
  • prior points may be excluded;
  • jurisdiction, compliance, sybil, timing, or technical rules may apply;
  • a program may be modified or cancelled;
  • no economic value is promised.

5.5 Statistics#

If the interface displays aggregate statistics, they must be read from the deployed contract or a verifiable indexer built from that contract. Before a deployment or when reads fail, the interface should display zero, unavailable, or a loading state—never fabricated adoption numbers.

Permitted aggregate fields include:

  • total active profiles;
  • total Boosted profiles;
  • total points recorded;
  • current network and contract address.

---

6. Technical Architecture#

6.1 High-level components#

The initial architecture contains:

  1. **Frontend application** — renders the landing page, app, profile, whitepaper, and legal routes.
  2. **Wallet connection layer** — discovers approved EVM wallets, reads account and chain state, and requests transactions.
  3. **BOT Chain RPC layer** — performs direct contract reads, estimates gas, sends user-signed transactions, and waits for receipts.
  4. **Vdecoty Points contract** — stores profile tier and points and enforces activation rules.
  5. **Block explorer links** — let users independently verify contract and transaction data.
  6. **Optional indexer or backend** — may be introduced only when necessary for efficient aggregate or historical views.

6.2 Frontend implementation constraints#

The final application must be implemented inside the complete template supplied by the product owner. The existing framework, package manager, lockfile, route foundation, component organization, primary layout, responsive behavior, and animation language must be preserved.

The implementation must not create an unrelated scaffold and paste a few template assets into it. Before changes begin, Codex must inventory every major template section and map each one to a Vdecoty use.

Web3 libraries should be selected for compatibility with the supplied repository. Where appropriate, `viem` and `wagmi` may provide chain, account, read, write, and receipt primitives. WalletConnect/Reown support requires a real project identifier. The application must also support an approved injected-wallet path where compatible.

6.3 Read strategy#

The frontend reads current state directly from the contract using functions such as:

  • `pointsOf(address)`;
  • `tierOf(address)`;
  • `totalParticipants()`;
  • `totalBoosts()`;
  • `totalPointsIssued()`;
  • `treasury()`;
  • `paused()`.

Broad historical event scanning should not be required for the core wallet experience. The official BOT Chain Mainnet RPC documentation indicates that `eth_getLogs` may be disabled on the official endpoint. If historical activity becomes necessary, Vdecoty should use a deliberately configured third-party endpoint, WebSocket subscription, or indexer rather than repeatedly scanning logs from the browser.

6.4 Write strategy#

The user’s wallet signs all state-changing calls. The frontend must:

  1. validate chain and contract configuration;
  2. read the current tier immediately before preparing the action;
  3. show transaction review details;
  4. call the exact contract function with the exact value;
  5. store the transaction hash only as pending state;
  6. wait for a successful receipt;
  7. refresh contract state;
  8. present the final tier and points.

Client-side buttons must be disabled while the transaction is pending to reduce duplicate submissions. The contract remains the ultimate duplicate-prevention layer.

6.5 Optional backend#

The initial profile activation does not require a backend database. A backend may later support:

  • cached aggregate data;
  • human-readable public profile slugs;
  • optional user-approved metadata;
  • abuse controls;
  • announcements;
  • program eligibility rules if a real program is separately launched.

A backend must never be used to overwrite or impersonate the contract-confirmed points balance. Any offchain fields must be clearly separated from onchain fields.

---

7. Smart-Contract Design#

7.1 Contract responsibilities#

The reference contract is responsible for:

  • enforcing one activation per address;
  • enforcing one Standard-to-Boosted upgrade;
  • enforcing the exact Boosted payment;
  • recording tier and points;
  • updating transparent aggregate counters;
  • forwarding Boosted payments to a configured treasury;
  • allowing an authorized owner to pause writes in an emergency;
  • allowing a two-step owner transfer;
  • emitting events for confirmed state changes.

7.2 Contract non-responsibilities#

The contract does not:

  • custody arbitrary user tokens;
  • request ERC-20 approvals;
  • implement a token;
  • transfer points;
  • calculate future eligibility;
  • promise a reward;
  • maintain social handles;
  • recover a user wallet;
  • conceal transactions;
  • guarantee RPC or frontend availability.

7.3 Ownership and treasury#

The owner and treasury are separate roles in the reference model:

  • the **owner** can pause or unpause activation and initiate a two-step ownership transfer;
  • the **treasury** receives Boosted payments;
  • the owner may update the treasury to a nonzero address through a public transaction.

Production should use carefully controlled addresses. A multisignature wallet should be considered for ownership and treasury roles. The final addresses must be documented before Mainnet deployment.

7.4 Payment forwarding#

The reference implementation forwards the exact 0.01 BOT payment to the treasury during the same transaction. If forwarding fails, the entire activation or boost reverts, preventing a state where points are issued but the configured payment destination did not receive funds.

Direct transfers to the contract are rejected to reduce accidental balances and accounting ambiguity.

7.5 Events#

The reference event set includes:

  • `ProfileActivated(address indexed account, Tier tier, uint256 points, uint256 payment)`;
  • `ProfileBoosted(address indexed account, uint256 previousPoints, uint256 newPoints, uint256 payment)`;
  • `TreasuryUpdated(address indexed previousTreasury, address indexed newTreasury)`.

Events are useful for indexing and receipt interpretation, but direct state reads remain the primary source for the current profile.

7.6 Pausing#

An emergency pause blocks new Standard activations, direct Boosted activations, and upgrades. It does not delete existing profiles. The interface must read `paused()` and disable transaction actions with a clear explanation.

Pausing is an operational safeguard, not proof that every vulnerability can be mitigated.

7.7 Upgradeability#

The initial reference contract is intentionally non-upgradeable. This reduces proxy complexity and makes the deployed logic easier to inspect. If a later release requires upgradeability, it must use a separate architecture review, audit, governance policy, storage-layout plan, and user disclosure.

---

8. BOT Chain Integration#

8.1 Network role#

BOT Chain is the execution and settlement network for Vdecoty profile activation. BOT is used for gas and for the optional Boosted payment.

The documented environments at the time of this whitepaper are:

EnvironmentChain IDRPCExplorerNative gas asset
BOT Chain Testnet968`https://rpc.bohr.life``https://scan.bohr.life`Test BOT
BOT Chain Mainnet677`https://rpc.botchain.ai``https://scan.botchain.ai`BOT

All values must be rechecked against current official documentation before deployment.

8.2 EVM compatibility#

BOT Chain documentation describes the network as EVM-compatible. This enables Vdecoty to use Solidity contracts and established Ethereum-compatible wallet tooling, while still requiring BOT Chain-specific chain configuration and testing.

EVM compatibility does not remove the need to test RPC behavior, gas estimation, wallet switching, explorer links, receipt timing, and contract deployment in both Testnet and Mainnet environments.

8.3 Environment separation#

Testnet and Mainnet configuration must remain independent. At minimum, the application stores separate values for:

  • chain ID;
  • RPC URL;
  • explorer URL;
  • contract address;
  • contract deployment block;
  • owner address;
  • treasury address;
  • release label.

Production must fail closed when the Mainnet contract address is absent or invalid. It must not silently substitute the Testnet contract.

8.4 Testnet-first policy#

The expected release sequence is:

  1. compile and test the contract locally;
  2. deploy to BOT Chain Testnet;
  3. verify source code where supported;
  4. connect the template-integrated frontend to Testnet;
  5. test all wallet and transaction states;
  6. publish a Vercel Preview labelled Testnet;
  7. complete security and product QA;
  8. obtain explicit Mainnet authorization and final addresses;
  9. deploy and verify Mainnet contract;
  10. publish production configuration and final release evidence.

---

9. Privacy and Data Boundaries#

9.1 Public blockchain data#

The following information is public by design when a wallet interacts with Vdecoty:

  • wallet address;
  • transaction hash;
  • block number and timestamp;
  • contract address;
  • transaction value and gas data;
  • profile tier;
  • points balance;
  • emitted events.

Users should not activate with an address they do not want associated with this public activity.

9.2 Frontend and analytics data#

The initial release should minimize collection. Analytics, if enabled, must not be presented as anonymous when wallet addresses or persistent identifiers can be correlated.

A production privacy policy must describe:

  • analytics provider;
  • event names;
  • IP handling;
  • cookies or local storage;
  • wallet-address processing;
  • retention periods;
  • legal basis or consent where required;
  • user contact and rights process;
  • cross-border processing where relevant.

9.3 Optional profile information#

Future optional profile fields should use explicit user consent and clear visibility controls. Public fields must be clearly identified as public before saving. Sensitive personal information should not be stored directly onchain because deletion and correction are difficult or impossible.

9.4 No hidden identity claims#

Vdecoty must not infer a user’s real name, location, age, wealth, legal identity, risk level, political beliefs, or creditworthiness from wallet activity. A wallet-linked social handle is not automatically proof that the wallet holder owns the social account.

---

10. Security Model#

10.1 Threat categories#

The Vdecoty release process considers at least the following threats:

  • malicious or compromised frontend deployment;
  • incorrect contract address or chain configuration;
  • phishing and cloned websites;
  • wallet prompt mismatch;
  • duplicate transaction submission;
  • replay of a user action;
  • reentrancy during treasury forwarding;
  • unauthorized owner operations;
  • paused-state inconsistency;
  • RPC failure or stale reads;
  • false success states after a reverted transaction;
  • exposed deployment keys or environment secrets;
  • dependency compromise;
  • inaccessible or misleading legal disclosure;
  • fabricated metrics, partners, audits, or addresses.

10.2 Contract controls#

The reference implementation uses:

  • explicit state-machine checks;
  • exact payment checks;
  • checks-effects-interactions ordering;
  • a reentrancy guard;
  • pausable write functions;
  • two-step ownership transfer;
  • a nonzero treasury requirement;
  • rejected direct payments;
  • no arbitrary points administration;
  • no token approvals or external token calls.

These controls reduce risk but do not guarantee the absence of defects.

10.3 Frontend controls#

The frontend must:

  • show the current chain and contract address;
  • refuse writes on the wrong chain;
  • verify contract bytecode exists;
  • use a pinned ABI that matches the deployed contract;
  • show Standard payment as 0 BOT and Boosted payment as exactly 0.01 BOT;
  • show gas separately;
  • avoid unlimited token approvals;
  • disable duplicate action buttons while pending;
  • wait for a successful receipt;
  • refresh state after confirmation;
  • retain a safe retry path after rejection or failure;
  • never request private keys or recovery phrases;
  • expose direct explorer links;
  • support reduced motion and accessible transaction status announcements.

10.4 Deployment controls#

Deployment keys must be treated as secrets and must never be committed, displayed in client-side environment variables, logged, or pasted into public issue trackers. A production deployment should use a dedicated deployer, then transfer ownership according to the approved operations plan.

The final release report must include contract addresses and transaction hashes, but never private credentials.

10.5 Audit and review#

A test suite is necessary but not equivalent to an independent audit. Before a high-visibility Mainnet release, Vdecoty should consider:

  • independent Solidity review;
  • static analysis;
  • unit and invariant tests;
  • deployment-script review;
  • frontend transaction review;
  • dependency audit;
  • domain and DNS security review;
  • multisignature and signer-security review;
  • public bug-reporting channel.

No “audited,” “secure,” or “risk-free” claim may appear without precise supporting evidence.

---

11. Operations and Treasury#

11.1 Treasury purpose#

The 0.01 BOT Boosted payment is received by the configured treasury. The website should disclose the treasury address after deployment and describe the payment as product revenue or treasury funding, subject to legal and accounting review.

The treasury may support development, infrastructure, security review, legal work, community operations, or other disclosed project costs. No specific use should be promised unless approved and operationally enforceable.

11.2 No depositor relationship#

A user making the Boosted payment is not depositing funds into an account, lending funds to Vdecoty, purchasing equity, or acquiring a right to repayment. The payment should be considered final after a valid transaction, subject to any separately published legal policy.

11.3 Administrative transparency#

The production website should publish or link to:

  • contract address;
  • contract source verification;
  • owner address;
  • treasury address;
  • current pause status;
  • Mainnet deployment transaction;
  • relevant audit report if one exists.

Any role transfer or treasury update is public onchain and should be documented in release notes.

---

12. Roadmap#

12.1 Phase 01 — Foundation#

The Foundation phase focuses on:

  • original Vdecoty brand and website;
  • full integration into the owner-supplied template;
  • wallet connection and network switching;
  • Standard and Boosted activation;
  • non-transferable points contract;
  • transaction receipts and public profile state;
  • Testnet and Mainnet environment separation;
  • whitepaper, privacy, terms, and disclosures;
  • Vercel deployment and production monitoring.

12.2 Phase 02 — Community Tools#

Research topics include:

  • optional profile fields;
  • user-controlled profile visibility;
  • curated participation programs;
  • additional non-financial attestations;
  • public program rules and receipts;
  • aggregate data and indexing;
  • abuse and sybil-mitigation approaches;
  • verified social-link proofs.

12.3 Phase 03 — Open Integrations#

Longer-term research may include:

  • read-only profile APIs;
  • SDK components;
  • portable attestations;
  • partner-defined modules with clear trust boundaries;
  • decentralized administration research;
  • cross-application discovery.

12.4 Roadmap limitations#

The roadmap is directional and may change. It does not promise dates, integrations, token issuance, airdrops, points conversion, governance rights, or economic value. Any new feature requires a separate specification, security review, privacy review, and legal review.

---

13. Governance Research#

The initial contract uses an owner role for emergency pause and treasury administration. This is operationally simple but centralized. Vdecoty should describe this honestly.

Potential future governance improvements include:

  • multisignature ownership;
  • role separation;
  • public operational policies;
  • delayed administrative changes;
  • community review of new profile modules;
  • immutable or versioned contract releases.

Governance research does not imply a governance token. A token is not required to improve operational transparency or distribute administrative responsibility.

---

14. Risks and Limitations#

14.1 Smart-contract risk#

Code can contain defects or unexpected interactions. A failed or exploited contract could cause loss of payment or incorrect state. Testing and review reduce but do not eliminate risk.

14.2 Wallet and phishing risk#

A compromised wallet, malicious extension, cloned website, or deceptive transaction prompt can cause loss. Users must verify the domain, network, contract address, payment amount, and wallet prompt.

14.3 Network and RPC risk#

BOT Chain, RPC endpoints, explorers, and wallets may experience congestion, outages, delayed data, inconsistent estimates, or unsupported methods. The frontend may temporarily fail to read state even when the contract remains available.

14.4 Transaction-finality and fee risk#

Transactions may remain pending, fail, or revert. Network fees may be paid even when a transaction does not produce the intended state. Gas costs are not controlled by Vdecoty.

14.5 Treasury and administrative risk#

The owner or treasury credentials may be compromised or mismanaged. Pausing can stop new activations. Treasury updates change the payment destination. Users should inspect current public configuration.

14.6 Regulatory risk#

Laws and regulatory interpretations may change or differ by jurisdiction. A future feature or community program may be restricted, modified, or unavailable. This whitepaper does not determine the legal status of a user or transaction.

14.7 Privacy risk#

Wallet activity is public and may be correlated with other information. A user cannot rely on Vdecoty to make confirmed blockchain activity private or erasable.

14.8 Product and roadmap risk#

Vdecoty may change, pause, discontinue, or never release exploratory features. The existence of a whitepaper or roadmap does not guarantee continued development.

14.9 No reward reliance#

Users should not pay 0.01 BOT or incur gas because they expect an airdrop, token, return, or future financial benefit. No such outcome is promised.

---

15. Release and Verification Standard#

A production release is not complete until the team can provide evidence for each of the following:

  • the full supplied template was audited and mapped;
  • all major template sections were reused;
  • code builds using the preserved package manager and lockfile;
  • contract tests pass;
  • Testnet contract address and deployment transaction are recorded;
  • Testnet source is verified where supported;
  • wallet states pass QA;
  • Standard activation results in 100 points;
  • direct Boosted activation results in 200 points;
  • Standard-to-Boosted upgrade results in 200 points;
  • duplicate and incorrect-payment paths revert;
  • failed transactions do not update final UI state;
  • Mainnet owner and treasury addresses are approved;
  • Mainnet deployment is explicitly authorized;
  • Mainnet source is verified where supported;
  • production uses Chain ID 677 and the Mainnet contract;
  • Vercel Production URL and commit SHA are documented;
  • no fabricated metric, partner, audit, token, or airdrop claim appears;
  • Privacy, Terms, and Points Disclosure are published;
  • the website is responsive and accessible;
  • no seed phrase or private key is requested.

---

16. Conclusion#

Vdecoty starts from a modest premise: a wallet can become easier to understand when a small number of clearly defined actions are recorded and presented honestly. The product does not need a tradable point, speculative promise, or complex social system to make that first step useful.

By combining a non-custodial wallet flow, a constrained onchain state machine, direct BOT Chain receipts, and explicit limitations, Vdecoty aims to create a credible foundation for future community identity tools. Its success should be evaluated by clarity, verifiability, security, and user control—not by implied future rewards.

---

Appendix A — Initial Contract Interface#

The expected public interface includes functions equivalent to:

function activateStandard() external;
function activateBoosted() external payable;
function boost() external payable;
function pointsOf(address account) external view returns (uint256);
function tierOf(address account) external view returns (Tier);
function totalParticipants() external view returns (uint256);
function totalBoosts() external view returns (uint256);
function totalPointsIssued() external view returns (uint256);
function treasury() external view returns (address);
function paused() external view returns (bool);

The final ABI must be generated from the compiled and deployed source, not handwritten independently.

---

Appendix B — Interface State Machine#

DISCONNECTED
  -> CONNECTING
  -> CONNECTED_WRONG_CHAIN
  -> CONNECTED_READING
  -> CONNECTED_NONE
  -> CONNECTED_STANDARD
  -> CONNECTED_BOOSTED

CONNECTED_NONE
  -> REVIEW_STANDARD
  -> WALLET_PROMPT
  -> SUBMITTED
  -> CONFIRMED_STANDARD | REJECTED | FAILED

CONNECTED_NONE
  -> REVIEW_BOOSTED
  -> WALLET_PROMPT
  -> SUBMITTED
  -> CONFIRMED_BOOSTED | REJECTED | FAILED

CONNECTED_STANDARD
  -> REVIEW_UPGRADE
  -> WALLET_PROMPT
  -> SUBMITTED
  -> CONFIRMED_BOOSTED | REJECTED | FAILED

Every confirmation branch ends with a fresh contract read.

---

Appendix C — Required Disclosures#

Points#

“Vdecoty Points are non-transferable participation records. They are not tokens, have no cash value, and do not guarantee any airdrop, allocation, conversion, or financial return.”

Boosted payment#

“The 0.01 BOT payment is a product interaction, not an investment. Network gas is additional. It does not purchase a token, equity, yield, or a guaranteed future benefit.”

Future programs#

“Vdecoty may explore future community programs. No token launch, airdrop, eligibility rule, conversion rate, allocation, value, or timing is promised.”

Wallet safety#

“Vdecoty will never ask for a seed phrase or private key. Review the network, contract address, amount, and gas in your wallet before signing.”

---

Appendix D — References#

  • BOT Chain Developer Documentation: `https://dev-docs.botchain.ai/docs/intro/`
  • BOT Chain Quick Guide: `https://dev-docs.botchain.ai/docs/Developers/quick-guide/`
  • BOT Chain JSON-RPC Endpoints: `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/`

All network references must be checked again immediately before deployment.

---