0078 XLS-78d: Subscriptions

[xrpl365]

XLS-78d - Subscriptions

Title:        Subscriptions
Type:         Draft
Revision:     2
Last Update:  09/09/2024
Authors:      Chris Dangerfield @xrpl365
              Denis Angell @angell_denis

Updates

Updated: 09/09/2024

• Adjusted SubscriptionCreate transaction name to SubscriptionSet and added support for updating the Amount and new optional Expiration.
• Added support for optional Expiration to support fixed length subscriptions.
• SubscriptionCancel updated to support either Account or Destination being able to cancel.
• Updated a number of fields and naming conventions inline with rippled standards.

Abstract

This proposal introduces a subscription (re-occurring payments) mechanism to the XRP Ledger (XRPL), enabling functionality similar to direct debits, thus removing the need for users to sign a transaction for each payment. The account owner will define values that are used to protect against abuse.

Motivation and Rationale

Currently, payments on the XRP Ledger require the sender to initiate and sign each transaction. With the introduction of off-chain solutions like Xaman API, the concept of pull payments emerged, where a transaction can be generated by the destination address and signed by the sender. However, this method still requires the user to authorize each transaction individually, which is not practical for services requiring regular, recurring payments, ie: subscriptions.

This proposal addresses this limitation by introducing a subscription feature that allows for pre-authorized recurring payments, improving the user experience and enabling a broader range of services on the XRP Ledger.

The proposed subscription model is designed to balance user convenience with security. By allowing pre-authorized payments within defined parameters, the system reduces the need for frequent user interaction while maintaining control over the amounts and frequency of payments. This approach also allows businesses to automate billing processes, improving service delivery while ensuring that users retain oversight and control of their recurring payments. The subscription feature enhances the versatility of the XRP Ledger, making it more accommodating for services that rely on automated, regular payments.

This proposal will support both payments in XRP and issued assets.

Amendment

This feature enables account owners to authorize automated payments with predefined parameters such as amount, frequency, and destination, reducing the need for manual transaction signing each time.

The amendment adds the following:

• A new ledger entry: Subscription
• A new transaction type: SubscriptionSet
• A new transaction type: SubscriptionCancel
• A new transaction type: SubscriptionClaim

New Ledger Entry: Subscription

The Subscription ledger entry is a new on-ledger object that stores the details of the subscription, including the destination address, the maximum allowable amount, the frequency of the payments, and the start time of the subscription.

Fields:

Field	Type	Required	Description
sfAccount	AccountID	✔️	The account that owns the subscription.
sfDestination	AccountID	✔️	The account authorized to receive the subscription payments.
sfDestinationTag	Number		Support for subscription payment categorization by the Destination.
sfAmount	Amount	✔️	The subscription amount (max) that can be withdrawn during each time period.
sfFrequency	UInt64	✔️	The time period (in seconds) between consecutive payments (e.g., 2592000 for monthly).
sfNextPaymentTime	UInt32	✔️	The next time (Ripple epoch time) the payment can be claimed. This field is automatically updated after each successful payment.
sfExpiration	UInt32		The time (Ripple epoch time) of the last payment. Allows for optional fixed period subscriptions.

Example Subscription object:

{
  "LedgerEntryType": "Subscription",
  "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
  "Destination": "rLdCa1mLK5R5Am25ArfXFmqgNwjZgnfy91",
  "DestinationTag": 10, // Bob is customer number 10
  "Amount": "100000000", // 100 XRP
  "Frequency": 2592000, // 30 days in seconds
  "NextPaymentTime": 711232800, // (example epoch time for next payment)
  "Expiration": 721600800 // (example epoch time for final payment)
}

We compute the Subscription object ID, a.k.a., SubscriptionID as the SHA-512Half of the following values, concatenated in order:

• The Subscription space key (0x00??)
• The Account ID
• The Destination ID
• The Txn Sequence

New Transaction Type: SubscriptionSet

The SubscriptionSet transaction is used to create a new subscription. The account owner specifies the destination, amount, frequency, and optionally the start time.

Fields:

Field	Type	Required	Description
sfTransactionType	String	✔️	The type of transaction:SubscriptionSet.
sfAccount	AccountID	✔️	The account that is creating the subscription.
sfDestination	AccountID		The account authorized to receive the subscription payments.
sfDestinationTag	Number		A destination tag to be associated with the subscription payment.
sfAmount	Amount	✔️	The subscription amount (max) that can be withdrawn during each time period.
sfFrequency	UInt64		The time period (in seconds) between consecutive payments.
sfStartTime	UInt32		(Optional) The time (Ripple epoch time) when the subscription starts. If not set, it starts immediately.
sfExpiration	UInt32		(Optional) The time (Ripple epoch time) when the subscription ends.
sfSubscriptionID			(Optional) Used for updating a subscription.

Example SubscriptionSet Transaction (Create):

{
  "TransactionType": "SubscriptionSet",
  "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
  "Destination": "rLdCa1mLK5R5Am25ArfXFmqgNwjZgnfy91",
  "DestinationTag": 10, // Bob is customer number 10
  "Amount": "100000000", // 100 XRP
  "Frequency": 2592000, // 30 days in seconds
  "StartTime": 711232800, // (example epoch time for start time)
  "Expiration": 721600800 // (example epoch time for final payment)
}

Example SubscriptionSet Transaction (Update):

{
  "TransactionType": "SubscriptionSet",
  "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
  "Amount": "100000000", // 100 XRP
  "Expiration": 724192800, // (example epoch time for final payment increased by one frequency period)
  "SubscriptionID": "E8A6F9B99B041DF5C932DF8DA29B2A84B42D4D4F0F4A08931D76D62F42E1F1B9"
}

Failure Conditions (Create)

• Destination is the same as Account.
• Amount is invalid OR <= 0.
• Frequency <= SYSTEM_MINIMUM (global value defining the minimum frequency: eg 1 hour or 1 day).
• Subscription ledger entry exists.
• Account does not have a valid Trustline (Limit, Frozen, Auth, Rippling).
• StartTime is less than the current time.
• Expiration is less than the current time.
• Expiration is less than the StartTime.
• Expiration is less than the NextPaymentTime.

State Changes (Create)

• Creates the Subscription ledger entry, initializing all the fields.
• If the StartTime field is included then the NextPaymentTime is the StartTime.
• If the StartTime field is not included then the NextPaymentTime is the current ledger time.

Failure Conditions (Update)

