AgentPayment Transaction Type

[ehounder]

Amendment Proposal: AgentPayment Transaction Type
Title: Introduction of AgentPayment Transaction Type

Description:
The AgentPayment transaction type proposed is an Atomic/Batch Transactions #162 multi payment transaction, designed to facilitate transactions where an agent or intermediary is involved, similar to credit card transactions. This amendment aims to streamline processes for transactions involving agents, such as websites, apps, car, real estate agents, AI agents, and so on allowing for an automatic calculation of agent fees within a single transaction.

Proposed Changes:

1. New Atomic/Batch Transactions 0056 XLS-56d: Atomic/Batch Transactions #162 Transaction Type:
   • TransactionType: "AgentPayment"
2. New Fields:
   • Account: The address of the buyer initiating the transaction.
   • AgentAccount: The address of the agent who will receive a percentage of the transaction amount.
   • AgentPercent: A decimal value representing the percentage of the purchase amount that goes to the agent.
   • PurchaseAmount: The amount of the purchase in drops (if XRP) or in issuer/currency format for other currencies.
   • AgentAmount: Calculated field representing the amount due to the agent based on AgentPercent.
   • Amount: The total amount to be transferred, which includes both the purchase amount and the agent's fee.
   • Destination: The address of the seller or final recipient of the funds.

Example Payload:

json
{
  "TransactionType": "AgentPayment",
  "Account": "buyer_wallet.address",
  "AgentAccount": "agent_wallet.address",
  "AgentPercent": 0.05,  // Example: 5% agent fee
  "PurchaseAmount": "1000000",  // 1 XRP in drops payment to "Destination"
  "AgentAmount": "50000",       // 0.05 * 1000000 = 50000 drops payment to "AgentAccount"
  "Amount": "1050000",          // 1000000 + 50000 = 1050000 drops total payment by "Account"
  "Destination": "seller_wallet.address"
}

Operational Details:

• Fee Calculation: The AgentAmount is calculated automatically based on PurchaseAmount and AgentPercent. This ensures that the agent receives their fee without requiring an additional transaction.
• Transaction Validation: The transaction must validate that Amount equals PurchaseAmount + AgentAmount to prevent discrepancies.
• Pathfinding: If the transaction involves currency conversion or pathfinding, these should be accounted for in the Amount calculation, ensuring all participants are compensated correctly.
• Ledger Hooks: Implement hooks to ensure that the transaction respects the XRPL's consensus rules and does not introduce vulnerabilities or overload the ledger with complex calculations.

Amendment Process:

• Voting: Requires Atomic/Batch Transactions 0056 XLS-56d: Atomic/Batch Transactions #162 amendment approval as use case type in the XRPL's amendment voting process where validators must vote on its inclusion.
• Testing: Before final voting, the amendment should be thoroughly tested in a testnet environment to ensure compatibility, security, and efficiency.

Rationale:
This amendment enhances the utility of the XRPL for more complex transaction scenarios, similar to how credit card purchases work, by integrating agent or intermediary fees directly into the transaction logic, thus reducing the need for multiple transactions and improving efficiency.

Potential Impact:

• User Experience: Simplified payment processes for transactions involving agents or intermediaries.
• Ledger Efficiency: Reduces the number of transactions needed for agent-fee collection.
• Economic: Could lead to more business models on the XRPL by supporting agent-based sales structures.

This amendment proposal would need to be formally drafted with exact specifications, reviewed by the XRPL community, subjected to extensive testing, and finally voted upon by validators.

[mvadari]

This problem is solved by #197 or #194.

[ehounder]

Ok great @mvadari the problem is solved with your spec Atomic/Batch Transactions #162 and @tequdev #194, #197.

Idea here is to rename the TransactionType AgentPayment instead of Batch proposing the following payload which is of course what frontend devs are concerned with:

json
{
  "TransactionType": "AgentPayment",
  "Account": "buyer_wallet.address",
  "AgentAccount": "agent_wallet.address",
  "AgentPercent": 0.05,  // Example: 5% agent fee
  "PurchaseAmount": "1000000",  // 1 XRP in drops payment to "Destination"
  "AgentAmount": "50000",       // 0.05 * 1000000 = 50000 drops payment to "AgentAccount"
  "Amount": "1050000",          // 1000000 + 50000 = 1050000 drops total payment by "Account"
  "Destination": "seller_wallet.address"
}

So we are ready to test such an AgentPayment transaction payload on the XRPL-Xaman devnets yes?

[mvadari]

Batch is much broader so it doesn't make sense to rename it.

[ehounder]

Yes of course Batch is much broader and shouldn't be renamed. Rather my poorly worded intent above is to make a specific type of Batch TransactionType AgentPayment executing by means of the above payload which of course would be just one initial variation of the Batch spec.

The XRPL-Xaman devnets test I am proposing could operate on a UI such as my https://smartlegalcontracts.net domain where users tokenize documents, make payments and escrows with my Xaman wallet signing API - any of which html-javascript I could minimize to run on the XRPL and Xaman devnets to be available in the Sample Code repository.

What do you think @mvadari could the Batch spec be applied to test this specific TransactionType AgentPayment?