Diadeal Network Whitepaper

Privacy-Aware Coordination and Verifiable Participation on BOT Chain

Version: 1.0
Publication date: August 29, 2026
Status: Product and architecture whitepaper for the Diadeal Network v1 release

Important Notice

This document describes the intended design of Diadeal Network and the limited capabilities of its first release. It is not an offer to sell tokens, securities, investments, or financial products. Diadeal Network does not promise a token, airdrop, allocation, conversion ratio, eligibility rule, financial return, or future benefit.

Diadeal Network is built on BOT Chain, a public EVM-compatible blockchain. Diadeal does not make BOT Chain transactions private. Wallet addresses, transaction values, contract calls, blocks, timestamps, contract state, and related activity may remain publicly visible and may be analyzed by third parties.

Roadmap items are research directions and may be delayed, changed, or cancelled.

Executive Summary
The Coordination Problem
Product Thesis
Design Principles
Diadeal v1
User Experience
BOT Chain Integration
Diadeal Points
Smart Contract Architecture
Privacy and Data Boundaries
Security Model
Technical Operations
Governance and Administration
Roadmap
Risks and Limitations
No Token or Airdrop Commitment
Legal and Regulatory Considerations
Conclusion

1. Executive Summary

Public blockchains make digital actions verifiable, but they also make many actions durable and observable. A wallet can be linked across applications. Transaction values and timing can reveal behavior. Contract prompts can be difficult to interpret. Applications may also collect identity or profile information that is not necessary for the action a user wants to complete.

Diadeal Network begins with a narrow principle:

A Web3 interface should ask for the minimum information required, explain every public action before confirmation, and make the resulting proof easy to inspect.

Diadeal is a privacy-aware participation and coordination project built on BOT Chain. It is not a privacy blockchain, mixer, private wallet, or encrypted execution layer. Its first release focuses on the application layer: data minimization, explicit consent, wallet-bound participation records, and clear public-chain disclosures.

The v1 product allows a self-custody wallet to create one of two participation records through a BOT Chain smart contract:

Standard Access: a zero-BOT-value contract call that records 100 non-transferable Diadeal Points. The user still pays the BOT Chain network gas fee.
Boosted Access: a contract call that sends exactly 0.01 BOT and records 200 non-transferable Diadeal Points. Network gas is paid separately.

A wallet that first chooses Standard Access may later send exactly 0.01 BOT once to add 100 points and upgrade to a final total of 200 points with Boosted Access.

Points are not tokens, money, equity, governance rights, or guaranteed future rewards. They are simple contract records associated with the wallet that completed a confirmed transaction.

The v1 system is designed to prove a complete and honest loop:

Understand the public-chain boundary
→ connect a self-custody wallet
→ switch to BOT Chain
→ review the exact contract action
→ confirm in the wallet
→ wait for a successful receipt
→ receive a wallet-bound participation record
→ inspect the transaction and contract evidence

This limited foundation can support future research into selective disclosure, scoped access, coordination rooms, and agent permissions. Those concepts are not part of v1 and require separate security design, implementation, and review.

2. The Coordination Problem

2.1 Public proof and persistent exposure

Blockchains are useful because independent participants can verify state without trusting a single database operator. That same transparency can create a long-lived behavioral record. Wallet addresses, counterparties, transaction values, contract interactions, timing, and repeated patterns may be combined to infer activity across applications.

The problem is not that public proof is always undesirable. The problem is that users often cannot distinguish between:

information that must be public for verification;
information that an application chooses to collect;
information that external infrastructure may observe;
information that should remain outside the transaction entirely.

A responsible interface should make those boundaries understandable before the wallet asks for approval.

2.2 Unclear transaction intent

Wallet prompts can be technically accurate while still being difficult for users to interpret. A user may see a contract address, hexadecimal calldata, a network name, and a native-asset value without understanding the intended result.

This creates a consent problem. A transaction is not meaningfully reviewed when the interface hides the relevant information or treats the wallet confirmation as a formality.

Diadeal requires the application to present, before confirmation:

the active wallet;
the network;
the contract;
the native value;
the points result;
the gas note;
the public nature of the resulting record;
the destination of a paid action.

2.3 Excess application-level collection