• Subscription Entry Account is not the same as the txn Account.
• Amount is invalid OR <= 0.
• Subscription ledger entry does not exists.
• Account does not have a valid Trustline (Limit, Frozen, Auth, Rippling).
• Expiration is less than the current time.
• Expiration is less than the StartTime.
• Expiration is less than the NextPaymentTime.
• SubscriptionID submitted and Amount not present or optional Expiration not present.

State Changes (Update)

• Updates the Amount and Expiration.

New Transaction Type: SubscriptionCancel

The SubscriptionCancel transaction is used to cancel an existing subscription. The transaction must be signed by the account that created the subscription.

Fields:

Field	Type	Required	Description
sfTransactionType	String	✔️	The type of transaction:SubscriptionCancel.
sfAccount	AccountID	✔️	The account that created the subscription.
sfSubscriptionID	Hash256	✔️	The unique identifier of the subscription to be canceled.

Example SubscriptionCancel Transaction:

{
  "TransactionType": "SubscriptionCancel",
  "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
  "SubscriptionID": "E8A6F9B99B041DF5C932DF8DA29B2A84B42D4D4F0F4A08931D76D62F42E1F1B9"
}

Failure Conditions

• SubscriptionID does not exist.
• Account is not the owner of the Subscription OR the Destination on the Subscription.

State Changes

• Removes the Subscription ledger entry associated with the given SubscriptionID.

New Transaction Type: SubscriptionClaim

The SubscriptionClaim transaction is used by the destination (beneficiary) to pull the funds from the subscriber’s account according to the predefined rules.

Fields:

Field	Type	Required	Description
sfTransactionType	String	✔️	The type of transaction:SubscriptionClaim.
sfAccount	AccountID	✔️	The account authorized to receive the subscription payment.
sfSubscriptionID	Hash256	✔️	The unique identifier of the subscription being claimed.
sfAmount	Amount	✔️	The amount being pulled, which must be less than or equal to the authorized amount.

Example SubscriptionClaim Transaction with XRP:

{
  "TransactionType": "SubscriptionClaim",
  "Account": "rLdCa1mLK5R5Am25ArfXFmqgNwjZgnfy91",
  "SubscriptionID": "E8A6F9B99B041DF5C932DF8DA29B2A84B42D4D4F0F4A08931D76D62F42E1F1B9",
  "Amount": "100000000" // 100 XRP
}

Example SubscriptionClaim Transaction with issued asset:

{
  "TransactionType": "SubscriptionClaim",
  "Account": "rLdCa1mLK5R5Am25ArfXFmqgNwjZgnfy91",
  "SubscriptionID": "E8A6F9B99B041DF5C932DF8DA29B2A84B42D4D4F0F4A08931D76D62F42E1F1B9",
  "Amount": {
    "currency": "USD",
    "value": "20",
    "issuer": "rUSDIssuerWKDv6jmDy1pUykJzF3wq" // Example issuer
  }
}

Failure Conditions

• Subscription ledger entry does not exist for SubscriptionID.
• Account is not the destination (beneficiary) specified in the Subscription OR the destination of the Subscription.
• Amount is < 0.
• If Amount is IOU and IOU is a "bad" currency.
• Amount (type) does not equal Subscription Amount (type).
• Amount exceeds the authorized amount in the subscription.
• Account has insufficient funds
• Account does not have a valid Trustline (Limit, Frozen, Auth, Rippling)
• Destination does not have a valid Trustline (Limit, Frozen, Auth, Rippling) (Optional)
• Destination does not have enough XRP to cover creation of Trustline (Optional)
• Current time is before NextPaymentTime.

State Changes

• Deducts the specified Amount from the subscriber’s account.
• Updates NextPaymentTime in the Subscription ledger entry to the NextPaymentTime plus the Frequency.
• Credit the specified Amount to the destination account.
• Create Destination Trustline (Optional)
• Removes the Subscription ledger object where time > Expiration.

Zero Value Claims

In this proposal a zero value claim is not a failure condition; no value is transferred but the NextPaymentTime field is updated.

Transaction Fees & Reserves

It is assumed that all transactions related to subscriptions, including SubscriptionSet, SubscriptionCancel, and SubscriptionClaim, should incur standard transaction fees inline with regular payments.

The Subscription ledger entry will require an increase in the account's reserve by the standard amount applicable to other ledger objects on the XRP Ledger. This ensures that accounts cannot create an excessive number of subscriptions without maintaining sufficient reserves.

Key Points to Understand

• Transaction Claim: The NextPaymentTime updates upon success, meaning only one pull payment can be successfully claimed within the period.
• Time Management: The NextPaymentTime field in the Subscription ledger entry ensures that payments cannot be claimed more frequently than specified by the Frequency.
• Security: Since the subscription creation requires explicit user authorization, only an amount up-to the pre-approved value can be withdrawn.

Basic Flow Scenarios

User Onboarding

• The user signs up for a service.
• The service generates a subscription request with details like amount and frequency.
• The user reviews and signs the subscription, creating it on the XRPL.

Service Pulls Payment

• The service claims a payment immediately if the start date is set to "now" or after the specified start date has passed.
• Reoccurring payments are pulled as per the subscription details.

Payment Failure

• If a payment fails due to insufficient funds, the service notifies the user and retries after eg: 7 days.
• Upon successful retry, the payment process continues as normal.

Fee Increase

• The service increases its charge and notifies the user.
• The user is prompted to update the subscription amount with a SubscriptionSet transaction.

Cancellation

• The user can cancel the subscription at any time, effectively ending the service.
• Ideally, the user informs the service before cancelling, but this is not mandatory.
• The service can also cancel the subscription at anytime.

Backward Compatibility

The introduction of subscription transactions is backward-compatible as it does not alter existing transaction types or the current operation of the XRPL. Users who do not opt into the subscription system will experience no changes. Additionally, the subscription settings will be added as a new ledger object.

Conclusion

The proposed subscription feature introduces a much-needed capability to the XRPL, enabling automated recurring payments in a secure and user-friendly manner. By allowing users to pre-authorize transactions within defined parameters, the system reduces the friction associated with recurring payments, enabling a broader range of services to be supported on the XRP Ledger.

FAQ

A.1 What is the logic/decision making behind only allowing one pull payment?

The primary reason for limiting pull payments to one per subscription period is to simplify the implementation and management of the subscription system. Allowing multiple pull payments within a single period would require maintaining or checking a running balance of how much has already been pulled within that period. This adds significant complexity to the system, as it would need to track multiple transactions, ensure they don't exceed the authorized limit, and adjust the remaining balance accordingly after each pull.

