Condense (off-chain) job request structure

[0xDegenDeveloper]

Currently

The processor expects this job request format:

curl -X POST "http://localhost:3000/pricing_data" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: API_KEY" \
  -d '{
    "identifiers": ["PITCHLAKE_V1"],
    "params": {
      "twap": [8888, 9999],
      "volatility": [6666, 9999], 
      "reserve_price": [6666, 9999]
    },
    "client_info": {
      "client_address": "0x018df581fe0ee497a4a3595cf62aea0bafa7ba1a54a7dcbafca37bfada67c718",
      "vault_address": "0x...",
      "timestamp": 9999
    }
  }'

In this structure, there is 1 typo and a few simplifications we can do.

Typo

The codebase is no longer calculating volatility, it calculates max_return instead; however, the job request still uses the volatility field name.

Simplifications

1. identifiers are used on-chain (by verifier and vaults) as a single felt ('PITCHLAKE_V1'). We could make this field just a string instead of an array of strings.

• We refer to this as program_id on our end. If we are going for matching names, I'm unsure which makes sense to use (identifiers || program_id)

2. client_info.client_address is no longer used at all on or off chain, we can omit this

3. client_info.timestamp: We have been setting this equal to the same value as the params upper bounds (9999) when we send the job request. This value gets ignored off chain, and is replaced by the actual timestamp when the request is sent on-chain. So since this timestamp is getting overwritten by "now" by the processor, we could just omit this from the off-chain request (still passing it on chain)

4. client_info: Since vault_address is the only field from the job_request.client_info that we actually need to send, we could just replace client_info: {...} with vault_address: ...

TLDR;

Go from this:

curl -X POST "http://localhost:3000/pricing_data" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: API_KEY" \
  -d '{
    "identifiers": ["PITCHLAKE_V1"],
    "params": {
      "twap": [8888, 9999],
      "volatility": [6666, 9999], 
      "reserve_price": [6666, 9999]
    },
    "client_info": {
      "client_address": "0x018df581fe0ee497a4a3595cf62aea0bafa7ba1a54a7dcbafca37bfada67c718",
      "vault_address": "0x...",
      "timestamp": 9999
    }
  }'

To this:

curl -X POST "http://localhost:3000/pricing_data" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: API_KEY" \
  -d '{
    "program_id": "PITCHLAKE_V1",
    "vault_address: "0x...",
    "params": {
      "twap": [8888, 9999],
      "max_return": [6666, 9999], 
      "reserve_price": [6666, 9999]
    },
  }'

Afterwards

If these changes are made we should update the Pitchlake structs from this:

/// Sent from Verifier -> Vault (serialized)
struct JobRequest {
    vault_address: ContractAddress,
    timestamp: u64,
    program_id: felt252,
}

/// Sent from Verifier -> Vault (serialized)
struct VerifierData {
    reserve_price_start_timestamp: u64,
    reserve_price_end_timestamp: u64,
    reserve_price: felt252,
    twap_start_timestamp: u64,
    twap_end_timestamp: u64,
    twap_result: felt252,
    max_return_start_timestamp: u64,
    max_return_end_timestamp: u64,
    max_return: felt252,
}

to this:

struct JobRequest {
    /// Set by processor when it receives the off-chain request
    timestamp: u64,
    /// From initial off-chain request
    vault_address: ContractAddress,
    program_id: felt252,
    /// From initial off-chain request (params)
    reserve_price_start_timestamp: u64,
    reserve_price_end_timestamp: u64,
    twap_start_timestamp: u64,
    twap_end_timestamp: u64,
    max_return_start_timestamp: u64,
    max_return_end_timestamp: u64,
}

struct JobResult {
    reserve_price: felt252,
    twap_result: felt252,
    max_return: felt252,
}

Related Issue

If this issue is to be implemented, this Pitchlake issue will need to be redone if finished already

[ametel01]

Addressed in #34

please @0xDegenDeveloper review and let me know if it address the issue correctly