Many products add account systems, emails, social profiles, referrals, identity fields, and behavioral analytics to a simple wallet action. Some of those systems may be useful in other contexts, but they are not necessary for Diadeal v1.

The first release therefore avoids requiring:

an email address;
a legal name;
a phone number;
an identity document;
a social-media account;
a referral code;
a profile image;
a private document;
a deal description.

The connected wallet is sufficient to read and create the v1 participation record.

2.4 The limits of interface-level privacy

Data minimization does not create protocol-level privacy. Even when an application stores little information, a public blockchain transaction may remain visible. Wallet providers, RPC providers, hosting infrastructure, analytics tools, browsers, and external links may also process technical data.

Diadeal addresses this limitation through disclosure rather than concealment. The product must state clearly what it can and cannot protect.

3. Product Thesis

Diadeal's product thesis has three parts.

3.1 Ask for less

An application should not collect personal context merely because it can. The v1 contract needs only the wallet address supplied by the transaction sender and the public state required to record participation.

3.2 Explain more

Before the wallet opens, the interface should explain the exact action in plain language. Users should understand the difference between a zero-value contract call and a paid claim, and they should see that network gas is separate.

3.3 Preserve verifiability

The resulting record should not depend on a hidden application database. The wallet's tier and point total should be readable from a deployed contract, and confirmed transactions should include direct BOT Chain Explorer links.

Together, these principles produce a system that is privacy-aware without making false privacy guarantees.

4. Design Principles

4.1 Minimal public proof

Diadeal v1 records only the state needed for the participation program:

wallet address;
access tier;
point total;
activation time;
boost time when applicable;
aggregate participation totals;
the native value associated with paid actions through transaction and event evidence.

The contract does not require a legal identity, email, private message, document, or deal term.

No transaction should be triggered automatically after wallet connection. Connecting a wallet allows the application to read the active public address; it does not authorize a contract call.

The user must deliberately choose Standard Access, Boosted Access, or an available upgrade, then review and confirm the action.

4.3 Receipt-based truth

The interface must not award points or display success because a button was clicked or a wallet prompt appeared. Points are considered confirmed only after the transaction receipt reports success and the contract state is reread.

4.4 Non-custodial operation

Diadeal does not ask for a seed phrase or private key. It does not hold user assets, request token approvals, perform swaps, stake tokens, or move funds without a user-approved wallet transaction.

4.5 Honest failure states

Network failures, RPC errors, transaction rejections, reverts, contract pauses, and unavailable history should be shown accurately. Missing data is not replaced with fabricated activity.

4.6 Accessible review

Transaction review and status interfaces should be usable with keyboard navigation, visible focus, readable contrast, clear headings, and screen-reader announcements for important state changes.

4.7 No reward speculation

Points are presented as participation records, not as an investment or speculative asset. The interface must not estimate an airdrop, display a points price, rank wallets by expected value, or imply a guaranteed token allocation.

5. Diadeal v1

5.1 Product scope

The first release includes:

an English public website;
original Diadeal branding;
BOT Chain wallet connection;
wrong-network detection and add/switch behavior;
Standard Access claim;
direct Boosted Access claim;
upgrade from Standard to Boosted;
an Account page that reads the current wallet's contract state;
transaction, block, contract, and Explorer evidence;
pending transaction recovery after page refresh;
a Whitepaper page;
Privacy Policy and Terms of Use;
responsive desktop and mobile layouts;
Vercel deployment.

5.2 Excluded from v1

The first release does not include:

protocol-level private execution;
encrypted mempool services;
stealth addresses;
private transfers;
a mixer;
a token;
an NFT;
staking;
lending;
trading;
bridging;
a marketplace;
encrypted messaging;
a private deal room;
identity verification;
proof of unique humanity;
an AI agent;
referral farming;
guaranteed rewards.

5.3 Public website narrative

The website explains:

why public proof and private context should be separated;
what Diadeal records;
what the v1 contract does not store;
how a user reviews and confirms the participation action;
what future research may explore;
why those future concepts are not presented as live features.

5.4 Access tiers

Standard Access

Standard Access is created through a contract call with zero BOT sent to the contract. The wallet still pays the network gas fee. A successful call records:

Tier: Standard
Points: 100

Boosted Access

Boosted Access is created through a contract call that sends exactly 0.01 BOT. Network gas is paid separately. A successful call records:

Tier: Boosted
Points: 200