By restricting it to a single transaction per period:

1. Prevention of Account Spamming: By limiting to one payment per period, the system prevents scenarios where a service might attempt to pull small amounts frequently (e.g., 1 XRP daily from a 30 XRP monthly limit). This would result in unnecessary transaction noise, potentially overwhelming the user's transaction history and creating confusion.
2. Simplified Implementation: The system avoids the need to continuously track and update the remaining balance within a subscription period.
3. Efficient Resource Management: While the primary focus is on simplifying implementation, restricting to one transaction per period also reduces the load on the XRPL. It avoids unnecessary multiple transactions that could otherwise increase processing requirements without providing additional value, ensuring smoother ledger operations. In scenarios where a service wanted to bill weekly rather than monthly, the subscription should just be setup with a frequency of weekly.
4. Practical Usage: In most cases the service would pull the max amount from the account each month; but there are good reasons why a service may wish to pull less than the max amount and as long as the service fully understands the limitation I see no reason to over-complicate the design.

A.2 Why can a payment be pulled that is less than the authorized amount?

The subscription model allows for flexibility in the amount that can be pulled during each payment cycle, provided it does not exceed the maximum authorized amount. This flexibility is important for several reasons:

1. Dynamic Billing Needs : Many services have varying costs depending on usage. For example, cloud services, utilities, or other pay-as-you-go models might generate different billing amounts each month. Allowing payments to be pulled for amounts less than the authorized maximum ensures that users are only charged for what they have used, without the need to authorize a different amount for each billing cycle.
2. Credit Adjustments : In scenarios where a user is given a credit (e.g., a refund, discount, or bonus), it is more efficient to apply this credit directly to reduce the amount pulled in the next subscription payment. This avoids the need to take the full authorized amount and then issue a separate credit back to the user. By pulling only the adjusted amount, the system simplifies the transaction process and reduces unnecessary operations, making the billing process smoother and more transparent.
3. User Convenience and Trust : Allowing for partial pulls under the maximum authorized amount enhances user trust by ensuring that they are only charged what is necessary. This avoids potential frustration or confusion that could arise from seeing multiple transactions (e.g., a full payment followed by a credit) on their account.

A.3 Can the Receiver pull multiple transactions within a period?

No, the receiver cannot pull multiple transactions within the same subscription period. The subscription model is designed to allow only one transaction per defined period (e.g., monthly, weekly) as specified in the SubscriptionSet transaction.

Once a payment is pulled, the system updates the NextPaymentTime field, ensuring that no additional payments can be claimed until the next period begins. This safeguard prevents the possibility of multiple deductions from the user's account within the same billing cycle, thereby protecting the user from unauthorized or excessive withdrawals.

This mechanism ensures that the subscription operates predictably, aligning with the user’s expectations for regular, recurring payments and preventing potential abuse by the beneficiary.

A.4 Can the user modify the subscription settings after it has been created?

Yes, we have updated the specification to allow for dual use of the SubscriptionSet transaction. The account owner will be able to update the amount and optional expiration time fields. To adjust the destination, dTag, frequency or start time, the account owner should cancel the subscription and create a new one.

A.5 What prevents a user from signing up for a 12-month subscription and then cancelling it prematurely?

There is nothing within the subscription mechanism itself that prevents a user from cancelling a subscription at any time, even if it was intended for a longer period, such as 12 months. This is similar to how traditional direct debits work in many financial systems, where users can cancel payments at any time.

To mitigate the risks associated with premature cancellation, service providers should enforce their terms of service to handle such situations. The XRP Ledger subscription model provides the technical foundation for recurring payments but does not enforce contractual obligations between the user and the service provider.

A.6 What happens if the user’s account cannot fulfil a subscription payment?

If the user’s account does not have sufficient funds to cover the subscription payment when a SubscriptionClaim transaction is submitted, the transaction will fail, and no funds will be transferred. The NextPaymentTime will remain unchanged, meaning the subscription will not reset until a successful payment is made.

In such cases, the service provider is in a similar position as they would be with a failed direct debit payment in traditional banking systems. They would need to rely on their own policies, such as retrying the payment at a later time or taking action based on the terms of service agreed upon with the user.

A.7 Can the subscription be paused temporarily?

Currently, the subscription model does not include a specific "pause" feature. However, there are two ways to effectively pause a subscription:

1. Cancel and Recreate : The user can cancel the subscription using a SubscriptionCancel transaction and later recreate it with a SubscriptionCreate transaction when they wish to resume payments. This method gives the user full control over their subscriptions but requires them to manage the timing manually.

2. Pause the Service with the Provider : The user can also pause the service directly with the provider, leaving the subscription in place. In this case, the provider has two options:

   1. Submit a 0-Value Claim : The provider can submit a SubscriptionClaim transaction with a 0-value amount, which would be considered valid and would update the NextPaymentTime without transferring any funds. This allows the subscription to remain active while effectively pausing payments.

   2. Partial Payment : The provider could agree to a partial payment for the period (e.g., pausing the service for two weeks and submitting a claim for 50% of the maximum value). This allows the provider to reduce the payment amount based on the paused duration while still maintaining the subscription’s timing and validity.

      These options provide flexibility while ensuring that the subscription mechanism can accommodate temporary service pauses without requiring users to fully cancel their subscriptions.

A.8 How is the subscription terminated?

A subscription can be terminated by the user at any time by submitting a SubscriptionCancel transaction. Once cancelled, no further payments can be claimed under that subscription, and the associated ledger entry will be removed. If the user wants to restart the subscription, a new SubscriptionCreate transaction must be submitted. This specification has been updated to also allow the destination (beneficiary) on the subscription to cancel the subscription too.

A.9 Can multiple subscriptions be created for the same beneficiary?

Yes, a user can create multiple subscriptions for the same destination, each with different parameters such as amount, frequency, and start time. Each subscription operates independently, allowing for flexible payment arrangements, such as different services or products billed separately by the same beneficiary.

A.10 What safeguards are in place to prevent unauthorized modifications to a subscription?

Subscriptions can be modified once they are created, but with very limited scope, only the amount and expiration time can be changed and this can only be claimed by the account owner.

SubscriptionSet must be signed by the account owner, ensuring that only the account owner or an authorized delegate can setup or modify a subscription, thereby preventing unauthorized changes.

A.11 What considerations have been given to this being used by a bad actor to create network spam?

Nothing would prevent an account owner from setting up hundreds of subscriptions, but this is true of any transaction that generates an account object and is mitigated by the cost of the object reserve.

