Within Prex, items, primarily quota, are exchanged using limit order book. Each instance is claimed to implement a service by a service provider. To utilize quota, a sell order must be matched, an access token claimed, and then activated, as detailed in the quota lifecycle. The following outlines the processes of order matching and token claiming.

There are typically two scenarios for the submission of sales requests within Prex. The first involves service providers directly placing sell orders. The second involves general users reselling quota.

(TODO when implemented)

(TODO when implemented)

Purchase requests are matched in a limit-order format. Currently, Prex only permits sellers to submit sell orders, but buyers cannot submit orders and always match. This is designed to facilitate real-time responses, given that buyers are typically users seeking services to fulfill immediate needs.

message ClaimTokenRequest {
  string name = 1;
  int64 account_id = 2;
  // TODO: audience should not be a user given variable. Should be provider given
  string audience = 3;
  string arg_json = 4;
}

• name refers to the resource name for fulfilled orders.
• audience indicates the identifier of the target service given by user. This may switch a provider given one in the future.
• token policy is explained in the service section.

Ideally, a Prex operator does not need to be concerned with unsolicited service providers, as they are required to pay for each sales order they place. In the event of excessive spam, we could implement personalized pricing strategies to offer discounts to reputable service providers.