A heading button for page organization
Blog

THNDR Payments

Clinch is a platform allowing users to wager on skills-based games, facilitated by THNDR Payments for direct user-to-user wagers without depositing funds onto third-party wallets. THNDR Payment Contracts, powered by the Lightning Network, employ hodl invoices and wrapped invoices to introduce conditions and act as an escrow service. Wrapped invoices enable trustless fund transfers via a third party, while hodl invoices allow conditional payments, useful in scenarios like skill-based wagering. THNDR wagers involve deploying two THNDR Payment contracts, each representing one side of the bet, with outcomes including cancellation, execution, or draw based on match results.
Technology
August 8, 2024
THNDR Payments

What is it?

Clinch (clinch.gg) is a platform that allows users to place wagers on skills-based games.

THNDR Payments make it possible for these wagers to occur directly between two users, without the need for depositing funds onto a third party wallet or website. Right now, on Clinch, you can experience the power of THNDR Payments and wager against other players in our game, Club Bitcoin: Solitaire.

How does it work?

The Clinch platform at clinch.gg where users can place wager is fueled by a unique conditional payment called a THNDR Payment Contract. At a high-level, THNDR Payment Contracts make it possible to temporarily pause the flow of payments between two parties, and only execute or cancel the payments once specific conditions have been met. This type of payment is useful in several different scenarios including skills-based wagering (similar to the Clinch platform), general escrow services, auctions, marketplaces, and more.

Under the hood

THNDR Payment Contracts are made up of two unique mechanisms on the Lightning Network: 1 hodl invoices, and 2wrapped invoices. Here’s a breakdown of how each works:

Wrapped invoices: A wrapped invoice essentially allows a third party to serve as a proxy between two parties (i.e. the sender and recipient) in a payment but without ever touching funds that are transferred between the two parties. The third party in this scenario acts, or provides, a similar function as the role of a routing node on the Lightning Network.

  1. The receiver, Bob, creates an invoice Invoice B for the amount of the payment, or in this scenario, the amount of the wager. To keep the payment secure and make sure the funds cannot be stolen, Bob uses a cryptographic hash function. The hash can be thought of as a ‘lock’ that needs a secret key. That secret key is called a pre-image. Only Bob knows the pre-image. You can learn more about payment hashes, preimages, and how they are used in the Lightning Network in Voltage’s blog on HTLC’s here, or in River’s Glossary here.)
  2. Bob will then send his invoice to the third party, THNDR Services then takes the payment hash from Bob’s invoice and crafts another invoice. This is the wrapped invoice Wrapped Invoice B.
  3. In this scenario, Clinch Services can make the invoice for a different amount than that of Bob’s invoice. This is how the third party can introduce a fee, or in the scenario of a wager, a rake.
  4. The third party, THNDR Services, can then send this wrapped invoice to the sender, Alice. However, once Alice pays this wrapped invoice, THNDR Services cannot immediately access the funds sent, as they do not have the initial pre-image.
  5. In order to obtain the pre-image, THNDR Services first needs to pay the initial invoice Invoice B they received from Bob.
  6. Once Bob receives the payment from THNDR Services, he reveals the secret pre-image. This pre-image then allows THNDR Services to claim funds from the wrapped invoice Wrapped Invoice B from Alice.

Wrapped invoices allow the sender Alice) to send funds to the recipient (Bob) trustlessly through the third party Clinch Services)

Hodl Invoice: A hodl invoice allows for the introduction of conditions into a payment flow. If two parties wanted to set up a payment based on a condition being met, hodl invoices allows for this to occur. Example: Alice and Bob want to play a tennis match and Bob bets Alice that if he wins, she will pay him. However, Alice wants to guarantee that Bob actually wins before sending him the payment. Alice and Bob could use a hodl contract to do this.

  1. In this scenario, Bob sends a hodl invoice to Alice for the match payment.
  2. Alice pays the invoice, but unlike a normal payment on the Lightning Network, Bob does not immediately send the pre-image secret to Alice. This keeps the payment from going through until they play the match.
  3. Once the match concludes and the outcome is known, the pre-image is revealed to Alice accordingly:
    1. If Bob wins the match, the pre-image is revealed to Alice and funds are sent to Bob.
    2. If Alice wins the match, the pre-image is not revealed and the funds are returned to Alice.

