repodaofi

repodaofi Whitepaper

Wallet-Verified Participation for Open Communities

Version: 1.0 Publication date: 4 September 2026 Status: Product and technical design for the first public release

This document describes the intended first release of repodaofi. It is not an offer to sell tokens, securities, investments, or financial products. No token, airdrop, allocation, conversion ratio, monetary value, yield, or future benefit is promised.

Executive Summary
Context
Product Thesis
Design Principles
The First Release
User Journey
Wallet Ownership Verification
repodaofi Points
Optional On-Chain Boost
System Architecture
Data and Privacy Boundaries
Security Model
Operations and Administration
Roadmap
Risks and Limitations
No Token or Airdrop Commitment
Legal and Regulatory Considerations
Conclusion

1. Executive Summary

Open-source software and open digital communities depend on participation that is often difficult to recognize consistently. A user may arrive early, review an idea, test a release, provide feedback, document a process, or support community coordination without producing a single metric that captures the full contribution. At the same time, many Web3 participation systems introduce unnecessary complexity, speculative token language, opaque scoring, or transactions that users do not clearly understand.

repodaofi begins with a narrower promise:

Let a user prove control of a wallet, create one limited participation record, and optionally add one publicly verifiable on-chain action.

The first release provides two states:

Base record: a user connects a self-custody wallet, signs a human-readable ownership-verification message, and receives 100 non-transferable repodaofi Points once.
Boosted record: the same wallet may optionally submit one transaction containing exactly 0.01 BOT. After a successful receipt and independent verification, the wallet reaches a final total of 200 Points.

The base record is an application-level record, not a blockchain token. The Boost is an on-chain proof, not an investment. Points cannot be transferred, sold, withdrawn, approved, or redeemed through repodaofi. They do not guarantee an airdrop, token allocation, conversion ratio, governance right, monetary value, or future utility.

repodaofi is non-custodial. It never needs a seed phrase, private key, wallet password, keystore file, or unlimited token approval. Every signature and transaction must be initiated and approved by the user.

The first release intentionally avoids a token launch, marketplace, bonding curve, staking system, yield product, repository tokenization system, contributor salary system, decentralized credit score, or claim that one wallet equals one person. Those features would introduce legal, security, product, and expectation risks that are not necessary to prove the initial user journey.

2. Context

Open collaboration produces value through code, research, documentation, testing, moderation, design, education, and coordination. Conventional platforms can record some of these actions, but records are fragmented across identities and services. Web3 introduces the possibility of wallet-bound continuity and public transaction evidence, yet it also introduces irreversible actions, public metadata, wallet security risk, and speculative expectations.

A trustworthy first step should therefore do less, not more. It should make each state understandable, bind it to a user-controlled wallet, expose the source of that state, and avoid implying a financial promise.

repodaofi focuses on four problems:

Wallet connections are often misunderstood. Users may not know the difference between connecting, signing, approving, and sending a transaction.
Points can be presented as disguised speculation. Users may assume that any points program guarantees a future token or reward.
Pending transactions are frequently misrepresented as success. A submitted hash is not the same as a successful receipt and verified contract state.
Public-chain activity is easy to overstate. A wallet action can prove control of an address or completion of a transaction, but it cannot prove legal identity, uniqueness, reputation, contribution quality, or intent by itself.

The product is designed around these limitations.

3. Product Thesis

repodaofi is a wallet-verified participation layer for open communities.

The product thesis is that an early participation record can be useful when it is:

voluntary;
easy to understand;
wallet-controlled;
deterministic;
limited in scope;
transparent about its source;
explicit about what it does not prove;
free of guaranteed token or financial claims.

The initial Points total is deliberately capped. A wallet may have 100 base Points or 200 boosted Points. The product does not use open-ended farming, daily streaks, referral multiplication, hidden multipliers, wealth weighting, trading volume, or arbitrary administrator adjustments.

