# Fact Registry Contracts

## Fact Registry

The Fact Registry design pattern is a way to separate statements verification from the business logic of the contract flow.

A fact registry holds a hash table of verified “facts” which are represented by a hash of claims that the registry has checked and found valid. This table may be queried by accessing the `isValid` function of the registry with a given hash.

In addition, each fact registry exposes a registry specific function for submitting new claims together with their proofs. The information submitted varies from one registry to the other depending of the type of fact requiring verification.

For further reading on the Fact Registry design pattern see this blog post.

StarkEx uses the following fact registries:

## STARK Verifier for Cairo Programs

Verifies programs that are written in Cairo. Specifically, it verifies the computational integrity of executing a Cairo program `P` on an input data `D`, and the correctness of the post-execution state of the system.

The verifier gets as part of the input a hash of the program `P`.

## Committee Signature Verifier

Verifies the availability proof in Validium. Reverts if invalid. An availability proof should have a form containing a concatenation of signatures by signatories. Signatures should be sorted in ascending order by signatory address. Signatures should be 65 bytes long. r(32) + s(32) + v(1). There should be at least the number of required signatures as defined in this contract and all signatures provided should be from signatories.

See `Availability Verifiers` for more information on when this is used.

## Escape Verifier

Verifies that the contents of a vault belong to a certain Merkle commitment (root).

The Merkle commitment uses the Pedersen hash variation described next:

• Hash constants: A sequence $p_i$ of 504 points on an elliptic curve and an additional $ec_{shift}$ point

• Input: A vector of 504 bits $b_i$

• Output: The 252 bits x coordinate of $(ec_{shift} + \sum_i b_i*p_i)$g

The following table describes the expected `escapeProof` format. Note that unlike a standard Merkle proof, the `escapeProof` contains both the nodes along the Merkle path and their siblings. The proof ends with the expected root and the ID of the vault for which the proof is submitted (which implies the location of the nodes within the Merkle tree).

starkKey (252)

assetId (252)

zeros (8)

hash(starkKey, assetId) (252)

quantizedAmount (252)

zeros (8)

left_node_0 (252)

right_node_0 (252)

zeros (8)

…​

left_node_n (252)

right_node_n (252)

zeros (8)

root (252)

zeros (4) | vaultId (248)

zeros (8)

If the proof is accepted, this is registered under the following claim hash that may later be queried for validity:

`claimHash = keccak256(starkKey, assetId, quantizedAmount, vaultRoot, treeHeight, vaultId)`