Hodl invoices are an interesting way to introduce conditional payments on the Lightning Network. For more information on hodl invoices, check out Voltage’s blog post here.

THNDR Payment Contracts: While hodl invoices alone are interesting in the context of wagering, they don’t account for the need for an external party to provide unbiased match results. Combining hodl contracts and wrapped invoices allows us to introduce an oracle in the payment path to provide match outcomes (the condition) while also taking a fee for the service provided.

THNDR wagers: In order to place a wager, two THNDR Payment contracts must be deployed with each one representing one side of the bet:

  • Alice sends the THNDR Service an invoice, which is then wrapped and sent to Bob. This payment represents Bob receiving funds in the event he wins the match.
  • Bob sends the THNDR Service an invoice, which is then wrapped and sent to Alice. This payment represents Alice receiving funds in the event she wins the match.

Note: The wrapped invoices sent to the recipient can be for a different amount than the invoice originally sent from the sender to the THNDR Service. This allows for the introduction of a service fee or rake.Both Alice and Bob pay the respective invoices they were sent. However, THNDR pauses these payments while the parties wait for the outcome of the match (the conditions to be met). Once the match concludes, the THNDR Service cancels the wrapped invoice they sent to the winner (originating from the loser) and the winner’s held funds are returned. The THNDR Service then pays the wrapped invoice they received from the winner, which reveals the pre-image and unlocks the payment from the loser.

Payment permeations

The most common outcomes of a THNDR wager are when one of the two parties wins, but the possible payment permeations consist of:

Party #1 wins: When Alice wins, the invoice from Alice to Bob is cancelled, and the invoice from Bob to Alice is executed. Funds are distributed to Alice with a service fee or rake to THNDR Services

Party #2 wins: When Bob wins, the invoice from Bob to Alice is cancelled, and the invoice from Alice to Bob is executed. Funds are distributed to Bob with a service fee or rake to THNDR Services

Draw: If both parties achieve the same score, the match is considered a “draw”. In this scenarios, both parties’ contracts are cancelled and each receives their deposited funds.

Match cancelled: If one or both parties do not pay the invoice, or do not click “Start Game”, the match is cancelled, and both parties’ deposited funds are returned

Score not submitted: If one party does not play the match after clicking “Start Game” or fails to submit a score, that party receives a score of “0”. If both parties either do not play the match or fail to submit a score, both players receive a score of “0”, the match is a draw, and both contracts are cancelled, and both parties’ funds are returned.

How we hodl

At THNDR, we are committed to acting as good stewards of all open source software, especially Bitcoin and the Lightning Network. We recognize the negative implications hodl invoices could potentially have on the optimal functioning of the network. Due to the conditional nature of hodl contracts, funds are ‘held in limbo until payment conditions are met. When funds are held, this makes it impossible for that channel to be used to route other payments. In the event that hodl contracts are used indiscriminately throughout the network on public channels, this could lead to congestion of the network and negatively impact payment pathfinding and reliability. Weare dedicated to using hodl contracts responsibly. To do so, we operate direct, private channels with wallet providers that service our customers. As such, funds are typically only ever held in private channels for no longer than 10 minutes, and thus, do not impact operation of the overall network. For additional information or questions, please email us at hello@thndr.games.

—--------

Special thanks to Fanis Michalakis for his write-up for LN Market’s Latest Strikes blog. His writing heavily influenced this article and we’re beyond grateful. Follow him on X (aka. Twitter) for more technical insights on the Lightning Network