Workflow

Interaction between Actors in a Kalypso Market primarily involves the following scenarios:

1. Registration of the Matching Engine: A Kalypso protocol run service over Oyster. v1 features an orderbook-based algorithm over a single Oyster node.
2. Creation of a Market: Any one can create new Markets if an existing Market doesn't satisfy a ZK app or protocol's requirements.
3. Registration of the Input Verification Service: Any one can operate the service to check validity of inputs when they are private or can't be checked on-chain. It is expected to be the Market Creators themselves.
4. Registration of Generators in Market: Any one can generate proofs for any of the listed Markets. Some Markets may require TEE support.
5. Proof request and delivery lifecycle: Any one can place requests and fetch ZK proofs for listed Markets with suitable registered Generators.

📄️ Registration of the Matching Engine

Anyone can run the Matching Engine as an enclave inside an Oyster Node.

📄️ Creation of a Market

As mentioned earlier, Market Creators are responsible for creation of markets. New Markets are required when an existing Market is not suitable for generating proofs for a certain circuit (that is, the app uses a whole new circuit that no other app on Kalypso uses) or when parameters like slashing rates or minimum stake are to be updated to meet a new range of guarantees.

📄️ Registration of the Input Verification Service

In cases where inputs are private, the Generator Image contains the input verification logic. As the Generator Image itself runs inside a secure enclave, attestations from a whitelisted Generator Image (which will normally be run by the Generator itself) claiming that inputs are wrong are considered valid by the Input Verifier.

🗃️ Registration of Generators in a Market

1 item

📄️ Proof request and delivery lifecycle

Once a Market is created, Requesters can place Proof Requests for the corresponding circuit. Apps or clients would normally use the Kalypso SDK to place Requests. The SDK allows developers to configure the Market identifier, required response time guarantee and pricing strategy. The latter two fields can either be hardcoded, be dynamically set at runtime by programming some strategy or be left exposed to let end users to decide on the go.