This limited design makes the state easier to explain and audit. A user can answer three questions:

Was this wallet verified?
Was the optional on-chain action confirmed?
What evidence produced the current Points total?

4. Design Principles

4.1 Self-custody by default

The user controls the wallet and reviews every request. repodaofi does not hold user funds or recovery credentials.

4.2 Explicit state transitions

A page must distinguish disconnected, connected, verification requested, base confirmed, Boost review, wallet prompt, submitted, confirmed, failed, and unavailable states. These states must not be collapsed into a decorative success animation.

4.3 Receipt before reward

A transaction hash proves submission, not success. Boost Points are added only after a successful receipt and a complete server-side reconciliation.

4.4 Minimal data collection

The first release needs a wallet address, nonce, signature-verification result, session state, Points state, and limited transaction evidence. It does not need a legal name, home address, passport, face scan, phone number, social graph, or private repository data.

4.5 Honest public claims

repodaofi does not claim that Points are a token, that a Boost is an investment, that a wallet is a unique person, or that participation guarantees future access or value.

4.6 Inspectable proof

A confirmed Boost includes a transaction hash, block, contract address, amount, and confirmation time. The product provides a direct proof link using neutral link text.

4.7 Clarity-first interface

The interface preserves clear hierarchy, readable transaction review, understandable state changes, responsive behavior, and accessible interaction. Visual complexity must never hide the difference between connecting, signing, submitting, confirming, and failing.

5. The First Release

The first release includes:

a responsive public landing page;
an original repodaofi brand and logo;
compatible self-custody wallet connections;
supported-network switching or addition;
human-readable wallet ownership verification;
a one-time 100-Point base record;
an optional exact 0.01 BOT one-time Boost;
a final maximum of 200 Points;
pending transaction recovery after refresh;
server-side receipt reconciliation;
an Account page with proof details;
a full Whitepaper;
Privacy and Terms pages;
responsive and accessibility testing;
production deployment and monitoring.

The first release does not include:

a tradable token;
tokenomics;
an airdrop claim;
automatic or promised reward qualification;
repository-specific tokens;
bonding curves;
a launchpad;
swaps, staking, farming, lending, deposits, or custody;
token approvals;
contributor payroll;
DAO voting;
investment returns;
referral farming;
a leaderboard based on fabricated activity;
fake partners, investors, audits, users, or transaction counts.

6. User Journey

6.1 Connect

The user selects a compatible wallet. The page receives the public address and current connection state. The website does not automatically open a wallet prompt on page load.

6.2 Network readiness

The application checks whether the wallet is connected to the supported execution network. Public site copy uses neutral labels such as “Supported,” “Switch required,” and “Unavailable.” Technical identifiers remain in configuration and wallet-level prompts, not in public marketing copy.

6.3 Verify wallet control

The user requests a one-time nonce and signs a readable message. The message explains that it proves control of the address, moves no funds, and grants no token approval.

The server verifies the signature, domain, URI, nonce, issuance time, expiration time, expected address, and supported network context. A nonce is one-time use and expires quickly.

6.4 Receive the base record

After successful verification, the wallet receives 100 repodaofi Points once. Returning users restore the same confirmed state through a secure session or a new wallet verification.

6.5 Review the optional Boost

The user may retain 100 Points without paying. When the user chooses the Boost, the page displays:

connected wallet;
supported-network status;
contract address;
action name;
protocol payment of exactly 0.01 BOT;
estimated network fee;
expected total wallet cost;
final Points total of 200;
a clear statement that the payment is not an investment and promises no token or future benefit.

6.6 Submit and confirm

The application simulates or prepares the contract call, asks the wallet for confirmation, stores the pending transaction hash and non-sensitive recovery fields, and waits for the receipt.

6.7 Reconcile

After a successful receipt, the server checks:

the transaction sender matches the verified wallet;
the destination matches the configured contract;
the called function is the permitted Boost action;
the value is exactly 0.01 BOT;
the receipt status is successful;
the expected event was emitted by the configured contract;
the event wallet matches the verified wallet;
the block is not earlier than the recorded deployment block;
the transaction hash has not been used before;
the contract state reports the wallet as boosted.

Only then does the application add 100 Boost Points and show a final total of 200.

6.8 Inspect proof

The Account page shows the verified state and evidence. Failure, timeout, or data unavailability never silently changes a confirmed state.

7. Wallet Ownership Verification

Wallet ownership verification uses a readable signed message and a server-generated nonce.

A recommended message includes:

product name;
request purpose;
public wallet address;
website domain;
request URI;
one-time nonce;
issue time;
expiration time;
statement that no funds move and no spending approval is granted.

The server must not trust an address submitted without verifying the signature. It must normalize addresses consistently, prevent nonce reuse, enforce expiration, bind the request to the correct domain and URI, and create an HTTP-only secure session after success.

Wallet verification proves control of a private key corresponding to an address at the time of signing. It does not prove:

legal identity;
uniqueness;
age;
residence;
reputation;
creditworthiness;
ownership of external accounts;
quality or quantity of contribution;
compliance status.

8. repodaofi Points

8.1 Base Points

A successfully verified wallet receives 100 base Points once.

8.2 Boost Points

A wallet with a reconciled Boost receives an additional 100 Points.

8.3 Maximum

The maximum first-release total is 200 Points.

8.4 Non-transferability

Points cannot be transferred, approved, delegated, withdrawn, sold, traded, bridged, staked, or redeemed through repodaofi.

8.5 No monetary value

Points are not money, cryptocurrency, stored value, securities, equity, debt, governance rights, revenue rights, profit rights, or claims on assets.

8.6 Deterministic state

The application must calculate Points from two explicit facts:

verified wallet = 100 Points
verified wallet + reconciled Boost = 200 Points

An administrator must not have a hidden control that fabricates arbitrary Points.

8.7 No guaranteed future use

Future community programs may be explored, changed, delayed, limited, or cancelled. Current Points create no obligation to deliver a future program.

9. Optional On-Chain Boost

The Boost is a one-time contract interaction with an exact protocol payment of 0.01 BOT, plus the network fee displayed by the user's wallet.

The Boost exists to create a simple public proof of intentional participation. It is not a deposit, investment, purchase of equity, purchase of a token, loan, staking position, yield strategy, or claim on the treasury.

The contract should enforce:

exact payment;
one Boost per wallet;
paused-state protection;
reentrancy protection;
a nonzero immutable treasury;
direct forwarding of the payment in the same transaction;
an event containing the wallet, amount, timestamp, and cumulative count;
rejected direct transfers;
two-step ownership transfer;
no arbitrary points management;
no token approvals or external token calls.

A transaction that is rejected, dropped, replaced unsuccessfully, reverted, sent to the wrong contract, sent with the wrong value, sent by a different wallet, or missing the expected event must not add Boost Points.

10. System Architecture

10.1 Frontend

The frontend is a responsive web application with typed interfaces and standard EVM-compatible wallet libraries. The implementation should preserve clear state boundaries and accessible interaction.

Responsibilities include:

wallet connection;
network readiness;
readable signature request;
current account state;
Boost review;
transaction simulation and submission;
pending recovery;
receipt polling;
proof links;
responsive and accessible UI.

10.2 Application API

The API is responsible for:

nonce generation;
signature verification;
secure sessions;
base Points idempotency;
profile retrieval;
Boost receipt reconciliation;
transaction-hash uniqueness;
rate limiting;
error normalization;
audit logging without secrets.

10.3 Database

A production database stores normalized wallet profiles, nonces, sessions or session references, confirmed Points state, and reconciled transaction evidence.

Recommended constraints include:

one profile per normalized wallet address;
one consumed base verification state per wallet;
one Boost transaction hash globally;
one Boost per wallet;
a maximum Points total of 200;
idempotent reconciliation;
created and updated timestamps;
no seed phrase, private key, or wallet password columns.

10.4 Smart contract

The contract records the one-time Boost state and forwards the exact payment to the configured treasury. It does not issue a token and does not maintain a transferable Points balance.

10.5 Proof links

The Account page exposes neutral “View transaction,” “View block,” and “View contract” actions. The destination is configured by environment, and an unavailable explorer produces an honest unavailable state.

11. Data and Privacy Boundaries

Public blockchain data may include wallet addresses, transaction hashes, contract calls, values, blocks, and timestamps. Disconnecting a wallet from the site does not delete public blockchain records.

The first release may process:

public wallet address;
signature-verification request and result;
nonce and expiration;
session identifier;
Points state;
transaction hash;
contract address;
amount;
block number;
confirmation time;
application security and availability logs.

The first release should not request:

recovery phrase;
private key;
keystore file;
wallet password;
passport or identity-card scan;
biometric template;
home address;
private repository credentials;
unlimited token approval.

Analytics must not intentionally receive full wallet addresses, signatures, private credentials, or wallet balances unless a later policy explicitly defines and justifies the processing. Non-essential analytics and cookies should remain disabled until they are configured and disclosed.

Pending recovery may store a limited record in browser storage:

wallet address
network identifier
transaction hash
action type
contract address
submission time

It must not store session secrets, signatures, private keys, or recovery phrases.

12. Security Model

12.1 Threats considered

phishing or cloned websites;
compromised frontend deployment;
wrong contract or network configuration;
nonce replay;
signature replay across domains;
duplicate base claims;
duplicate Boosts;
transaction replacement or reversion;
false success before receipt;
wrong sender, destination, function, or value;
event spoofing;
old or replayed transaction hashes;
treasury misconfiguration;
reentrancy during forwarding;
unauthorized pause or ownership actions;
leaked deployment keys;
dependency compromise;
rate-limit abuse;
RPC failure or stale reads;
fabricated metrics or proof.

12.2 Frontend controls

Never auto-open a wallet prompt on initial page load.
Display the exact payment and estimated fee separately.
Show the configured contract address before confirmation.
Disable duplicate submission while pending.
Recover pending transactions after refresh.
Require a successful receipt before success.
Re-read confirmed profile and contract state.
Provide understandable error classes and next steps.
Never request unlimited token approval.
Never expose secrets in client variables.

12.3 API controls

One-time nonces with short expiration.
Domain and URI binding.
Secure, HTTP-only, same-site cookies.
CSRF protection where required by the session design.
Address normalization.
Rate limiting by address, session, and network edge signals.
Idempotent base claim and reconciliation.
Server-side RPC verification.
Unique transaction-hash constraint.
Structured logs without signatures or credentials.

12.4 Contract controls

Exact-fee requirement.
One-wallet-one-Boost mapping.
Checks-effects-interactions ordering.
Reentrancy guard.
Pausable write path.
Immutable nonzero treasury.
Rejected direct transfers.
Two-step ownership transfer.
No arbitrary Points setter.
No upgradeability in the foundation release unless separately justified and reviewed.

12.5 Deployment controls

Deployment keys must never be committed, logged, placed in public tickets, or exposed through client-side variables. A dedicated deployer should be used, followed by ownership transfer to the approved operational address. A test suite is necessary but is not the same as an independent security audit.

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

13. Operations and Administration

The contract owner is limited to operational safety functions such as pause, unpause, and two-step ownership transfer. The owner cannot edit a user's Boost state, fabricate Points, change historical events, or withdraw funds that are directly forwarded by the contract.

The treasury address is configured at deployment and is immutable in the foundation release. It should be a project-approved operational or multisignature address. The deployment must reject a zero address.

