White paperDraft 1, September 2026

Wallet safety infrastructure for Web3

How Pavoriz puts what is known about a dApp, an address or a project in front of somebody at the moment they sign, and gives them a way to take permissions back.

Start reading
chains across nine ecosystems
70
chains across nine ecosystems
threat feed entries
438K
threat feed entries
named exploit incidents
1,250
named exploit incidents
lost across those incidents
$20.22B
lost across those incidents

01

Abstract

Pavoriz is a security layer that sits between a person and the decentralised applications they use. It brings what is known about a dApp, an address or a project to the moment somebody is about to sign, and gives them a way to take back permissions they have already given.

The platform is a web application, a companion browser extension, a multi chain approval scanner, a threat intelligence pipeline and two Solidity contracts. It spans 70 chains across nine ecosystems.

02

The problem

Every interaction with a dApp asks a wallet to hand a contract a standing permission. Those permissions do not expire, and they pile up across every chain a person has ever used. Most people hold dozens of live approvals to contracts they cannot name.

The failure is not that people make bad decisions. The information needed to make a good one is spread across block explorers, security feeds, incident databases and calldata nobody can read, and none of it is in front of somebody when they press Confirm.

03

The platform

Pavoriz answers four questions that today take four separate products:

  • What has this wallet already given away, and what does it put at risk? (the Revoke console)
  • Is this dApp safe to use right now, while I am on it? (Pavoriz Shield)
  • Is this address or website already known to be dangerous? (threat intelligence)
  • Is this project what it claims to be? (the Project Trust Check)
A person and their wallet
Pavoriz security layer

01

Revoke console

What has this wallet already given away?

02

Pavoriz Shield

Is this dApp safe right now, while I am on it?

03

Threat intelligence

Is this address or site already known to be dangerous?

04

Project Trust Check

Is this project what it claims to be?

dApps
Contracts
70 chains
Figure 1Pavoriz sits between the wallet and everything it signs for, and answers four questions before the signature.

04

Revoke console

Reads a wallet's live token approvals across 65 chains, names the contracts holding them, and sends the transaction that takes them back.

  • Value at risk is the smaller of the allowance and the balance, priced from a live feed. A spender can only take what is there.
  • Revoking runs in four ordered steps: build the calldata, switch to the right chain, simulate, then send. A call that would revert fails before the wallet is asked.
  • ERC-20 allowances, single NFT approvals and operator approvals are kept apart, because they are three different calls.
1Build

Calldata from the stored standard. Anything it cannot build exactly is refused.

2Switch

To the chain the approval lives on. Across 65 chains this is the usual case.

3Simulate

A call that would revert fails here, before the wallet is asked.

4Send

Then wait for the receipt. A reverted receipt is not a success.

Figure 2Every revoke takes the same four steps, in the order that fails cheapest first.

05

Pavoriz Shield

A Manifest V3 browser extension that protects a session while it is happening.

  • Always on protection: launching a dApp through Pavoriz enrols it, so a later direct visit arms the Shield on its own.
  • Every wallet request is graded before it reaches the wallet, with an allow and block prompt carrying the Pavoriz mark.
  • A revoke is offered the moment an approval is granted, while the person is still looking at the screen.
  • Only the host leaves the browser, never the path or the query, and only for hosts already under the Shield.
dAppasks the wallet to sign
Shield grades the request
LowMediumHigh
Walletsees it only after the person chose
Pavoriz ShieldHigh risk

Unlimited approval requested

This lets the contract move every USDC this wallet holds, now and later.

BlockAllow anyway
Pavoriz ShieldApproval granted

Take it back now?

The wallet accepted. One transaction sets the allowance back to zero.

RevokeLeave it
Figure 3A wallet request passes through the Shield before the wallet sees it, and an approval that goes through is met with the offer to undo it.

06

Auto revoke

Lets Pavoriz send the transaction that clears a dangerous approval without asking for a signature when it fires. One mechanism per ecosystem, each chosen so that a total compromise of Pavoriz achieves nothing beyond cancelling approvals somebody wanted cancelled.

Solana

Pavoriz holds

A durable nonce transaction, signed once

Bounded by

The signed bytes

Held and broadcast when a trigger fires. The fee is fixed inside what was signed.

Cosmos

Pavoriz holds

An authz grant for MsgRevoke only

Bounded by

Chain consensus

Plus a capped feegrant. Sixteen chains, no contract to audit.

EVM

Pavoriz holds

