# Monetizing Lokinet: Integrating Payment, Per Order Token Burning, and Authorization into the Exit Marketplace

[venezuela01]

Monetizing Lokinet: Integrating Payment, Per Order Token Burning, and Authorization into the Exit Marketplace

This proposal presents an alternative approach to the one detailed in the Lokinet Exit Marketplace Design blog post available at https://oxen.io/blog/lokinet-exit-marketplace-design.

While the above design opts for a "per vendor token burning" model, this proposal employs a "per order token burning" model, or a consumer-side token burning model.

The terminology used in this draft does not overlap with that in the aforementioned link, thus avoiding potential reader confusion. Please note that this proposal is in its early stages and is primarily intended for brainstorming.

The primary goal of this proposal is to provide a convenient method for VPN service providers to manage users and payments, and for users to connect easily to the VPN service immediately after payment. The incomplete goal of this proposal is to enforce token burning higher than standard transaction fee rate for a VPN service, we will introduce what we have and what is missing. A detailed breakdown follows, with identified tasks for further action marked as TODOs.

1. New Oxen Wallet Transaction Address Type: M-address

We propose implementing a new transaction address format starting with the prefix M, which denotes merchants. Unlike the standard address that begins with L, all M addresses would be categorized as a separate type that requires a higher transaction fee.

We propose to introduce a PUBLIC_MERCHANT_ADDRESS_BASE58_PREFIX to encode the M-address in Base58, in addition to the existing PUBLIC_ADDRESS_BASE58_PREFIX, PUBLIC_INTEGRATED_ADDRESS_BASE58_PREFIX, and PUBLIC_SUBADDRESS_BASE58_PREFIX for other address subtypes.

The current protocol uses the formula s_i = Hash_s(hashkey.SUBADDRESS | v_0 | i) + s_0 to calculate the private key of a subaddress. Similarly, we proposal the following way to calculate the private key of a M-address subtype: Instead of prepending hashkey.SUBADDRESS to calculate the hash, we prepend a dedicated prefix hashkey.MERCHANT_ADDRESS represents the M address subtype, see https://www.getmonero.org/library/MoneroAddressesCheatsheet20201206.pdf for reference in the Monero case.

2. New Transaction Type - advance_subscription

We further propose to introduce a new transaction type to the Oxen protocol, advance_subscription, supplementing the existing txtype options of standard, state_change, key_image_unlock, stake, and oxen_name_system. The token burning requirement for a advance_subscription transaction will be significantly higher than standard transactions, increasing from less than 1 Oxen per transaction on average to around 3 Oxen per transaction. Assuming the current market price of Oxen is about $0.1 USD and a VPN subscription order is $10 USD per month, 3 Oxen (or $0.3 USD) would account for roughly 3% of the order amount. This fee is comparable to that of Visa international payments and could scale well with the growth of the VPN market.

TODO: The actual fee and its economic impact still need to be researched.

3. New ONS Mapping Type - mapping::merchant

We then suggest the Oxen protocol to implement a new ONS mapping called mapping::merchant. This integrates both the Lokinet address of the VPN service provider and the Oxen wallet receiving address of the service provider. The Oxen address in a mapping::merchant record must be a M address type, otherwise a miner will refuse to include this record when registered. Optionally, a mapping::merchant record could even integrate a BTCPay payment URL to support additional payment methods, but the implementation details require further research. Another option is to integrate an URL to a per-merchant-dedicated Oxen <> wOxen bridge, so users can pay using wOxen, or potentially the new name SENT, to purchase for subscription services. In case of users decide to pay by wOxen/SENT, we can utilize the bridge to collect fees directly. We can also provide fee discount to users who pay in the legacy native Oxen coin directly, to encourage users to hold and use a more private coin.

4. Payment Process

Users make a payment by scanning a QR code or resolving an ONS name to obtain the Oxen wallet M address of the service provider. They then pay a specific amount required by the VPN service provider to the parsed address using the advance_subscription transaction type. Here, the txtype is automatically determined by the user’s wallet based on the address subtype. This transaction generates an on-chain Oxen tx_hash and incurs a fee that is burned, acting as a network commission. As stated earlier, the burning amount of this transaction (3 Oxen, for example) is higher than a standard Oxen transfer (less than 1 Oxen). An Oxen miner should check the txtype and ensure the burning fee is as expected before mining the transaction.

Note that a VPN service provider might have multiple SKU (Stock Keeping Unit), so they might want to present multiple QR code encoding different SKU id, and the SKU id will be further encoded in a user purchase transaction as extra data, the implementation details require further research.

5. Connection Establishment

To establish a connection with the VPN service provider, users must attach the previously generated Oxen tx_hash to their initial request.

6. Transaction Verification

The service provider verifies this connection request by cross-referencing the attached tx_hash with their Oxen wallet. This validation process checks the transaction's existence, amount, legitimacy, sku_id, and whether the corresponding subscription is still active. The expected order amount and expiration are defined by the terms of agreement set by the service provider, which are off-chain knowledge.

7. Nonce Issuance

Once the validation is complete, the service provider issues a random nonce as a challenge to the user. This is done to prevent others from picking up the tx_hash and posing as the original buyer, as well as to prevent replay attacks.

8. Payment Proof Generation

The user then generates a proof of payment using the get_tx_proof command on their Oxen wallet, signing the nonce by including it in the <message> parameter of the get_tx_proof command.

9. Proof Verification

The user sends the proof of payment back to the service provider, who uses the check_tx_proof command to verify the proof. The check_tx_proof command confirms that the proof is valid, the transaction is legitimate, and the message signed by the user matches the nonce that was issued.

10. Mid-term Authentication Token Issuance

Following a successful validation, the service provider issues a mid-term lokinet authentication token to the user, which remains valid until its expiration.

11. OTC Trading

Over-the-counter (OTC) trading between Lokinet VPN service providers and users is inevitable and not prohibited. When we provide VPN service providers and users with a suite of tools built on top of Lokinet and Oxen, our goal is to deliver convenience, not burden. By simulating a basic CRM (Customer Relationship Management) system, we facilitate a straightforward way to manage anonymous customers and authorize VPN access. This convenience provides marginal benefits to both VPN service providers and users, making the approximate 3 Oxen transaction fee worthwhile when compared to using different payment methods and self-built management systems. The marginal cost is also low enough to disincentivize service providers and users from modifying or rebuilding the tools to circumvent the token burning mechanism. Despite a transaction fee rate that may not seem high at first, our ambition is to secure a tiny fraction of the expansive $50 billion VPN industry in the long term. Moreover, if Lokinet becomes the standard in the VPN industry over the next decade, we might even reduce the fee to less than 3%, potentially to 1%, or even just to the standard transaction fee.

See also:

How to solve the most daunting challenge of the marketplace business model: platform leakage.

Outstanding issues that require further discussion include:

1. The actual cryptographic implementation of the Oxen address subtype and its implications for the privacy of users and service providers needs further research. However, if the business model is validated and continues to scale, we might gradually lower the transaction fee over time. Ultimately, we could revert to the standard transaction fee, which would eliminate the need for a different address subtype.

2. A reasonable fee pricing strategy, as well as how to adjust the fee, also requires further research. If not handled properly, catastrophic results could occur, such as the instance of a $130 USD transaction incurring a $26 million USD transaction fee. See also Marketplace pricing: How to define your ideal take rate

Finally, it's worth mentioning that the above proposal is not restricted to the VPN market. For instance, a video streaming service operating exclusively within Lokinet, without hosting on the clearnet, could potentially reuse the same system for user payment and access management.

A related topic on monetization, intended for a different purpose, is introduced in Oxen Monetization: Integration of Lokinet Marketplace Referral Program in Session.

[venezuela01]

Update:

If Session is going to implement a dual-stack SENT/OXEN token pair, it is highly likely that the majority of customers will pay using the SENT token from an EVM chain, while only a few will use the legacy OXEN token.

In such a scenario, we can utilize the SENT<>Oxen bridge to collect fees directly from SENT users while providing fee discounts for OXEN users. This strategy will encourage users to hold and use a more private coin in the long term without sacrificing too much short-term profit.

Consequently, 1. New Oxen Wallet Transaction Address Type: M-address, 2. New Transaction Type - advance_subscription, and 3. New ONS Mapping Type - mapping::merchant may no longer be necessary, or at least low priority. These features were initially designed to enforce a high transaction fee specifically for VPN subscriptions, but now we intend to give OXEN users a transaction fee discount for VPN subscriptions, which would probably align with the standard fee rate. Our profit will rely on fees collected from SENT users, which will be enforced by the bridge during payment.

On the other hand, the remaining parts of the proposal, including 4. New ONS Mapping Type - mapping::merchant, 5. Connection Establishment, 6. Transaction Verification, 7. Nonce Issuance, 8. Payment Proof Generation, 9. Proof Verification, and 10. Mid-term Authentication Token Issuance, are still relevant in the new SENT context. This is because SENT will be swapped to OXEN at the last minute to increase privacy, and the merchant can use the get_tx_proof approach to authorize users anonymously.

[venezuela01]

This proposal has been partially superseded by Enhancing the Awareness, Utility, and Anonymity Set of Oxen - Part 8 - Lokinet Monetization, which presents a more integrated experience with Session. Nonetheless, certain foundational ideas and building blocks from this proposal retain value and merit further exploration.