user guides overview - atticplaygroup/prex GitHub Wiki
Caution
Disclaimer: external tools have not been implemented and designs may change
Certain documentation for users remains incomplete. Specifically, user agent functionality and service discovery via index are currently unimplemented. There's a general understanding of their intended function, but not a finalized implementation. Currently here in Prex we only define an interface for these features[^1]. User agents, for instance, will engage with Prex by matching sell orders and claiming tokens. Similarly, service discovery will involve searching for services, ultimately using a service_global_id for identification within Prex.
This section outlines the design and application of each component within the Prex system. It explains how PAID services realize their advertised attributes of being permissionless, autonomous, incentivized, and decoupled. Specifically, it details
- how quota tokens ensure appropriate compensation for services and protection against misuse,
- how account registration both with and without initial deposits, and the account lifecycle,
- how admin account manage resource cleanup and maintain adequate resource supply,
- how service providers earn revenue and perform withdrawals,
- how order matching and peer Prex trading facilitate an efficient market for service tokens,
- how commonly used services interact to build diverse applications on top of a common infrastructure,
- and finally how Byzantine Faults can happen and their impacts.
| Table | Description |
|---|---|
| services | Active services that can be traded. |
| accounts | Active accounts haven't expired |
| active_orders | Active orders that are being sold. Limited orders posted by sellers come here for buyers to match. |
| fulfilled_orders | Settled orders that a buyer buys from sellers. They can be claimed to access tokens, or resold by placing a sell order. |
| deposits | Nullifiers for spent Sui transaction digests. |
| withdraws | |
| claimed_orders | History of claimed orders. For audit purpose only. |
It's helpful to analyze a specific use case of PAID services. Imagine an individual wanting to utilize several PAID services, like chatbots, email, and livestream viewing, for routine activities. The following steps detail the actions an individual Alice and her user agent would take:
(Refer to scripts/api-test.sh for a buyer-seller example.)
Human Deposit:
- (Alice) purchases $10 worth of Sui (or any payment method supported by the Prex system, ideally a stable currency or fiat) to serve as her monthly budget.
- (Alice) authorizes her user agent to spend from this budget, potentially bypassing the need for passwords or notifications for ease of use.
Daily Usage:
- (Alice) Opens a chatbot application.
- (user agent) queries PAID indexes it deems reliable to find providers of a chatbot service, as well as Prex exchanges that offer their access tokens.
- (user agent) purchases access tokens from the chosen Prex exchanges, selecting providers based on its criteria.
- (user agent) uses the purchased access token to access the desired service.
- (Alice) receives the service.
Each time the user agent interacts with a PAID service, such as the index mentioned earlier or the chatbot, it involves purchasing access tokens from a Prex exchange.
Token Procurement:
- (user agent) deposits $1 (sufficient for three days' usage across all applications) into a Prex instance it trusts. An account is automatically generated unless the agent opts to use an existing account.
- (user agent) purchases access tokens (specifically,
sold quota) for the selected Prex instance. - (user agent) retrieves the market price for the desired service. If the price is acceptable, it acquires a quantity of access tokens estimated to be sufficient for usage over the next few days.