A bad actor can only claim a subscription, if they are defined as the destination address on the subscription and a claim can only be submitted once during a period; as described above this prevents the potential for spamming of micro transactions within a period. The only other transaction a bad actor can submit would be a cancel but this can only be performed on a subscription to which they are the beneficiary and can only be performed once.

We do not consider this proposal to be open to any new form of spam, but remain open to further discussions should anyone have concerns.

[mvadari]

Isn't this usecase already solved by payment channels?

[xrpl365]

No, I don't believe it is, but happy to discuss and of course be-wrong.

[tequdev]

The main difference is that the sender only needs to set the maximum amount they are allowed to pay for a certain period of time and does not need to send additional transactions.

If we try to do this with Paychan, a very large trust is placed on the owner of the Channel's private key.

[xrpl365]

The main difference is that the sender only needs to set the maximum amount they are allowed to pay for a certain period of time and does not need to send additional transactions.

If we try to do this with Paychan, a very large trust is placed on the owner of the Channel's private key.

When i do a direct debit with my bank i don't need to have 12 months payments in my bank and certainly don't have to lock the value up.

[tequdev]

Cool suggestion!

I prefer the sfAmount in SubscriptionCreate transaction type and Subscription ledger entry to be sfSendMax. It can be understood in the same way as the current Payment transaction.

[KhaledElawadi]

Just got this ping and must say that both the idea of Direct Debit payments and the mechanism proposed is ideal for the development of other similiar related projects of which I have a few.

Will give this a good read to see what else might be useful.

Nice proposal of an essential requirement and at the protocol level too. 👏

[mvadari]

If feels very un-Web3 to me to allow someone to draw money directly from my account for a payment without me directly authorizing that interaction. I prefer the model of Checks, which are still signed by the original account, but theoretically could be issued for multiple months. This would require a minor modification to checks to allow them to be invalid before a certain time (like escrows), but I think that'd be a simpler way to go about it.

[timhoff]

It appears that I was mistaken, mvadari. The proposal does indicate that the recipient would "pull" payments. Perhaps instead of just pushing the payments in a recurring manner, the manual pull option was chosen due to the lack of Hooks on the main net. I'm a bit confused on this.

[xrpl365]

If a scheduled push payment was possible then yes, this would be automated payments and even better, but that cant be done, cus there is no ability to trigger transactions based on time events. No idea how hooks got into this conversation.

[KhaledElawadi]

Agreed, scheduled push payments would be the best way to do it and are the best way to do it and I've heard David talking about doing it too.

It's actually the basis of another proposal that I have had ever since I heard him say it live in a space.

[timhoff]

No idea how hooks got into this conversation.

Because you say that a scheduled push payment isn't currently possible. A hook could potentially facilitate that function. Alas, though...

[xrpl365]

No idea how hooks got into this conversation.

Because you say that a scheduled push payment isn't currently possible. A hook could potentially facilitate that function. Alas, though...

that was Denis that said this and he was using it in the context of a layer 2 solution.
hooks wouldn't help, they would just totally change how we implemented it, in fact we wouldn't even need this amendment if we had hooks.

[mworks-proj]

We believe this amendment is not only necessary but also transformative. It will enable SaaS platforms to utilize Web3 and XRPL for payments, offering a seamless alternative to the current model that often forces users to purchase NFTs or tokens. This feature will integrate XRPL directly into the use case, providing a more efficient and user-friendly solution for businesses and consumers alike. We are eager to help build a template to showcase this amendment and welcome any opportunities for collaboration.

…

On Fri, Aug 30, 2024 at 8:39 AM Chris Dangerfield ***@***.***> wrote: Ok, so can I get something straight in my mind. Is this an automated payment that is made from the user's account by the user or is this an authorisation that's granted to the receiver to apply for/collect X amount of funds on a certain day? The later — Reply to this email directly, view it on GitHub <#222 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASVZGDSHJXFTWMP24AEMEATZUCGZ3AVCNFSM6AAAAABNMRO2MSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANJQGA3TCNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[nrhrhysd616]

Please forgive my poor English.

In order to create a subscription, I would like to at least verify that the domain exists in the recipient account.
If a user has multiple subscriptions, this is the basis for identifying which subscription it is. Additionally, external services (such as Xaman) can verify that a subscription can be trusted when it is created.

[xrpl365]

Good point, it would definitely be a best practice to review not just the domain exists but the terms and conditions as well.

However, this is not something that affects the core, it is more something we would hope wallet providers would support.

[mvadari]

Fee Increase

• The service increases its fee and notifies the user.
• The user is prompted to cancel the current subscription and authorize a new one with the updated fee.
• To streamline this, the service could use the BATCH amendment to handle cancellation and creation in a single transaction.

Why not allow users to change the amount on the subscription instead of needing them to cancel and recreate the subscription? You could refactor SubscriptionCreate to be SubscriptionSet so you can do both with one transaction. I think there's a potential exploit opportunity otherwise, because it'd be easy to forget to set a StartTime on the recreation, at which point the service can effectively charge you twice in one month even though they just had a price increase.

[xrpl365]

Fee Increase

• The service increases its fee and notifies the user.

• The user is prompted to cancel the current subscription and authorize a new one with the updated fee.

• To streamline this, the service could use the BATCH amendment to handle cancellation and creation in a single transaction.

Why not allow users to change the amount on the subscription instead of needing them to cancel and recreate the subscription? You could refactor SubscriptionCreate to be SubscriptionSet so you can do both with one transaction. I think there's a potential exploit opportunity otherwise, because it'd be easy to forget to set a StartTime on the recreation, at which point the service can effectively charge you twice in one month even though they just had a price increase.

Yes I agree and in fact Denis and I realised this about 15 mins after posting and we already agreed that we will update the spec. But it's a really good catch and you'd only have caught it if you spent proper time considering the proposal, so for that I'm grateful.

[timhoff]

Great idea and amendment proposal, Chris and Denis. Although I'm struggling with the term, "Subscription;" which implies receiving something. I wonder if AutomaticPayment might be better?

[xrpl365]

I don't like automatic payment simply because it's not automatic, it still needs to be initiated.
It could more accurately be described as reoccurring payments, pull-payments, pre-authorised payments.
At this stage, if the name is the biggest issue you have, I'll take that happily 🤪

[timhoff]

Fair points, Chris. RecurringPayment, it is. 🤪

Upon reading the proposal again, I think that I'm more confused now than before.

Stated in the conclusion paragraph:

"enabling automated recurring payments in a secure and user-friendly manner."

This implies that the payments would be sent automatically when the NextPaymentTime is reached.

Yet, stated in the SubscriptionExecute section:

"The SubscriptionExecute transaction is used by the recipient to pull the funds from the subscriber’s account according to the predefined rules."

This sounds like the recipient needs to perform an action to "pull" the payments.

I'm seeing in the comments that others are confused whether these are pull (recipient initiated) or automated recurring payments, as well. Perhaps they are pull because of the lack of Hooks on the main net?

Lastly, it's unclear how the subscription ends, besides for the manual SubscriptionCancel transaction. Perhaps adding an endTime, or numPayments field to the Subscription object would help the system automatically cancel the subscription after the final payment has been made. Or, if no endTime or numPayments are provided, continue payments indefinitely, until manually cancelled.

[xrpl365]

Hi Tim,
I will review the wording to ensure any confusion with the word automatic is removed.
To be clear this proposal is modelled on Direct Debits which is a very common thing in the UK.
The customer authorises the service to debit their account.
The service pulls the payment from the customer account.
There are rules around it, just like in this system.
It works exceptionally well and things like cheques in the UK are all but obsolete now.

So this proposal is a pre-authorised pull payment.
The payment does not occur automatically, that is actually not possible with the XRPL, there is no mechanism to fire a transaction automatically, every tx on the xrpl has to be explicitly called, so this works no different and I see absolutely nothing wrong with this amd let me elaborate why with a practical explanation.

lets say I am the running the service.
i have 100 customers.
in my backend i know who they are, i know the subscriptionID onledger.
it isn't difficult for me to have an entirely automated payment collection system.
my backend knows then the payment is due, that's easy.
when its due i take the payment and then i deal with the response from the ledger which is either:
success - not much to do just update my records.
failure - how i do it is up to me but i will likely inform my customer and give them another chance. I will retry the payment in say 3 days and again in 7 days - and if get get a success i will update my records, else I am going to deal with the customer like i would in any normal web 2 payment workflow, which is probably terminate their service.

i could provide numerous examples of different scenarios but in my view the spec offer great flexibility and i have a couple of tweaks to make to further enhance it.

Thanks for sharing your interpretation of the wording and i will get this reviewed and updated to ensure no-one else reaches this same conclusion.

[timhoff]

Hi Chris,

I appreciate the detailed response, and understand. The difference between our perspectives, I suppose, comes from the difference between how automated payments are performed in the UK and US. Here, we can setup payments through our banks, which are either recurring or automatic, via services like Bank of America's BillPay. Instead of authorizing direct debits, payments can be scheduled. I guess in practice, this "push" approach is not so different than "pull," but it seems better to me to have the sender initiate the transaction, rather than the recipient, as it could potentially lead to higher costs for the recipient to create and maintain the required software. Concerning how the subscription ends, attached is a screenshot of my bank's BillPay setup for scheduled payments. The options for the duration are: 1. Until I stop these automatic payments. 2. Until a specified number of payments are sent (numPayments, lastAmount - if different). And 3. Until, but not after (endDate, lastAmount - if different). Perhaps these options might give you some ideas. I realize that having a transaction automatically initiated on the XRPL isn't currently possible; which is why I mentioned that a Hook could have overcame that limitation; alas. But I admit that I'm not exactly sure of what can be natively built-in to rippled. So the point might be moot. Now my mind is drifting to Axelar and EVM smart contracts.... Cheers

[tequdev]

The SubscriptionID is generated from the following elements, but the last Sequence makes it difficult to obtain a specific Subscription. By using an ID field that can identify, for example, a Plan, it is easy to see if a user is subscribed to a Subscription for a certain Plan.

Using the Sequence field could also lead to multiple subscriptions to the same plan.

• The Subscription space key (0x00??)
• The Account ID
• The Recipient ID
• The Txn Sequence

[dangell7]

Is there any scenario where one user/account would have multiple plans or multiple of the same plan?

[tequdev]

It depends on the subscription provider.
If we assume that there is only one subscription between the two accounts, then there is no need to include TxnSeq as a part of the ID.

[dangell7]

Well if there is a possibility of many, then it needs to handle many... We are assuming that there is a possibility of many.

[tequdev]

My point here is that when using TxnSeq, it is difficult to check whether one account holds a subscription to another.

By tying Plan A as Plan A = ID:1 when there are several plans and using ID instead of TxnSeq, you can search for a Subscription object from the elements Alice AccountID, Bob, AccountID, SubscriptionID(1).

Never mind what I said about the number of plans.

[dangell7]

I offered google as an initial example. With google I am billed 3 different subscriptions. Google Workspace: Gmail, Calendar, Etc. Google Voice, and a Google Hosting. Each of these has a nested plan type.

So the recipient is the same for all three, if we use a plan field then that field might need to be able to handle layers. VOICE_STANDARD or WORKSPACE_BUSINESS.

If its a VLBlob then we should just think about using sfData as the field and make it arbitrary. Though I dont really see the value in the keylet including the plan.

You can query the account_objects by recipient and then if there are multiple you can in your app filter by the sfData.

Thoughts?

[JTXRP]

Hi @xrpl365

I tried to read everything very Carefully but here are my thoughts overall. I hope I absorbed it. I am not a developer but I hope my comments are valuable.

Details around value tied to the subscription/Refunds for value not given:

You answered this to a degree, but should the value given to the subscriber be tokenized in some way? Even if just required in the memo field of the transaction and named (EX. Chris Community Platinum Level) This would essentially tokenize and provide some account of the value the subscriber was promised.

Management of Subscriptions:

We live out life on subscriptions it seems, should we start with a better way to manage multiple subscriptions as part of the amendment?
To me as a user, I would like to see a trustline in my account representing all the subscriptions that are active. This way if I get rid of the trustline to remove the subscription.

Is there any scenario where multiple subscriptions could hit and cause issues? If there was backup or batching for example?

How does the value creator generate a list of subscribers for marketing or gain an understanding of how many active subscribers they have?

This Brings me to my next topic.

Subscription X Month Minimums.

As a creator, I want the option to lock in and incentivize 2,3, or even 6-month minimum so someone will spend the time to understand the value of something I have created. How would this be handled? In my mind to accept the transaction it would be a one time payment or hold in escrow the amount. I understand this severely complicates things but I am sure someone may want the the option.

Security and Time.
I am not sure how time is handled on the XRPL but is there any concern about vulnerabilities around time and subscriptions rapidly being taken if the ledgers understand of time was not synced for some reason?

Lending

