By examining the services table using the command

SELECT * FROM services;

Results similar to the following can be obtained:

 service_id |          service_global_id           |      display_name       | token_policy_config |           token_policy_type            
------------+--------------------------------------+-------------------------+---------------------+----------------------------------------
          1 | 00000000-0000-0000-0000-000000000000 | free quota service      | {"unit_price":1}    | exchange.prex.proto.ProductTokenPolicy
          2 | 00000000-0000-0000-0000-000000000001 | sold quota service      | {"unit_price":1}    | exchange.prex.proto.ProductTokenPolicy
          3 | b75e0c74-f08e-4690-8910-c70f9e43ba8c | i am an example service | {"unit_price":1}    | exchange.prex.proto.ProductTokenPolicy

The initial two services are integrated services used internally by Prex. The third service is an external example service.

token_policy specifies the rules governing how the access token can be requested. It is used when buyer requests an access token.

It provides buyers with the ability to request tokens in a customizable format. The format is not validated by Prex. They must ensure that the intended PAID service recognizes it when claiming.

For instance, assuming service 3 is a PAID storage service similar to Redis, the token can be requested as follows after purchasing it:

CLAIM_QUANITY=10
curl -s -H "Authorization: Bearer ${AUTH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "services/3/fulfilled-orders/5",
    "audience": "'"${PAYMENT_ADDRESS}"'",
    "arg_json": "'{\\\"storage_in_bytes\\\":1000,\\\"ttl\\\":86400}'",
    "account_id": '${ACCOUNT_ID}'
  }' \
  "http://localhost:3000/v1/services/3/fulfilled-orders/5:claim"

Here, ProductTokenPolity is an example of a token policy. This policy considers multiple factors and multiplies them, also multiplying by the unit_price defined in the service configuration, to determine the quantity to deduct.

For example, the user could purchase 1,000,000,000 units of Redis storage. Each unit could support 1 byte of PAID Redis storage with a 0.5-second TTL. To implement, we can set unit_price to 2.

"{\\\"storage_in_bytes\\\":1000,\\\"ttl\\\":86400}"

This JSON argument represents the client's request for the PAID server to store up to 1000 bytes for 1 day. The total quantity cost is unit_price * storage_in_bytes * ttl = 172,800,000.

This allows the user to make dynamic claims based on their usage. It aligns with the data model of serverless computation, offering a pay-as-you-go approach.

The service registration process is performed manually. This is because it is challenging to discern spam services from those that will generate substantial profits. Selection should primarily be driven by user demands and popularity.

(TODO: add a service registration user type to the privilege column, enabling them to manage services instead of requiring administrator intervention)

Prex operators may identify reputable services that are widely recognized by users for profit optimization. It is beyond the scope of Prex to store metadata such as service popularity, especially in real time. It may reference an index service for such information.

For observability, Prex will offer real-time information such as service prices and quantities in the future. Contributions are welcome.

A service_global_id is a unique identifier employed by user agents to locate services within a Prex environment. User agents consult a service index to discover relevant services and then verify their availability on trusted Prex instances using this ID.

To promote social benefit, Prex indexes are responsible for resolving potential conflicts, though a consensus mechanism is not part of the design. One potential approach involves utilizing a blockchain to maintain a list of service_global_ids, with users prioritizing the ID associated with the highest stake.

Indexes might also consolidate duplicate services with identical meanings or implement standardization practices, though this is outside the purview of Prex. Prex relies on the service_global_id for service identification, and the ultimate decision of which service to trust lies with the user agent.