# Using UPA in your ZK app

### ZK apps before UPA In a typical ZK app: * The client makes requests of the app contract. Each request contains public inputs`PIs` along with a proof that those public inputs were valid. * The app contract calls a `verify` function that checks whether a request's `(PIs, proof)` pair is valid or not. If the request was valid, then the app contract executes the corresponding business logic. ### ZK apps after UPA In a UPA-integrated ZK app, the UPA contract takes over the responsibility of proof verification. The client now makes a `AppRequest` in two stages. * First, they submit `(PIs, Proof)` to the UPA contract. If the proof is valid, then after some time the `PIs` are marked as verified in the UPA contract. * Second, they make an `AppRequest(PIs)`. The app contract checks whether `PIs` has been marked as verified on the UPA contract. If so, the app goes on to execute the request. The client saves gas because UPA verifies batches of proofs rather than individual proofs. ### What the UPA contract does The UPA contract verifies batches of proofs as follows. * The UPA contract receives a `submit(PIs, Proof)` call. * An off-chain proof aggregator adds the `(PIs, Proof)` pair to a batch. Then it produces a ZK proof `aggregatedProof` that all of the `(PIs, proof)` pairs in that batch are valid. It then sends the `aggregatedProof` to the UPA contract. * The UPA contract only needs to verify a single proof: `aggregatedProof`. If correct, then the contract marks all of the proofs in the corresponding batch as valid.