PROVADO (PRV) — Whitepaper v0.1

Verifiable reputation for market analysis Discussion draft — September 2026

Table of contents

1. Executive summary
2. The problem
3. The solution
4. How the protocol works
5. The PRV token
6. Tokenomics
7. Technical architecture
8. Governance
9. Security and risks
10. Regulatory considerations
11. Roadmap
12. Team and treasury
13. Step-by-step execution plan
14. Glossary

1. Executive summary

Provado is a protocol where market analysts publish predictions ("calls") with stake at risk, and their track record is recorded immutably and auditably on-chain. Analysts who are right build reputation and earn rewards; analysts who are wrong lose part of their stake. Followers pay only for access to analysts with a proven history — not for promises.

The PRV token is what makes the system work: it is used as collateral (stake) on predictions, as the payment currency for subscriptions, and as voting power in governance.

In one sentence: Provado turns "trust me" into "verify my record."

2. The problem

The crypto signals and analysis market moves billions but operates with almost no accountability:

• Unverifiable track records. Signal groups show only their wins; losses are deleted or never published.
• Zero skin in the game. The analyst earns the subscription regardless of outcome. The follower is the only one who loses money.
• High cost of discovering good analysts. A trader has to pay for several groups and lose capital to find out who actually delivers.
• Inverted incentives. The more sensational the call, the more subscribers — accuracy is not rewarded.
• No portability. Reputation built on Telegram dies on Telegram; it is not an asset the analyst owns.

None of these failures are fixed by "one more group." They require a neutral record-keeping layer where lying has a cost and being right has a reward.

3. The solution

Provado is a record-keeping and incentive layer with three participants:

Design principles

1. Record before outcome. A call only counts if it is registered on-chain with a hash and timestamp before the predicted event.
2. Stake proportional to confidence. The analyst chooses how much to stake; higher stake means more weight in the reputation score (and a larger loss if wrong).
3. Objective resolution. Calls are resolved by price oracles (e.g. "BTC above X by date Y"), not by opinion.
4. Reputation as an asset. The analyst's score is a non-transferable (soulbound) NFT they carry to any platform.

4. How the protocol works

4.1 Lifecycle of a call

Analyst → creates call (asset, direction, target, deadline, stake)
       → call is registered on-chain (hash + timestamp)
       → content hidden from non-subscribers until deadline
       → deadline passes → oracle fetches price → call resolved
       → CORRECT: stake returned + reward from pool
       → WRONG: part of stake goes to the reward pool
       → reputation score updated

4.2 Structure of a call

4.3 Resolution

• Target hit before invalidation and within the deadline: correct.
• Invalidation hit first: wrong.
• Deadline passes without touching either: neutral (stake returned, no reward, small network fee).

Prices come from decentralized oracles (Chainlink or Pyth) aggregating multiple sources, which removes manual disputes.

4.4 Reputation score

The score is not a simple hit rate — that would reward easy calls. It combines:

• Stake-weighted hit rate (higher-stake calls weigh more)
• Calibration — if an analyst declares 70% confidence, they should be right on roughly 70% of those calls. Overconfidence is penalized.
• Risk/reward ratio of the calls (distant target with a tight stop is worth more)
• Time decay — older calls weigh less, reflecting current performance
• Minimum volume — the score is only displayed after 20 resolved calls

4.5 Subscriptions

Followers pay PRV to see an analyst's calls before resolution. The analyst sets the price. The protocol keeps a fee (see section 6) and the rest goes to the analyst.

4.6 Penalties and anti-manipulation

• Call spam: minimum stake per call and a cap on simultaneous open calls per analyst.
• Contradictory calls (long and short on the same asset/deadline): detected and voided, with stake forfeited.
• Sybil (multiple accounts): the score requires history; new accounts confer no advantage, and the minimum stake makes the attack expensive.
• Oracle manipulation: multiple sources and a time window, not an instantaneous price.

5. The PRV token

5.1 Functions

5.2 Specification

