# Z-Imburse Docs: ZImburseRegistry

The Z-Imburse registry provides three main functions
* Guarantee integrity of ecrow contracts
* Central DKIM keyhash registry
* Entrypoint for escrow contract discoverability

:::info
The registry is a bit of an experiment into parent/child contracts, however in the context of optimizing proving speeds we forsee a scenario where the escrow registry functionlaity is abandoned and the DKIM key registry functionality is moved to the escrow contract. This would require escrow operators to synchronize their keys manually, but it would save recursive calls from an escrow contract to the registry contract.

The discoverability and labeling functionality provided by the escrow contract would be moved to an end-to-end encrypted database at the cost of decentralization.
:::

### Table of Contents
[Escrow Contract Registration Integrity](https://hackmd.io/@IQZ-5dJ4QGGu4K6oX71X7w/r1_zlMAlke)
[DKIM Registry](https://hackmd.io/@IQZ-5dJ4QGGu4K6oX71X7w/BkLcTW0g1l)
Participant Registry

## Escrow Registry Constructor
The escrow registry initializer sets the "definition" of the contract as well as providing the opportunity to set DKIM key hashes in the same transaction.

#[public]
#[initializer] 
fn constructor(
        usdc: AztecAddress,
        escrow_contract_id: Field,
        verifier_ids: [Field; BULK_KEY_LENGTH],
        dkim_key_hashes: [Field; BULK_KEY_LENGTH]
)

The primary function of the constructor is to set the `definition`. This consists of an address for the payment token used in escrows `usdc`, the unique contract class ID of escrow contracts `escrow_contract_id`, and the `admin` retrieved from context.

In version 1, we defer the rights to add DKIM keys to a permissioned superuser. This is obviously not ideal in production. In the future, options to rectify this include:
* Making DKIM key registration the responsibility of each escrow admin, giving agency to the reimbursement policy dictator.
* Involving a governance DAO that must ratify changes to the DKIM registry
* Oraclized ingestion of new DKIM keys
Recommendations on the best practice are desired, but we recognize the security vulnerabilty here and purposely chose to neglect fixing it in the PoC.