I know this is just for subscriptions but it seems like half the solution for lending as well. At the risk of adding to the scope, could there be some additional functionality added that would allow the lending of money or would that require smart contracts?

[dangell7]

1. Yeah a "plan" field might be a good idea. Or we could use the existing sfData field and allow an arbitrary amount of data to be stored with the subscription. Memos would work just fine here too.

2. A trustline represents a bi-directional obligation. You technically are under no obligation for the subscription. It's cancel anytime.

• The SAAS provider will determine what kind of IOU they want to accept. So if you have 4 subscriptions that use USD then you can remove that trustline and then those subscriptions would end up getting cancelled when they failed to claim the funds from your account.
• Any wallet/website can list the subscriptions by querying the account_objects and filtering by subscriptions.

3. If you want to lock your user into a subscription the you should be using PaymentChannels.

4. There is a much bigger issue if the XRPL isn't making forward progress. Every single transactor using RippleTime would fail in exactly the same way. Not an issue we are solving here today.

5. Lending is covered by another XLS. I would recommend you read up on those proposals. I'm not exactly sure how you could or would use the proposals in combination but I'm sure there are use cases out there. Nothing of the sort would be added to this amendment though.

[KhaledElawadi]

So far you have talked about regular subscriptions but that is not the same as Direct Debit.

Can this proposal authorise the varying amounts requested by utility companies on an ongoing basis where there is no set amount each time?

[xrpl365]

So far you have talked about regular subscriptions but that is not the same as Direct Debit.

Can this proposal authorise the varying amounts requested by utility companies on an ongoing basis where there is no set amount each time?

Yes.
the user sets a max amount and a time period.
the service pulls any amount <= to the max amount, only once within the period.
So in your example the utility company can bill me $50 one month and $60 another month, assuming I have authorised a maxAmount high enough. With a small tweak I am going to make the maxAmount can be easily adjusted meaning no change to the rolling period but the system can then account for fluctuations in either service charge OR user usage OR any other scenario.

[xrpl365]

3. If you want to lock your user into a subscription the you should be using PaymentChannels.
   PayChannels are not a solution to this.
   If you want to avoid the users have to sign a tx every month they have to fund the channel which means having all that money then tied up. It ifs tied up, then the user is better off just making a one-off payment for say 12 months as getting a discount, which is common practice.

[Cadey]

I like this proposal, a dedicated methof agreeing that party B can pull an agreed amount from party A once per period has a lot of comercial value to the ledger.

[interc0der]

I like the proposal and I have been asking for a formal subscription service for some time now.
With that said, I am going to provide a little push back with thoughts that have not already been discussed:

1. With many proposals, including this one, it feels like there is a philosophical divergence from the original ethos of the XRP Ledger. That is - not all logic needs to live on-chain. With this proposal, are we crossing that line? Rather than an amendment, why not a company, or groups of companies, come together and offer a subscription-as-a-service?

2. New Types incur serious technical debt across all projects building on the XRP Ledger. All projects (libraries, explorers, wallets, dapps, etc.) would be asked to update implementation in order to support these new transaction models. If it brings new capabilities that cannot be achieved by other means, then it is worth the investment.

3. Have we exploring how this solution compares to PaymentChannel? It seems to me that a majority of the features within this proposal can be accomplished through payment channels. Am I wrong? I am not claiming to be an expert with PaymentChannels and I do know that people have struggled with them in the past. We should document a comprehensive comparison between both.

@dangell7 You mention ’’If you want to lock your user into a subscription then you should be using PaymentChannels.“ - Ref. What exactly do you mean by this?

[dangell7]

1. I'm not sure I understand how another company can pull funds from your account while you still retain 100% control through another mechanism? The only thing I can think of is an L2 or XpopBridge using hooks on the other side but this still sounds like you have to pay them upfront, which subscription avoids.

2. Very true, although we see this with any amendment and I'm not sure this needs to be stated. I'm sure spending time on XChainBridge only to have it deprecated wasn't fun so I do understand. I spent time on the Ledger Integration for it...

3. Yeah, the main difference between a subscription and a payment channel, outside of the fact that payment channels don't use IOU's, is that the funds are not locked in a subscription. aka the funds are not removed from your account until the recipient makes the execute call to remove them each time period.

Payment channels could be used but it wouldn't be as efficient. If I sign up for figma today, I pay every month, 15.99. With subscriptions they take that out each month. With PaymentChannels, I would need to create the payment channel for a total that I deemed. Maybe 12 months * 15.99 then I would also need to sign an authorization for them to pull 15.99 and hope and pray that they only pulled that amount 1 time per month. Thats a whole lot of trust on a trustless network. If I wanted to extend that period I would have to call a new fund transaction. Thats really not how subscriptions work in the real world...

Another example is rent and leasing. I can have a month to month agreement where they pull 1,200 out of my account each month but I don't need 12 * 1200 to be locked up and if something goes wrong I know that they cannot just claim the remaining balance before I cancel.

[interc0der]

Okay thanks for the response and the provided examples.

It seems that PaymentChannel cannot truly work for a traditional subscription service because you have to lock the funds in the channel ahead of time, relying on a great deal of trust between both parties. I need to remember, PaymentChannel was implemented specifically for micro-payments, which, while close to traditional subscriptions, departs great deal and almost breaks all conventional subscription standards.

Whereas here, you remain in control of the funds until they are pulled from your account and can cancel the agreement at anytime.

[rothexD]

does that mean an sfRecipient can pull from the wallet until its fully empty? if so, is there a need to have a minimum reserve or something similar.

[xrpl365]

does that mean an sfRecipient can pull from the wallet until its fully empty? if so, is there a need to have a minimum reserve or something similar.

Yes but the normal rules of account reserves would apply, so on the basis that the transaction would take the account into the reserves this would not complete. However this does raise an interesting question how we that.

Could do a form of partial payment or reject entirely. We will consider this.

[Tapanito]

On SubscriptionExecute transaction state changes:

Updates NextPaymentTime in the Subscription ledger entry to the NextPaymentTime plus the Frequency.

This suggests that if I do not draw on the subscription for more than one period, I will be able to execute the Execute transaction more than once, back to back?

What is the motivation for not introducing a Subscription expiration date or a total limit on the funds that can be drawn?

[xrpl365]

On SubscriptionExecute transaction state changes:

Updates NextPaymentTime in the Subscription ledger entry to the NextPaymentTime plus the Frequency.

This suggests that if I do not draw on the subscription for more than one period, I will be able to execute the Execute transaction more than once, back to back?

What is the motivation for not introducing a Subscription expiration date or a total limit on the funds that can be drawn?

Yes, you are correct.
In theory a vendor could miss the payment window without penalty and claim multiple back to back, unless we prevent this of course which we could do by using next payment date and frequency to obtain an expiration date, but I'm not sure we should be doing that.

They may do this deliberately, maybe they don't bill for a month, but they would then submit a zero value claim which is valid as that pushes on the next payment period.

An expiry date is a possibility, it would be lightweight and certainly optional but we left it out of the spec for now.

[AdriaCarrera]

Great spec @xrpl365 and @dangell7 .
Because ledger close times are not completely accurate, could a SubscriptionExecute be invalid for some validators and valid for others?
I would suggest changing the sfFrequency and sfStartTime measure unit from seconds to amount of ledgers in order to avoid it.

[dangell7]

All nodes use the same ledger time. Ledger time is also used in other amendments. I see no issue with using ledger time.

[david-esq]

Hi @xrpl365,

Great specs! Thank you for your work.
To protect the end user, we should consider making the subscription expire.
In the non-crypto world, we rely on the expiration date of credit cards (A credit card expires in the next 4 years).
We can replicate the behavior with a maximum of occurrences for a subscription (how many times can the SubscriptionExecute transaction be submitted).

Example
If a monthly subscription is caped to 12, then you subscribe for a year and must renew at the end.

In terms of implementations, it would require adding an int sfMaxOccurrences field to the Subscription object and a param to the SubscriptionCreate.

[xrpl365]

I accept your observations and indeed you are not the only person to make this point.
Not to re-iterate the point, but I think we can add an expiry and as long as it is optional I believe it would enhance the feature and add very little overhead, so I will certainly discuss with @dangell7 when we consider a revision to this proposal.

[shortthefomo]

I'm a fan of the idea.

There is one question I have though that may make it even more useful. Crypto Conditions much like that which live on an Escrow. If one adds that as a possibility to claim on SubscriptionExecute. This can allow for an automated claim framework to be build by the business executing these, instead of executing these against possibly multiple accounts.

my 2 cents, thank you for your time on this @xrpl365

[xrpl365]

I'm a fan of the idea.

There is one question I have though that may make it even more useful. Crypto Conditions much like that which live on an Escrow. If one adds that as a possibility to claim on SubscriptionExecute. This can allow for an automated claim framework to be build by the business executing these, instead of executing these against possibly multiple accounts.

my 2 cents, thank you for your time on this @xrpl365

Let's discuss this in more detail off-line and then we can bring back any findings to this thread.
I am intrigued.

[Panosmek]

I am in favor of this proposal and I think it's a very needed feature that should already been done years ago. We need to bring Web2 features, that most internet users take for granted - such as subscriptions, into XRPL.

Beyond the core subscription functionality, I believe this feature can be extended to support additional use cases, such as buying something with monthly payments or "Pay Now, Buy Later" options for merchants that accepts XRPL payments. This would provide users with more flexibility and convenience when making purchases.

However, it's important to carefully consider the implications of allowing users to cancel subscriptions at any time. While this flexibility can be beneficial in certain scenarios, it may also lead to issues, especially in real-world scenarios. For example, if a user cancels a recurring monthly payment for a product they have bought and agreed to pay monthly payments (interest could also be added in the mix if we want to make it more advanced), it could disrupt the provider's business model and potentially lead to financial losses.

To mitigate this risk, it might be necessary to implement a feature that prevents users from unilaterally canceling subscriptions under certain circumstances. This could include cases where the user has already received the full value of the product or service, or where the provider has incurred significant costs in fulfilling the subscription.

It might also be good to explore options like:

Grace periods: Allowing users to cancel subscriptions with a certain amount of advance notice.
Partial refunds: Providing partial refunds for subscriptions cancelled before the end of the subscription period.
Pro-rated billing: Charging users based on the actual time they used the service.

By carefully considering these factors, we can ensure that the subscription feature is both user-friendly and sustainable for businesses using the XRP Ledger.

[xrpl365]