The 0.01 BOT payment may support product development, infrastructure, security review, legal work, or community operations, subject to final legal and accounting review. No depositor relationship, redemption right, profit share, or guaranteed use is created.

Operational monitoring should cover:

API availability;
database health;
RPC health;
contract pause state;
reconciliation failures;
unexpected duplicate attempts;
frontend error rates;
hosting deployment status;
domain and certificate status.

14. Roadmap

Roadmap items describe possible directions and do not create delivery or reward commitments.

Foundation

wallet verification;
100-Point base record;
optional one-time Boost;
Account proof;
public documentation;
production monitoring.

Participation Context

optional, consent-based contribution categories;
clearer proof labels;
community-specific campaigns with explicit rules;
source links for off-chain evidence.

Portable Records

exportable signed summaries;
machine-readable profile state;
consent-based integrations;
standards review for attestations and credentials.

Open Coordination

transparent campaign creation policies;
community review workflows;
role and permission models;
evidence-based contribution programs.

Interoperability Research

standards-based attestations;
selective disclosure research;
cross-application portability;
privacy-preserving proof experiments after security review.

No roadmap stage guarantees a token, airdrop, allocation, Points conversion, governance right, or financial benefit.

15. Risks and Limitations

Smart-contract risk

Code may contain defects, interact unexpectedly with a treasury contract, or behave differently under network conditions.

Wallet risk

Users may use a compromised wallet, approve a misleading request, or lose access to keys.

Network risk

RPC, explorers, validators, or indexing services may be delayed, unavailable, or inconsistent.

Frontend risk

A compromised frontend may show incorrect transaction details. Users should verify the wallet prompt and configured contract.

Backend risk

Session, database, or reconciliation defects may delay or incorrectly display application-level Points. Deterministic constraints and audit logs reduce but do not eliminate this risk.

Privacy risk

Public wallet activity can be analyzed and linked with other public or off-chain information.

Treasury risk

A configured treasury may be compromised, unavailable, or legally restricted.

Regulatory risk

Rules affecting digital assets, points programs, consumer disclosures, privacy, and blockchain transactions vary and may change.

Expectation risk

Users may incorrectly assume that Points or a payment guarantee a future token or financial return. Clear non-promise language must remain visible.

Identity limitation

A wallet record does not prove a unique human, legal identity, contribution quality, or reputation.

16. No Token or Airdrop Commitment

repodaofi has not promised a token or an airdrop.

Points do not guarantee:

eligibility;
allocation;
conversion;
monetary value;
a snapshot;
a reward date;
governance rights;
access rights;
profit;
yield;
reimbursement;
future utility.

Users should not sign, transact, or pay 0.01 BOT because they expect a financial return. Any future program, if introduced, may use different criteria, exclude earlier activity, change before launch, be unavailable in some jurisdictions, or be cancelled.

17. Legal and Regulatory Considerations

The first release should receive project-owner and qualified legal review before public production use. Relevant topics may include consumer disclosures, points-program treatment, digital-asset regulation, sanctions, taxation, privacy, marketing claims, treasury accounting, and jurisdictional availability.

repodaofi is not a bank, broker, exchange, custodian, investment adviser, identity authority, or government service. The product does not provide financial, legal, tax, identity, compliance, or security advice.

Users are responsible for wallet security, transaction review, fees, applicable law, and tax consequences.

18. Conclusion

repodaofi starts with a small, verifiable promise.

A user connects a self-custody wallet, proves control through a readable signature, receives one limited base record, and decides whether to create one optional on-chain proof. Every state has an explicit source, and every limitation is visible.

This foundation does not solve open-source funding, contribution measurement, identity, governance, or coordination by itself. It establishes the behavior required before more complex systems are credible:

informed user action;
deterministic state;
clear proof;
minimal data collection;
self-custody;
no fabricated activity;
no unsupported token promise.

Participation that can be proven—without promising what has not been built.