Upgrade

A Standard wallet may upgrade once by sending exactly 0.01 BOT. The successful upgrade records:

Previous points: 100
Additional points: 100
Final points: 200
Final tier: Boosted

A wallet cannot claim twice or exceed 200 points under the v1 contract.

6. User Experience

6.1 Browsing without a wallet

All public product, Whitepaper, Privacy, and Terms content should remain readable without connecting a wallet. The website should not force a connection just to understand the project.

6.2 Wallet connection

The user selects a compatible self-custody EVM wallet. Diadeal reads the active public address and current network through the wallet provider.

The product does not automatically request a signature or transaction after connection.

6.3 Network review

If the wallet is not on the configured BOT Chain network, the interface offers a clear switch or add-network action. The active chain ID must be verified before a contract call is prepared.

6.4 Contract-state read

The application reads the current wallet's tier, point total, activation time, boost time, contract pause state, and relevant aggregate values directly from the configured contract.

If the contract or RPC is unavailable, the interface displays an unavailable state. It does not assume the wallet has zero points.

6.5 Action selection

An unclaimed wallet may choose Standard or Boosted Access. A Standard wallet sees an upgrade option. A Boosted wallet sees its completed state and no further points action.

6.6 Transaction review

The review panel includes:

wallet address;
BOT Chain network;
contract address;
action name;
exact native value;
points after success;
network gas note;
Treasury destination for a paid action;
public-record disclosure.

6.7 Simulation and confirmation

The application simulates the exact contract call before opening the wallet. A failed simulation prevents submission and produces an understandable message.

The user then confirms or rejects the transaction in the wallet.

6.8 Pending state

After submission, the product displays the transaction hash and a direct Explorer link. Duplicate submissions are disabled while the transaction is pending.

Non-sensitive transaction metadata may be stored locally to recover the pending state after a page refresh.

6.9 Success

Success is shown only after a successful receipt. The application then rereads the contract and displays:

wallet;
tier;
points;
transaction value;
transaction hash;
block number;
confirmation time;
contract link;
network.

6.10 Failure

A rejected, reverted, replaced, timed-out, or failed transaction does not add points. The interface presents the failure and allows a valid retry.

7. BOT Chain Integration

7.1 Network role

BOT Chain is the public settlement and contract-execution network for Diadeal v1. BOT is the native asset used for network gas and for the fixed 0.01 BOT Boosted or Upgrade value.

7.2 Network configuration

The intended configuration is:

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
Faucet: https://faucet.botchain.ai/basic

The project should use testnet until contract tests, end-to-end flows, owner and Treasury configuration, legal content, and deployment readiness are complete.

7.3 Public RPC limitation

BOT Chain's official documentation states that eth_getLogs is disabled on the listed public mainnet RPC endpoint. As a result:

current contract state can be read through direct view calls;
submitted transaction receipts can be read;
historical event lists require an approved indexer, third-party RPC, or WebSocket provider.

When no event provider is configured, Diadeal should show that history is unavailable rather than generating sample activity.

7.4 Explorer evidence

The interface should create direct links for:

connected wallet;
contract;
transaction;
block where practical.

Explorer availability is external to Diadeal and may be interrupted.

8. Diadeal Points

8.1 Definition

Diadeal Points are integer values recorded by the DiadealGenesisRegistry contract for a wallet address.

They are designed to show whether the wallet completed a confirmed Standard claim, direct Boosted claim, or upgrade.

8.2 Non-transferability

The contract does not implement transfer, approval, allowance, mint-to-another-wallet, burn-by-user, withdrawal, or marketplace functions.

Points cannot be moved from one wallet to another.

8.3 Maximum balance

The v1 maximum is:

200 Diadeal Points per wallet

8.4 No cash value

The application does not assign a fiat or crypto price to points. It does not provide redemption, exchange, liquidity, staking, or return calculations.

8.5 No guaranteed future use

Diadeal may explore additional uses for participation records, but points may remain only historical records. Any future program would require separate rules, disclosures, security review, and legal review.

8.6 Wallet-based identity limitation

The contract applies rules per wallet address. It does not prove that one wallet equals one person. A person may control multiple wallets, and a wallet may be controlled through different interfaces.

9. Smart Contract Architecture

9.1 Contract

The reference contract is named:

DiadealGenesisRegistry

It is intended to use Solidity 0.8.24 or a reviewed compatible version and OpenZeppelin components for:

two-step ownership transfer;
pausing;
reentrancy protection.

The contract is not upgradeable.

9.2 State

The contract maintains:

an access tier for each wallet;
a point balance for each wallet;
activation and boost timestamps;
participant totals;
Standard and Boosted wallet totals;
total points issued;
total BOT collected through paid actions;
an immutable Treasury address.

9.3 Standard claim

claimStandard():

is available only to an unclaimed wallet;
sends zero BOT value to the contract;
records Standard tier;
records 100 points;
increments aggregate values;
emits an activation event;
is blocked when the contract is paused.

9.4 Direct Boosted claim

claimBoosted():

is available only to an unclaimed wallet;
requires exactly 0.01 BOT;
records Boosted tier;
records 200 points;
increments aggregate values;
forwards the received BOT to the immutable Treasury;
emits an activation event;
is protected against reentrancy;
is blocked when paused.

9.5 Upgrade

upgradeToBoosted():

is available only to a Standard wallet;
requires exactly 0.01 BOT;
adds 100 points for a final total of 200;
changes the tier to Boosted;
updates aggregate Standard and Boosted counts;
forwards the received BOT to Treasury;
emits an upgrade event;
cannot be repeated;
is blocked when paused.

9.6 Administrative power

The owner may pause or unpause claims and use the two-step ownership-transfer process. The owner does not have a function to:

add or remove points;
change a wallet's tier;
transfer points;
withdraw user assets;
change the immutable Treasury;
create a token.

This limited authority reduces, but does not eliminate, operational risk.

9.7 Direct transfers

Native transfers that do not call an approved claim or upgrade function should revert. This reduces accidental BOT deposits to the contract.

9.8 Treasury

Paid actions forward 0.01 BOT to the configured Treasury during the same transaction. A failed Treasury transfer causes the entire transaction to revert, preventing points from being recorded without the intended payment flow.

The Treasury is publicly observable. The project owner is responsible for selecting, securing, and documenting it.

9.9 Events

Contract events include the wallet, tier or upgrade action, points added, resulting point total, native value, and timestamp. These events are public and must not be described as private.

9.10 Testing

The contract should be tested for:

deployment validation;
exact-value enforcement;
one-time claims;
correct upgrade behavior;
aggregate invariants;
pause permissions;
Treasury failure;
direct-transfer rejection;
reentrancy resistance;
event correctness;
maximum point balance;
source verification and testnet execution.

Public mainnet deployment should occur only after explicit authorization and appropriate review.

10. Privacy and Data Boundaries

10.1 What Diadeal means by privacy-aware

“Privacy-aware” describes product choices that reduce unnecessary application-level collection and make public exposure clear. It does not mean that the underlying blockchain transaction is hidden.

10.2 Public blockchain information

Depending on network and tooling, public information may include:

wallet address;
wallet balance;
transaction hash;
sender and recipient;
contract address;
native value;
gas fields;
calldata;
block number;
timestamp;
contract state;
events;
repeated interaction patterns.

Users should assume that confirmed BOT Chain activity can be observed and analyzed.

10.3 Information not required by the v1 contract

The v1 contract does not require:

legal name;
email address;
phone number;
identity document;
private message;
file or document;
deal term;
social account;
seed phrase;
private key.

10.4 Infrastructure providers

A production application depends on external infrastructure that may process technical data. Examples include:

wallet applications and browser extensions;
WalletConnect infrastructure when enabled;
RPC providers;
BOT Chain Explorer;
Vercel hosting and logs;
domain and content-delivery infrastructure;
analytics when explicitly enabled;
error monitoring when explicitly enabled.

The production Privacy Policy must name or describe the providers actually configured and should not claim that Diadeal controls their independent data practices.

10.5 Local storage

The application may store limited pending-transaction recovery data locally, such as:

transaction hash;
wallet address;
chain ID;
contract address;
action type;
submission time.

It must not store private keys, seed phrases, raw signatures, or sensitive session secrets.

10.6 Disconnecting a wallet

Disconnecting removes the application's active connection but does not erase public blockchain records or data already processed by external providers.

10.7 Future selective disclosure

Future research may examine credentials, scoped permissions, and client-side encryption. Any such feature must begin with a threat model that defines:

what is being protected;
from whom it is protected;
who controls encryption keys;
how access is revoked;
what metadata remains visible;
how loss and recovery work;
what is anchored publicly;
what legal obligations apply.

A visual concept alone is not a privacy system.

11. Security Model

11.1 User-controlled wallet

Users retain control of their wallets and must review transactions before approval. Diadeal cannot recover a lost seed phrase, reverse a confirmed transaction, or guarantee wallet-provider security.

11.2 Exact transaction values

Boosted and Upgrade actions require exactly 0.01 BOT. Underpayment and overpayment should revert. Standard Access sends zero BOT value to the contract but still consumes gas.

11.3 Contract simulation

The interface should simulate the exact function, wallet, chain, contract, and value before asking the wallet to submit the transaction.

Simulation reduces avoidable failures but does not guarantee final inclusion or success.

11.4 Pending and replacement handling

Transactions can remain pending, be replaced, fail, or confirm after the interface times out. Diadeal should preserve the transaction hash, offer an Explorer link, and avoid declaring a final outcome without evidence.

11.5 Pause mechanism

The owner may pause new claims or upgrades in response to a discovered issue. Pausing does not erase existing records and does not guarantee that all risks have been eliminated.

11.6 Treasury security

A compromised Treasury may expose paid proceeds after successful transfers. The project owner should use an appropriate secure wallet or multisignature process, document the operational model, and avoid using an unreviewed personal wallet.

11.7 Frontend integrity

The production site should use:

verified contract configuration;
clear contract display;
dependency and secret scanning;
safe security headers compatible with wallet connections;
no unnecessary third-party scripts;
protected deployment permissions;
reviewed domain and Vercel configuration;
post-deployment checks.

A malicious frontend can misrepresent a contract request even when the contract itself is correct. Users should also verify the contract and value in their wallet.

11.8 No audit claim without evidence

Diadeal must not describe the contract, frontend, or protocol as audited unless a real third-party report exists, covers the deployed version, and is publicly linked.

12. Technical Operations

12.1 Environment separation

Testnet, Preview, and Production environments should use separate configuration. Contract addresses, deployment blocks, network selection, WalletConnect settings, and public URLs must be explicit.

12.2 Deployment keys

The deployment private key must not be committed to Git or exposed through public environment variables. It should not remain in the production Vercel runtime after deployment.

12.3 Source verification

The deployed contract source, compiler version, optimizer settings, constructor parameters, and relevant metadata should be verified on the BOT Chain Explorer where supported.

12.4 Monitoring

Operational monitoring may include:

site availability;
build and deployment status;
RPC health;
contract pause state;
failed transaction categories;
client errors without sensitive wallet payloads.

Analytics should be disabled by default and must not send full wallet addresses or signatures to third parties.

12.5 Incident response

A basic incident plan should define:

who can pause the contract;
how a compromised frontend deployment is rolled back;
how users are notified through real official channels;
how false links are identified;
how contract and Treasury addresses are reverified;
what information is preserved for investigation;
what cannot be reversed on-chain.

13. Governance and Administration

13.1 Initial operation

Diadeal v1 is an application with limited owner administration, not a decentralized governance protocol.

Operational decisions may include:

pausing or unpausing claims;
deploying a corrected contract;
updating the frontend configuration;
changing infrastructure providers;
revising legal disclosures;
changing future product priorities.

13.2 Existing records

The owner cannot edit points or tiers in the reference v1 contract. A future migration would require a new contract and a publicly explained process.

13.3 Transparency

Material production information should be documented, including:

contract address;
owner address;
Treasury address;
deployment transaction;
deployment block;
source verification;
current pause status;
current website domain;
current Vercel production URL or custom domain;
material rule changes.

13.4 Future governance

Any future governance system would require separate design. Points should not be presented as governance power unless a later, implemented system explicitly establishes that role.

14. Roadmap

The roadmap expresses possible directions rather than guaranteed dates.

Phase 1 — Access Registry

The first phase focuses on a reliable public foundation:

original Diadeal brand;
complete template-based website;
BOT Chain wallet connection;
network guard;
Standard claim;
direct Boosted claim;
upgrade;
Account evidence;
Whitepaper and legal pages;
contract tests and verification;
Vercel deployment.