Hi Panos.
First thanks for your consideration of the feature; having reviewed your comments I do agree with your points however, it is my view these types of things are not the responsibility of the protocol. If a business and a consumer enter into an agreement this should be governed by law (t&c's) as it is now in web 2, I do not think building a whole bunch of condition based functionality is necessarily the way to go. Off-chain / layer 2 solutions to your points are in my view the best solution, as it keeps the protocol change light, keeping things ultra flexible; then the business can add any logic they want on-top of the protocol.
I will discuss with @dangell7 but thank you for taking the time to add your input.

[dangell7]

A user MUST be able to cancel their subscription at any time.

https://www.ftc.gov/news-events/news/press-releases/2024/06/ftc-takes-action-against-adobe-executives-hiding-fees-preventing-consumers-easily-cancelling

[Panosmek]

@dangell7 , yes I agree for subscriptions, but in my examples I'm not talking about subscriptions. For example, let's say you buy a phone and you want to buy it with monthly payments, you have gotten the phone so, at least here in Greece, you connect it with your bank account and it automatically takes money every month no matter what because you have already gotten the device so you should pay for it and you can't cancel it.

[dangell7]

Understandable, you would want to use PayChannels with IOUs if you want to "lock" the funds. Hopefully we can get that amendment reviewed soon.

[david-esq]

@dangell7 , yes I agree for subscriptions, but in my examples I'm not talking about subscriptions. For example, let's say you buy a phone and you want to buy it with monthly payments, you have gotten the phone so, at least here in Greece, you connect it with your bank account and it automatically takes money every month no matter what because you have already gotten the device so you should pay for it and you can't cancel it.

Subscriptions and multiple installments payments are two different concepts and may not be treated with the same features. A multiple installment payments is binding and should be honored even if the payer decides to run away, contrary to an sub where the customer should be free to leave at any time, under the contract conditions.

[ralphsa]

There needs to be care taken in the design between the actual transaction i.e. debiting the account / initiating a payment and the contract that stipulates the conditions. As mentioned by @Panosmek there are a lot of edge cases where refunds etc. might occur, in most payment systems these would be separate transactions and any adjustments handled by the system that manages the subscription record.

To provide some context, in most direct debit schemes, there is a system which manages the mandate setup, drives billing etc. When setting up there is a mandate request which is lodged against the recipients account (they have to agree to this lodgement) and then there are separate transactions for each direct debit. There is also a legal framework for these types of transactions covering items such as indemnity (regardless of whether this is a card transaction or direct debit), communication of the intent to take payment (i.e. normally this has to be communicated x days before taking the payment) - this is probably beyond the scope of this and I would recommend only focussing on the actual transactions not the subscription management or other workflows in any proposal.

In the example of existing systems and direct debits, the mandate can normally be deleted from the account by the account holder, this will cause the next collection to fail. This would require a resubmission of the lodgement of the direct debit mandate before the next collection can occur.

[xrpl365]

This proposal is kind of mirrored on the UK direct debit system.
However, certain elements are not possible, for example the guarantee that exists with the UK system and underwritten by the scheme. So to protect users, this is why we have a maximum limit, essentially meaning the protocol provides the user protection, not the bank.

As regards edge-cases, I do not consider it the job of the protocol to account for things like refunds or partial claims, the protocol provides the flexibility for the business to implement these things as they see fit and ultimately it is down to the business and their customer to understand the terms of their agreement.

I appreciate you taking the time to offer your perspective.

[ralphsa]

Agreed, a lot of the existing schemes have a lot of 'non protocol' level features / implementations that are implemented through legal frameworks. So fully agree on keeping the protocol lightweight and allowing the users to agree the additional scope outside of this.

[DavidRutledge037]

This looks great! Nice work Chris and Denis.

[xurgedigital]

After reviewing the XLS-78d proposal and community discussions, we find this feature would be beneficial for automating recurring payments within the TextRP unified messaging platform.

Benefits:

• Automation: This feature would effectively streamline recurring premium service payments without requiring user interaction for each transaction.
• Flexibility: The ability to set maximum payment amounts and frequencies, along with the potential for future updates to adjust subscriptions, is crucial for adapting to various service models.
• User Control: We appreciate the built-in controls, such as setting maximum limits and the option to cancel subscriptions at any time, which helps maintain user trust.

Risks and Considerations:

• Complexity and Implementation: As noted, introducing new transaction types can add complexity and potential technical debt to the system. Carefully managing the development and integration of these features would mitigate unnecessary complications.
• User Trust: The potential for misunderstanding pull-based transactions in a Web3 environment underscores the need for clear communication with our users to ensure they feel secure in authorizing recurring payments.
• Subscription Lifecycle Management: We recommend considering an optional expiration date or maximum number of occurrences for subscriptions to prevent indefinite payments, which could help manage both user expectations and business operations.
• Cancellation Risks: The concern regarding users canceling subscriptions after receiving full value from a service could be addressed by implementing optional features like a minimum commitment period, or grace periods for cancellations. These mechanisms could protect businesses while still offering users flexibility and control, though don't necessarily have to be part of the transaction, and some of this functionality can be handled by the software.

TextRP supports adopting this amendment, recognizing its potential to enhance our operations by providing a more efficient and user-friendly solution for recurring payments. We are eager to see how this feature evolves and look forward to contributing to its development and/or implementation.

[rothexD]

After reviewing the XLS-78d proposal and community discussions, we find this feature would be beneficial for automating recurring payments within the TextRP unified messaging platform.

Benefits:

• Automation: This feature would effectively streamline recurring premium service payments without requiring user interaction for each transaction.

• Flexibility: The ability to set maximum payment amounts and frequencies, along with the potential for future updates to adjust subscriptions, is crucial for adapting to various service models.

• User Control: We appreciate the built-in controls, such as setting maximum limits and the option to cancel subscriptions at any time, which helps maintain user trust.

Risks and Considerations:

• Complexity and Implementation: As noted, introducing new transaction types can add complexity and potential technical debt to the system. Carefully managing the development and integration of these features would mitigate unnecessary complications.

• User Trust: The potential for misunderstanding pull-based transactions in a Web3 environment underscores the need for clear communication with our users to ensure they feel secure in authorizing recurring payments.

• Subscription Lifecycle Management: We recommend considering an optional expiration date or maximum number of occurrences for subscriptions to prevent indefinite payments, which could help manage both user expectations and business operations.

• Cancellation Risks: The concern regarding users canceling subscriptions after receiving full value from a service could be addressed by implementing optional features like a minimum commitment period, or grace periods for cancellations. These mechanisms could protect businesses while still offering users flexibility and control, though don't necessarily have to be part of the transaction, and some of this functionality can be handled by the software.

TextRP supports adopting this amendment, recognizing its potential to enhance our operations by providing a more efficient and user-friendly solution for recurring payments. We are eager to see how this feature evolves and look forward to contributing to its development and/or implementation.

A minimum doesn't make any sense i think, a minimum is just an extra hurdle. Nothing stops me from moving all of my funds to a different wallet. Effectively not allowing you to pull from my funds.

[xrpl365]

I concur with this point, very little value in adding functionality if it can be bypassed.

[XRPSezz]

I think recurring subscription payments is a good idea. The frequency of payments if no minimum limit implemented could even be daily in some instances.
A cooling off period is a legal requirement in some countries, and a customer giving notice to quit the service as well. This proposal allows for those standards to be met i assume?

I think its a sensible approach to funding web3 services.
Better in fact than anything currently available re subs elsewhere.

[xrpl365]

This proposal allows for those standards to be met i assume?
I believe the proposal is flexible enough to account for such things, but the goal of the proposal is not to enforce rules, it is to enable services to build systems on-top which are compliant in their jurisdiction.

[falila]

Maybe we can build a hook 🪝 on evernode to demonstrate this amendment.

[xrpl365]

Creating a hook to do this would certainly be possible, although the implementation would be a bit different.
However this is one of those features where i think having this baked into the protocol actually makes sense, as it is an extension to the core functionality of payments.

[xrpl365]

We believe the specification has now reached a "well-refined" state, incorporating the feedback received so far and making the necessary adjustments.
Please comment here if you have any objections to moving this specification to a DRAFT state.
We will wait for one week to accommodate any final feedback or concerns before proceeding to the next step.

(Note: Per the Contributing guidelines, moving a specification into DRAFT does not imply any formal endorsement or guarantee of adoption. It is simply a mechanism to improve the process of refining the specification.)

[Cadey]

I just have one comment, when creating a subscription i see the use of the destinationtag to represent the users external account, however i think sn explicit "text" feild ehich can be set during the subscription will help the subscription provider much more.

ExternalRef, externRef

This can be included as a memo when the subscription payment is made and can be used to solve s number of potential issues for the provider and is less restricted than the destinationTag

[xrpl365]

I appreciate the input and I will discuss with @dangell7 - the idea of a reference makes sense but whether this needs to be on-chain I am not so sure. It's a tiny change tho if we did.