DEV Community

Cover image for Stellar Quests Level 1: Path Payments
WZRD
WZRD

Posted on

Stellar Quests Level 1: Path Payments

What are Path Payments?

Similar to Payments, a Path Payment is the transfer of currency from one party/person/thing to another, but the difference is that the recipient will receive their desired currency rather than what was originally sent from the source. Payments are sent directly from one account to another, while a Path Payment goes through the Stellar DEX (decentralized exchange) and/or liquidity pools before reaching the recipient.

In order for a Path Payment to work, there needs to be sufficient buy/sell offers on the DEX or a liquidity pool exchange path. There are times when a path payment will need to take several hops before reaching its destination, and although the transaction can fail when there aren't sufficient offers or liquidity pools, this operation is still "convenient".

Account A sells XLM → [buy XLM / sell ETH → buy ETH / sell BTC → buy BTC / sell USDC] → Account B receives USDC

There are two different operations for Path Payments: path payments "strict send", and path payment "strict receive". These two operations act in a different manner: the first, Strict Send, will make sure that the amount sent from the source is exact while the amount received by the destination may be less depending on conversion rates; and the second, Strict Receive, will make sure that the amount received by the destination is exact while the amount sent from the source may be less or more- also depending on conversion rates.

Both Path Payment Strict Send and Path Payment Strict Receive, on the Stellar blockchain, are operation types that must be selected when building a transaction. NOTE: Don't confuse transactions with operations- a single transaction can perform many different types of operations, and can also bundle many operations into the single transaction.

Path Payment Strict Send

Strict Send path payments are created by building a transaction of operation type "Path Payment Strict Send". This operation asks for seven inputs: destination, sending asset, send amount, intermediate path, destination asset, minimum destination amount, and source account. The Destination is the public key of the account that will receive the payment. The Sending Asset is the form of value one will send to the destination; this can be the native asset Lumen ($XLM), or a custom asset. NOTE: In order for a destination to receive a custom asset, they must've established a trustline for it. The Sending Amount is the exact total of an asset one will send to the destination. The Intermediate Path specifies the assets one wants the payment to path through; this input is optional because it gives greater control to organizations if needed. The Destination Asset is the form of value received by the destination. The Minimum Destination Amount is the min amount of an asset that must be received by the destination; which can cause a transaction to fail is there aren't sufficient buy/sell offers or liquidity pools available to guarantee the minimum. The Source Account is the public key of the account that'll be making the path payment; this input is optional because if the value won't be sent by the account which has built the transaction, then the public key entered here will refer to the account that will send the value. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually making the path payment.

Path Payment Strict Receive

Strict Receive path payments are created by building a transaction of operation type "Path Payment Strict Receive". This operation asks for seven inputs: destination, sending asset, maximum send amount, intermediate path, destination asset, destination amount, and source account. The Destination is the public key of the account that will receive the payment. The Sending Asset is the form of value one will send to the destination; this can be the native asset Lumen ($XLM), or a custom asset. NOTE: In order for a destination to receive a custom asset, they must've established a trustline for it. The Maximum Sending Amount is the max amount of an asset one is willing to send to the destination; which can cause a transaction to fail is there aren't sufficient buy/sell offers or liquidity pools available to guarantee the maximum. The Intermediate Path specifies the assets one wants the payment to path through; this input is optional because it gives greater control to organizations if needed. The Destination Asset is the form of value received by the destination. The Destination Amount is the exact total of an asset one will receive from the source. The Source Account is the public key of the account that'll be making the path payment; this input is optional because if the value won't be sent by the account which has built the transaction, then the public key entered here will refer to the account that will send the value. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually making the path payment.

Outro

I plan on writing corresponding blog posts with relevant code examples. For now, I'm simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net. If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Top comments (0)