Accounts within Prex differ from traditional accounts. They are intended to be inexpensive and disposable. They are not, by default, linked to user interactions or substantial digital assets.

A new account is created within a Prex instance when the supplied identifier is not already in use. The user must first send a supported currency like Sui to a designated Prex wallet address, which can be identified by calling the ListPaymentMethods function. As stated in the introduction, Prex is designed to be adaptable to payment methods beyond the cryptocurrency provided in the reference implementation.

message PaymentMethod {
  string name = 1;
  PaymentCoin coin = 2;
  PaymentEnvironment environment = 3;
  string address = 4;
}

Each account has an expiration period, set by the ttl value in the DepositRequest message. Once this expiration is reached, the account will be deleted, even if it still holds funds. The expiration can be extended by depositing additional funds using the same username. The cost per second of the expiration is determined by the ACCOUNT_TTL_PRICE environment variable.

message SuiDepositProof {
  string chain_digest = 4;
  google.protobuf.Timestamp start_time = 5;
  bytes challenge = 6;
  string signature = 7;
}

message DepositRequest {
  string username = 1;
  string password = 2;
  google.protobuf.Duration ttl = 3;
  SuiDepositProof proof = 4;
}

In above message, chain_digest refers to the unique identifier of a transaction of user's Sui deposit. Prex will query blockchain nodes to locate finalized transactions with this identifier and identify the originator that sent funds to it.

To prove ownership of a deposit, Prex requires a personal message signature from the transaction originator's wallet. This message to sign is a challenge produced by the GetChallenge API, based on the current timestamp and the originator's Sui address.

message GetChallengeRequest {
  string address = 1;
}

To prevent double spending of the same deposit, Prex logs transaction identifiers from successful deposits as invalidation markers (a.k.a. nullifiers). To avoid an indefinite increase in the number of these markers, a transaction will expire after a time period defined by MESSAGE_AUTH_TIMEOUT from the start_time. After this timeout, these invalidation markers can be removed from the database using scheduled maintenance tasks.

See scripts/register-account.sh for an example usage.

Following registration, login is achieved through conventional username and password authentication. Upon successful login, a JWT is issued to authorize the account. Each session will automatically terminate after a duration defined by SESSION_TIMEOUT.

Support for OAuth 2.0 and other contemporary authentication methods might be integrated in the future. However, this is not the primary focus, as Prex accounts are designed to be simple and easily replaceable, with the exception of special accounts such as administrator account.

See scripts/login-account.sh for a usage example.

You can configure any desired username and password for a Prex instance. For ease of use and illustrative purposes, the prex client account command generates usernames and passwords based on mnemonic phrases with varying prefixes (referred to as passwords within the BIP39 key derivation function) to create account credentials for Prex. This approach facilitates automated management from a single, randomly generated mnemonic source.