Phase 2 — Selective Disclosure Research

Potential research areas:

credential formats;
scoped access;
consent receipts;
client-side encryption;
key management;
revocation;
metadata analysis;
threat-model publication.

Research does not imply production availability.

Phase 3 — Coordination Rooms

Potential future coordination features may include:

participant-controlled encrypted context;
explicit room membership;
public proof anchors;
access expiry;
document integrity proofs;
dispute and recovery procedures.

A private room feature would require independent security review and should not be launched solely as a frontend mockup.

Phase 4 — Agent Controls

Potential future agent features may include:

permission scopes;
human-readable action policies;
spending limits;
expiration;
revocation;
auditable consent records;
clear separation between autonomous behavior and human approval.

Agent actions should never be described as private merely because the interface hides them from view.

15. Risks and Limitations

15.1 Smart contract risk

Contract defects may cause calls to fail, points to be recorded incorrectly, or paid actions to behave unexpectedly. Tests and review reduce but do not eliminate this risk.

15.2 Wallet risk

Users are responsible for wallet security, device security, malicious extensions, phishing, and transaction review. Diadeal cannot recover lost keys.

15.3 Public-chain risk

Wallet and transaction activity may be public, linked, copied, indexed, and analyzed indefinitely. Diadeal cannot guarantee anonymity.

15.4 Network risk

BOT Chain congestion, consensus issues, reorganization, RPC outages, protocol changes, or Explorer outages may delay or interrupt the application.

15.5 Infrastructure risk

Vercel, wallet providers, WalletConnect, RPC services, domain providers, analytics, and external links may fail, change terms, or process technical data.

15.6 Treasury risk

The paid action forwards BOT to the configured Treasury. Treasury compromise, loss, misuse, or incorrect configuration may affect those funds.

15.7 Frontend risk

A compromised deployment or domain can display a false contract or value. Contract display, wallet review, deployment controls, and official-link verification are important.

15.8 Points risk

Points may never have any use beyond participation records. A future application may modify or discontinue the program through a new version, but the v1 owner cannot edit existing records in the reference contract.

15.9 Sybil risk

The rules apply per wallet, not per person. Multiple wallets may be controlled by the same participant.

15.10 Roadmap risk

Future features may be technically infeasible, insecure, delayed, modified, legally restricted, or cancelled.

15.11 Regulatory risk

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

15.12 Name and brand risk

The Diadeal Network name should be reviewed for domains, trademarks, social handles, and potential confusion before broad promotion.

16. No Token or Airdrop Commitment

Diadeal v1 does not issue a token.

Diadeal Points do not represent:

a token allocation;
a claim on a future token;
an airdrop entitlement;
a conversion formula;
equity;
debt;
revenue share;
governance rights;
interest;
yield;
profit;
a guaranteed service benefit.

The project may study future ecosystem uses, but no user should interact with Diadeal based on an expectation of financial reward.

Any future token or distribution would require a separate decision, legal analysis, technical design, public terms, eligibility rules, security review, and implementation. This whitepaper does not commit the project to taking those steps.

17. Legal and Regulatory Considerations

Diadeal is intended as a software interface and public smart-contract participation system. Public availability does not mean that every use is lawful in every jurisdiction.

Users are responsible for:

understanding applicable laws;
reviewing wallet and transaction details;
paying network fees;
securing their wallets;
evaluating tax or reporting obligations;
deciding whether participation is appropriate.

Diadeal does not provide investment, financial, legal, tax, privacy, cybersecurity, or regulatory advice.

The project owner should obtain appropriate legal review before mainnet launch, especially regarding:

points-program disclosures;
collection and forwarding of 0.01 BOT;
privacy statements;
consumer terms;
sanctions and restricted jurisdictions;
data-protection obligations;
future encrypted coordination features;
any future token-related decision.

18. Conclusion

Diadeal Network begins with a modest but important premise: a Web3 product can be more respectful of user context without pretending that a public blockchain is private.

The first release asks for less information, explains the exact transaction, waits for verifiable confirmation, and gives the user direct evidence of the resulting record. Its points system is deliberately limited, non-transferable, and free of guaranteed reward claims.

This foundation is not the final vision of coordination. It is the boundary that must be understood before more complex systems are built.

Coordinate without oversharing. Prove only what the action requires.