• Standard: ERC-20
• Network: Base (Coinbase's L2 on Ethereum) — low cost, Ethereum security, good liquidity
• Max supply: 1,000,000,000 PRV (fixed; no inflation beyond scheduled emissions)
• Decimals: 18

6. Tokenomics

6.1 Initial distribution

Rationale: more than half of supply goes to those who use and govern the protocol. Team and investors total 27% with long vesting — below the market average, signaling long-term commitment.

6.2 Value flow

Subscriptions ─┐
Call fees ─────┼──► Protocol fee (10%) ──► 50% burned
Penalties ─────┘                            30% reward pool
                                            20% treasury

• Burn: creates deflationary pressure proportional to real usage.
• Reward pool: fed by penalties and emissions; distributed to analysts with correct calls, weighted by stake and difficulty.
• Treasury: funds development, audits and incentives.

6.3 Emission schedule (rewards)

High early emission attracts analysts before subscription volume exists; afterwards the protocol must sustain itself on real fees.

6.4 Staking mechanics

• Minimum stake per call: 100 PRV (adjustable by governance)
• Loss on a wrong call: 30% of stake (adjustable)
• Reward on a correct call: proportional to stake × (1 − declared confidence) — staking heavily on something you declared unlikely pays more

7. Technical architecture

7.1 Layers

┌──────────────────────────────────────┐
│  Frontend (web + app)                │  Next.js, wallet connect
├──────────────────────────────────────┤
│  Indexer / API                       │  The Graph or Ponder, score cache
├──────────────────────────────────────┤
│  Smart contracts (Base)              │  Solidity
│   ├─ PRVToken.sol (ERC-20)           │
│   ├─ CallRegistry.sol                │  call registration and resolution
│   ├─ Staking.sol                     │  stake, penalty, reward
│   ├─ Reputation.sol                  │  soulbound NFT + score
│   ├─ Subscription.sol                │  subscriptions and revenue split
│   └─ Governance.sol + Timelock       │  OpenZeppelin Governor
├──────────────────────────────────────┤
│  Oracles                             │  Chainlink Data Feeds / Pyth
└──────────────────────────────────────┘

7.2 Call privacy

Calls use commit-reveal: at registration only the hash goes on-chain (proof of prior existence). The content is stored encrypted on IPFS, with the key released to subscribers. At the deadline the content is revealed publicly so anyone can verify it.

7.3 Why Base

• Transaction fees in the cents — essential for frequent calls
• Inherits Ethereum security
• Active ecosystem, mature tooling (Foundry, Hardhat, OpenZeppelin)
• Alternatives considered: Arbitrum (similar), Solana (cheaper, but Rust tooling and audits are more expensive)

7.4 Recommended stack

• Contracts: Solidity 0.8.x, Foundry for testing, OpenZeppelin as base
• Audits: two independent audits before mainnet
• Frontend: Next.js + wagmi + viem
• Indexing: Ponder (self-hosted) or The Graph
• Storage: IPFS via Pinata for call content

8. Governance

• Model: DAO with OpenZeppelin Governor + 48h Timelock
• 1 PRV = 1 vote, with a lock-time bonus (veToken, up to 2× for a 2-year lock)
• Quorum: 4% of circulating supply
• Votable parameters: fees, minimum stake, penalty %, accepted oracles, treasury usage, new call types
• Initial phase (12 months): 4-of-7 multisig with emergency veto, dissolved after progressive decentralization

9. Security and risks

Technical risks

• Contract bug: mitigated by audits, a bug bounty (Immunefi) and a gradual launch with stake caps.
• Oracle failure: multiple sources, circuit breaker if sources diverge by more than 2%.
• Front-running: commit-reveal and time-window-based resolution.

Economic risks

• Low analyst adoption: high initial emission + ambassador program.
• Thin liquidity: liquidity locked 24 months, no team sales in year one.
• Score gaming: calibration and time decay make it hard to exploit with easy calls.

Market risks

• PRV volatility changes the real cost of staking. Future fix: allow stablecoin stake with automatic conversion.

10. Regulatory considerations

This section is a map of points to watch, not legal advice. Consult a lawyer specializing in crypto-assets in every jurisdiction where you operate before launch.

Brazil (home jurisdiction)

• Law 14,478/2022 (Crypto-Asset Legal Framework) and Central Bank regulation: virtual asset service providers (VASPs) require authorization. A decentralized protocol may fall outside the scope, but the entity operating the frontend and any custody may not.
• CVM Guidance Opinion 40: if the token is characterized as a security (expectation of profit from the efforts of others), a public offering requires registration. Designing PRV as a utility and governance token — with real use from day one — reduces but does not eliminate this risk. The public sale is the most sensitive point.
• Taxation: crypto gains are taxable (RFB Normative Instruction 1,888/2019 and Law 14,754/2023 for offshore assets). The structure of the issuing foundation/company matters.
• Analysis content: securities analysts in Brazil need CVM accreditation. For pure crypto the rules are looser today, but that may change. The protocol must state clearly that calls are not investment advice.

United States / EU

• US: Howey test exposure; most projects geo-block US participants from token sales.
• EU: MiCA applies to public offerings of crypto-assets and requires a whitepaper filing for certain categories.

Common legal structure: a foundation abroad (Switzerland, Cayman, Panama) holding IP and treasury, with an operating company in Brazil. It adds cost and complexity — a decision to make with counsel.

11. Roadmap

12. Team and treasury

Minimum viable team to reach mainnet:

• 1 founder / product
• 2 Solidity developers (one senior)
• 1 frontend developer
• 1 community / growth lead
• Outsourced lawyer and accountant
• Outsourced audits

Estimated budget to mainnet: US$250k–500k, with audits as the largest single line (US$60k–150k). This is what the early-investor round needs to cover.

13. Step-by-step execution plan

Stage 1 — Validate the idea (weeks 1–4)

1. Interview 20 analysts and 30 signal-group followers. Core question: "would you register your calls with money at risk?"
2. Build a landing page with a waitlist.
3. Run a pilot without blockchain: a public spreadsheet + call hashes posted on X. If nobody joins without a token, nobody will join with one.
4. Go/no-go criterion: at least 15 analysts willing to join the beta.

Stage 2 — Structure (weeks 5–8)

5. Consult a crypto lawyer on structure (foundation + company) and token classification.
6. Define cap table and founders' agreement.
7. Close the core team (at least the senior Solidity dev).
8. Finalize the whitepaper with pilot feedback.

Stage 3 — Build (weeks 9–20)

9. Write contracts with Foundry; test coverage above 90%.
10. Deploy to testnet (Base Sepolia).
11. Minimal frontend: connect wallet, create call, view score, subscribe to analyst.
12. Closed beta with pilot analysts using test tokens.
13. Iterate the score formula with real beta data.

Stage 4 — Fund (in parallel with stage 3)

14. Prepare pitch deck and data room.
15. Round with crypto funds and angels: 12% of supply for US$300–500k (sets initial valuation).
16. Fallback if no round: fair launch with reduced scope and a smaller team.

Stage 5 — Security (weeks 21–28)

17. Engage two audits (e.g. one boutique + one major firm).
18. Fix everything critical and high; publish the reports.
19. Open a bug bounty.

Stage 6 — Launch (weeks 29–32)

20. Deploy contracts to mainnet behind a multisig.
21. Create a PRV/ETH liquidity pool on a DEX (Aerodrome or Uniswap on Base) and lock the liquidity.
22. Airdrop to beta testers.
23. Open the protocol with low stake caps, raising them weekly.

Stage 7 — Grow (month 9 onward)

24. Ambassador program: high-score analysts earn extra PRV for bringing followers.
25. Publish weekly leaderboards — the leaderboard itself is marketing.
26. TradingView and Telegram integrations (a bot that registers a call on-chain from a message).
27. CEX listings only after proven organic volume — listing too early only attracts speculation.

What to avoid

• Launching the token before the product. A token with no use becomes pure speculation and attracts the wrong crowd.
• Promising returns. Besides being illegal in many scenarios, it contradicts the project's premise.
• Skimping on audits. It is the one line item where cutting cost can end the project.
• Concentrated distribution. Team + investors above 35% is usually rejected by the community.

14. Glossary

• Call: a price prediction registered in the protocol.
• Stake: tokens deposited as collateral on a call.
• TGE (Token Generation Event): the moment the token comes into existence and starts circulating.
• Vesting: gradual release of tokens over time.
• Cliff: initial period with no release at all.
• Oracle: a service that brings external data (prices) on-chain.
• Soulbound NFT: an NFT that cannot be transferred — permanently tied to one wallet.
• Commit-reveal: registering a hash first and revealing the content later, proving it existed beforehand.
• DAO: an organization governed by token-holder voting.
• VASP: virtual asset service provider, the term used in Brazilian regulation.
• Multisig: a wallet that requires several signatures to execute a transaction.