-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
# Monetizing Lokinet: Integrating Payment, Per Order Token Burning, and Authorization into the Exit Marketplace #2191
Comments
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 In such a scenario, we can utilize the SENT<>Oxen bridge to collect fees directly from 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 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 |
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. |
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.
M
-addressWe propose implementing a new transaction address format starting with the prefix
M
, which denotes merchants. Unlike the standard address that begins withL
, allM
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 theM
-address in Base58, in addition to the existingPUBLIC_ADDRESS_BASE58_PREFIX
,PUBLIC_INTEGRATED_ADDRESS_BASE58_PREFIX
, andPUBLIC_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 aM
-address subtype: Instead of prependinghashkey.SUBADDRESS
to calculate the hash, we prepend a dedicated prefixhashkey.MERCHANT_ADDRESS
represents theM
address subtype, see https://www.getmonero.org/library/MoneroAddressesCheatsheet20201206.pdf for reference in the Monero case.advance_subscription
We further propose to introduce a new transaction type to the Oxen protocol,
advance_subscription
, supplementing the existingtxtype
options ofstandard
,state_change
,key_image_unlock
,stake
, andoxen_name_system
. The token burning requirement for aadvance_subscription
transaction will be significantly higher thanstandard
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.
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 amapping::merchant
record must be aM
address type, otherwise a miner will refuse to include this record when registered. Optionally, amapping::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.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 theadvance_subscription
transaction type. Here, thetxtype
is automatically determined by the user’s wallet based on the address subtype. This transaction generates an on-chain Oxentx_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 thetxtype
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.
To establish a connection with the VPN service provider, users must attach the previously generated Oxen
tx_hash
to their initial request.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.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.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 theget_tx_proof
command.The user sends the proof of payment back to the service provider, who uses the
check_tx_proof
command to verify the proof. Thecheck_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.Following a successful validation, the service provider issues a mid-term lokinet authentication token to the user, which remains valid until its expiration.
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:
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.
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.
The text was updated successfully, but these errors were encountered: