# Proof of Hack

## goal

find a way to prove, on-chain, that a protocol can be hacked for an amount `X > bounty`, without giving away the details of the vulnerability

* proof must be checkable on-chain by a contract
* proof must somehow show that `> bountyAmount` tokens can be moved out of the contracts due to a bug (i.e. illegitimately)

## why
The hacker can use this proof to force the vault to pay out the bounty if the committee is not cooperative

## what is a hack

For the purposes of the proof of hack, a hack is:

> A valid hack is a transction that allows an attacker to illegitimately move X$ worth of funds to an address of this choice (where X > bountAmount)

## the protocol

0. _hacker_ goes through the usual channels: finds a vulnerability, submits a bug report, but the committee is not paying out
1. _hacker_ creates a proof of hack that demonstrates that X amount of funds can be moved out of the protocol.
1. _hacker_ sends proof of hack to protocol and gets the bounty

## what is a "proof of hack"

> A proof of hack is a zkEVM proof of a valid state transition such that:
>
>1. the initial state of the proof is in (very) recent history, or in >any case is at a actual historical ethereum state that contains the >contracts covered by the bounty
>2. the output state, X funds are transfered to the hacker's address (or the zero addres, it does not matter maybe)
>3. the state transation used the contracts "illegitimately"

Basic difficulty is to distinguish "illegimate" moving of funds from "legitimate" transfers (i.e. normal withdrawal).

There is this idea by shay that a hacker could "prove" that the funds are not his by putting them at risk in exchange for the bounty, i.e. to somehow submit a transaction like this:

> if the bounty is not paid (before time _t_) then X$ of tokens are burned

it is only rational to submit this transaction if the submitter is not the legitimate owner of the X$ of token

However, it seems inevitable that in that case the vulnerability is disclosed (and the team could fix it instead of paying out the bounty)

Another idea is to abandon the idea of legitimacy altogether, and instead pay out bounties on the basis of invariants that are broken:

> 1. Subject for the proof of hack bounties are *invariants* on ethereum states defined by the project, such as "the total amount of shares should equal the total amount of deposited funds"
>1. A proof-of-hack is a zkEVM proof of a valid state transition from a recent ethereum block to a new block in which the invariant is false