An EIP-7702 delegation

Bounded by

2,736 byte contract

Three revoke calls and nothing else. Ended by delegating to address zero.

Worst caseA total compromise of Pavoriz cancels approvals. It cannot move a token anywhere.
Figure 4One mechanism per ecosystem. In each, the most a total compromise of Pavoriz can do is cancel approvals.

07

Threat intelligence

Four public blocklists fetched from their publishers on a schedule, an incident index, and a victim graph Pavoriz builds itself by reading drainer activity directly off chain logs.

438,200

Threat feed entries

435,670

Phishing hosts

2,530

Known drainer addresses

1,250

Named exploit incidents

$20.22B

Lost across those incidents

4,496

Victim edges read off chain

Figure 5What the pipeline holds today. The victim graph is read off chain logs by Pavoriz rather than taken from a publisher.

08

Project Trust Check

Paste a project's website, its contract address, or both. Pavoriz gathers what is publicly there from fifteen sources and grades it across four groups: the contract, the website, the identity history, and what the project claims against what was found.

Confidence is reported separately from the score, so how much could be read is never confused with how good the answer was. A check that could not run is removed from both sides of the score rather than counted as zero.

A

The contract

Honeypot, hidden owner, mint, blocklists.

B

The website

Certificate, domain age, phishing lists.

C

Identity history

Account age, renames, handle moves.

D

Claims vs findings

What the project says against what was read.

Scorehow good it looked
Confidencehow much could be read

Below half confidence there is no score at all. A check that could not run leaves both sides of the fraction.

Figure 6Four groups graded separately. Confidence says how much could be read; the score says how good it looked.

09

Contract design

Both contracts follow one principle: the aim is not a contract nobody can break, it is one where breaking it completely gets the attacker something worthless.

  • SpotlightEscrow, on BNB Chain at 0xd8349cf26ddbe37350cf75bd5d8c14a64b42815d, holds placement payments until a decision moves them: settled on approval, refunded on rejection. The server key cannot name a destination or withdraw.
  • PavorizRevoker compiles to 2,736 bytes with no DELEGATECALL, no SELFDESTRUCT, no CREATE and no storage at all. It deploys to one canonical address on every chain.

PavorizRevoker

2,736 bytes

Not in the bytecode

DELEGATECALLCALLCODESELFDESTRUCTCREATESSTORESLOAD

Its only writes

revokeAllowancerevokeTokenrevokeOperator

SpotlightEscrow

BNB Chain
Applicant pays
Held in the contract

Approved

settled to owner

Refused

refunded to payer

Figure 7What each contract leaves out is the security argument. Both are checked against the compiled bytecode, not the source.

10

The $PAVO token

PAVO is the utility token for the Pavoriz platform. The product already has a place for it: the Pavo fee on automatic revokes and the gas tank are priced in dollars and collected in a token an administrator chooses, starting with a stablecoin and moving to PAVO once that is a decision worth making.

  • Paying for protection: auto revoke fees and gas tank top ups.
  • Governance: a proposal board for holders, kept separate from the monthly dApp vote.

Tokenomics (total supply, allocation, vesting and launch venue) will be published here before the token launches. Until then there is no official PAVO contract, and anything claiming to sell PAVO is not Pavoriz.

11

Design principles

  • Nothing invented is presented as measured. A dApp nobody has opened reads Not measured rather than showing a number.
  • A failed read is never a clean result. A check that could not run says so, and a feed that shrinks by half is refused rather than trusted.
  • Every measurement is a script that can be re-run, not a constant somebody typed once.

12

Where it goes

  • Distribution: publish the Shield to the Chrome and Firefox stores, cover off chain signatures, and notify people when a new approval appears on a wallet they watch.
  • The data as a product: address reputation, then a keyed public API over the threat, exploit and approval data.
  • Reach: WalletConnect, then a Pavoriz mobile browser with the Shield built in, carrying alerts, the Revoke console, the directory and the trust check.
  • Depth: a security audit of both contracts, auto revoke in production, then the token and governance.
  1. 1

    Distribution

    • Shield in the Chrome and Firefox stores
    • Off chain signatures
    • New approval alerts
  2. 2

    Data as a product

    • Address reputation
    • A keyed public API
  3. 3

    Reach

    • WalletConnect
    • A mobile browser with the Shield built in
  4. 4

    Depth

    • Audit of both contracts
    • Auto revoke in production
    • Token and governance
Figure 8Four tracks, in the order they unlock each other.