Proof Request Life Cycle

For a deployed proof system, a Proof Request life cycle proceeds as follows.

1. The Seeker submits a Proof Request to Matchmaker through the RPC server. The Proof Request contains a pointer to the CDN URL hosting the proof system details and other computation details required to generate a proof. Note that these details within the Proof Request are actually signed with Seeker's whitelisted key.

2. The Matchmaker verifies that Seeker is whitelisted and triggers a task assignment process.

   1. Note that, when an Operator registers to serve on Fermah AVS through the EigenLayer middleware contracts, it commits its availability for a certain period of time. Currently, the default is set to a minimum of 500 blocks, or 15.625 Ethereum epochs. It also specifies the hardware configuration that it would commit to serving Proof Requests on Fermah. The Matchmaker logs that information from the EigenLayer middleware contracts.

   2. The Matchmaker runs through the list of available Operators and assigns a given task to the first one that has a compatible hardware configuration (one that is equivalent or stronger than the required configuration). Currently, the required configurations for deployed proof systems are hard-coded into the Matchmaker.

   3. The Matchmaker tracks the status of all Proof Requests that Seekers can query and obtain. Let's discuss the current timeout settings.

      1. The Seeker has an option to set a time limit for which it is willing to wait for proof generation. If no proof gets generated on time, then the Proof Request status is set to REJECTED.

      2. If no time limit is set by the Seeker, the Operator sets a default time limit of 1 hour. If no proof is generated in this time, the Operator sends an error message to the Matchmaker to mark the Proof Request as REJECTED.

   4. Once Matchmaker receives a proof, it relays the proof to the Seeker's callback URL.