# ZImburse: Proactive Reimbursement for Crypto-Native Organizations

## Summary



Work in the crypto ecosystem often presents situations where grantees pay for costs upfront, and some company or foundation eventually *reimburses* them for the funds. This slow, reactive, and bureaucratic process is an ironic antithesis of the infrastructure these organizations are building. We propose *ZImburse*: an Aztec-based web app for instant self-authorizing reimbursement dictated by organizational policies.

There are two classes of users in ZImburse:
* Escrow managers, who fund the escrow contract and set policies for reimbursement
* Grantees, who use ZKEmail.nr to verifiably self-execute claims over entitlements to reimbursements on things like travel and hosting costs.

We build this application from a perspective of a real problem we and many others face- just see [DaoHaus's Cookie Jar](https://docs.daohaus.club/sdk/starter/examples#cookiejar) extension. If ZImburse can achieve a reasonable UX, the likely adoption would lead to drastically reduced friction and overhead for organizations and contributors in web3 alike.

## Methodology
In the MVP, there are three types of costs we can reimburse:
* Ride sharing (Lyft, Uber)
* Flights (United Airlines, American Airlines, Frontier Airlines)
* Hosting costs (AWS, Linode)

We can't include every service provider for each of these categories without having had generated a receipt through them, so our inclusion in the MVP will be limited to those we already have access to, including but not limited to the service providers listed above.

### General Architecture of Reimbursement
We've mapped out an initial secure but unoptimized version of verifying a monthly hosting cost below:

This is the general flow:
1. Admins should privately "enroll" grantees in the organization to allow them to claim organization-wide entitlements. This can be nullified by adding an additional nullifier check for users.

2. Admins will fund their ZImburse escrow contract with as much money as they think they will need. This should be done repeatedly as needed to top up grant funding.

3. Admins will create "Entitlement Notes" which are either made available publicly and immutably (for organization-wide entitlement) or added to a user's set of entitlement notes.

4. A grantee who is eligible for a given entitlement will use the corresponding email verifier function (circuit) to prove the authentic receipt of the email from an authorized service provider.

5. The verification exports all information needed to track the root of trust of the email, nullify against repeated use, evaluate whether the receipt applies for a given timeframe, and determine the value eligible for reimbursement.

6. A private call is used to prove access to entitlement notes (kernel), potentially to check timeframes, determine the reimbursement value, and generate any nullifiers and tree roots used publicly.

7. A public call is used to check the used DKIM pubkey, check for any existing nullifiers that prevent the user or email from being used, insert a new nullifier to "consume" the receipt in the contract, and finally release shielded tokens to the grantee according to the reimbursement policy.

The enumerated steps are for the specific case of hosting entitlements recurring monthly, however travel entitlements have a few extra steps around matching admin-defined locations and range-checking dates for receipts. We haven't mapped everything out down to exact specifics, and expect there are certain abstractions we will make that could afford a one-size-fits-all approach to entitlement notes and potentially even email verification.

#### ZKEmail.nr

Mach 34 has actually already built a functioning [ZKEmail.nr](https://github.com/Mach-34/zkemail.nr/) library with the following capabilities in circuit:
* RSA signatures over the header of an email
* Base 64 decoding of body hashes from email headers
* Hashing email body content and comparing it to the decoded body hash from the header
* Demonstration of the use of [Noir String Search](https://github.com/noir-lang/noir_string_search) to prove the recipient of an email is from a gmail domain (this is highly application specific and will require developer input, hence the "demo")

Additionally, there is a rust command line that is used to perform the end-to-end transformation of `.eml` files into a Prover.toml that performs these checks. Our code was derived by [Olehmisar (Shield Swap) already](https://gist.github.com/olehmisar/8b7231039985877b10ad9b0983a3b74d), which has proven the efficacy of the pattern to drive logic in the Aztec sandbox.

Outstanding components included or desired by traditional ZKEmail are described more below.

##### Partial Body Hashing
Noir exposes the ["sha256_compression"](https://github.com/AztecProtocol/aztec-packages/blob/dda1616ae3c3f8afd9131e9d0dde4cbb896adb55/noir/noir-repo/noir_stdlib/src/hash/mod.nr#L141) black box function, meaning partial body hashing is readily available for integration. The majority of the work involved will be in the input generation library.

##### Quoted Printable Encoding
ZImburse will not immediately prioritize the inclusion of Quoted Printable Encoding- the NCR application specifically asks to focus on an end-user application. We can fully build an MVP proving that DAO's, companies, and foundations can use this infrastructure to facilitate proactive reimbursement policies without dedicated QPE decoder circuitry.

Work here can be prioritized over optimization and inclusion of as many additional sources of receipts as possible.

##### JS Library for Input Generation
ZKEmail.nr is written as a rust CLI. ZImburse as an Aztec dApp is a browser application interfacing with the official JS-based PXE, meaning we need to do the light work of reworking the rust CLI into a library with WASM bindings so that we can drive the input generation in a browser environment.

##### String Search vs Regex
There are many teams that have already proposed building regex in Noir and it is capitally inefficient for Aztec to fund R&D of two competing libraries when the success of one is already high.

We strongly posit that [string searching](https://github.com/noir-lang/noir_string_search) is sufficient in the vast majority of cases, most importantly the header. Restricted to the header, there is no situation where, for instance, the string "to:" will appear anywhere other than as the recipient field in the header. In fact, this is likely the optimal path as regex will undoubtedly be more expensive. We additionally believe that string searching is sufficient (if a bit unweildy) for any query run over the body in our specific usecase.

As another team delivers their implementation of ZK-Regex, we would review the implementation and determine whether it makes sense to integrate into queries made over the body of the email.

## Timeline
Forecasted dates are derived from a September 5th, 2024 reveal of the chosen proposals and are subject to be moved back in the unlikely event that finalists are not selected by then.

### R&D (Week 1)
**Sept. 6 to Sept. 12**
* Scoping out how each email for each provided service must be verified
* Diagramming of all user flows (this is done to give space to challenge existing notions of how this will be built, in service of finding abstractions that decrease per-unit implementation costs. Nice side effect of strong documentation)
* Very rough mocks of UX
* Browser integration of ZKEmail.nr + wasm bindings for basic emails
* Quick exploration of Browser wallet options + testing their use
* Either Oleh's WalletConnect or Porco's Metamask Snap most likely, unless another currently unknown option exists

### Hosting Entitlements (Weeks 2-4)
**Sept. 13 to Oct. 3**
* Noir Contract
* Admin
* Ability to deploy a new instance of ZImburse (keeping organizations segregated)
* Funding of escrow
* Add DKIM pubkeys to the tree
* In lieu of a stronger oracle system in the MVP. Will likely have a built in "sync DKIM" utility for admin to query expected/ known selectors, but we also consider this problem outside of the scope of this MVP
* Send a hosting entitlement to an address
* Nullify hosting entitlements given to an address
* Grantee
* Library for circuits used so that all flows can be extended to other chains and integrations if so desired by other applications
* Monthly grant reimbursement for hosting costs using ZKEmail over Linode and AWS receipts
* TXE unit testing for included functionality
* Web app
* Integration of chosen Aztec wallet for login by role + authorizing transactions
* Full ZKEmail.nr proof input generation in JS
* Attach interface & reasonable (but not necessarily final) UX to drive all functionality described in "Noir Contract" section
* Email Ingress: Manual upload of .eml files (allow privacy preservation at the cost of UX)
* "Server"
* Need somewhere to put all merkle leaves and preimages for DKIM pubkey tree. Might dump into IPFS to avoid using a backend
* Might also be included if we want to add ergonomics like labels for the admin
* Fake email/ DKIM signature for malleated emails to drive higher volumes of tests in the Aztec devnet environment

#### Report #1
**Published October 3rd, 2024**
Report on progress will detail the end-to-end integration of a web app driving contracts deployed to the Aztec sandbox

### Travel Entitlements (Weeks 5-7)
**Oct. 4 to Oct. 24**
* Noir Contract
* Admin
* Ability to privately whitelist users for org-wide reimbursements
* Ability to privately nullify users from using org-wide reimbursements
* Ability to send travel entitlements to an address
* Ability to nullify travel entitelements from an address
* Ability to create public, org-wide entitlements
* We will not include the ability to nullify org-wide one time use entitlements unless we find an abundance of time
* Grantee
* Ability to prove an email of a flight or rideshare receipt to receive a one-time travel reimbursement
* Testing
* TXE testing
* End to end TS/ PXE testing demonstrating the use of input generators over emails
* Web app
* Hook up all aztec contract integrations with the sandbox
* Final UX/UI implementation
* GMail integration for scanning email for a specific receipt, as ZKP2P would facilitate with the email-based verification regime
* Additional searching for any and all possible sources of receipts
* Primarily focused on including as many travel and hosting receipts as possible
* If we can include a new class of reimbursable receipt, also *try* to fit in here, time permitting

### Wrap Up & Delivery (Week 8)
**Oct. 25 to Oct. 31**
* Final documentation
* Organization of SWE assets generated in the repo
* Readme with instructions on local use
* Live deployment of web application
* Aztec Devnet deployment
* Technically each org should deploy their own contract so live site should allow this
* Have test site with automated ability to enroll users, send them a dummy email they can reimburse themselves with to test if they can't create a policy to reimburse themselves with the emails they currently have
* The Admin UI should very clearly allow you to opt in (not out) to the dummy DKIM key when creating the dkim tree

#### Report #2
**Published ~November 6th**
We will take up to 1 week upon completion of the ZImburse MVP as we would like to create a writing that pitches the use of the application rather than just acting as a work report. This will likely include some video recordings, creating fake organizations people can easily join and test with fake USDC, etc.

## Start Date
September 6th

## Team Members
The [Mach 34 team](https://mach34.space/team) (Jack Gilcrest and Ian Brighton) will be responsible for delivering this work.

### Aztec Ecosystem Work
* [BattleZips-Noir](https://github.com/battlezips/battlezips-noir) code & [tutorial series](https://www.youtube.com/watch?v=s9SAHxGFkvs&list=PLWACGbvIsEgnR2aUCr9i-PpmTVhF5Zuik)
* Work on Ethan000's [Noir-Halo2](https://github.com/Ethan-000/halo2_backend)
* [Zybil](https://github.com/mach-34/zybil) (Sandbox Feedback Partner #1) and continual feedback on DevEx, feature requests, bug discovery, etc
* [Aztec State Channels](https://github.com/mach-34/aztec-state-channels), a native implementation of peer-to-peer incremental state construction built by modifying the PXE to allow a specifically constructed transaction on Aztec to be done by multiple distrusting provers (worked with brute force recursion but doesn't work with protogalaxy folding 😔)

### EF PSE Work
* [BattleZips-Halo2](https://github.com/battlezips/battlezips-halo2) - battleships written in Halo2-IPA
* [The Word](https://github.com/mach-34/the-word), a fun experimental CLI-based social game for using ZKP's of secrets shared in out of band channels to see how large a group can grow before a secret becomes public (includes integration with ZuPass)
* [Grapevine](https://github.com/mach-34/grapevine), a social graph CLI and library built with Nova folding to recursively prove degrees of separation from an identity

## Questions
What other receipts could we verify asides from hosting costs and travel receipts?

Can we inverse partial hashing to get the content at the start of an email?

How do we reconcile payments in alternative currencies? This oracle problem does not seem fun to solve in the private context; it would be much better if there were stablecoins on DEX's to use

Is it worth including ZK Passport to allow escrow managers to make commitments to names and grantees to prove ownership of matching commitments to add a layer of identity verification? Do we need them to also commit to nicknames that may appear if we want to check names on emails?

Can we abstract entitlement notes to "Spot" (one time use) and Monthly?

With PDF parsing, can we obtain more receipts? For instance, we wanted to include hotels but found most invoices were included as PDF attachments to emails.

Can we provide labels to addresses without using a server? Or does it make far more sense to have an end-to-end encrypted server to map names to addresses instead of relying on encrypted storage in Aztec (which will be public when iOS 99 ships with quantum computing) (should we add this to the deliverables because we probably need this)

Can we use the L1/L2 message bridge to extend functionality from a ZImburse instance deployed on Aztec to L1 Ethereum? Obviously on L2 the only reasonable option is to redeploy a version of this infrastructure with inferior privacy properties