Golem Deep Dive #1: Mid-agreement payments

Introducing the Golem Deep Dive!

We’ve wrapped up the GitHub Digest series and are starting something new, the Golem Deep Dive. This new series will allow us to go into a broader range of topics other than purely covering the Golem GitHub.

For the start of this new series, we’re going to be covering the features of the Beta V release in more detail. We’ll start with mid-agreement payments and later we’ll go into HTTP auth runtime, local HTTP proxy, and the new events interface.

Up close and personal with mid-agreement payments

Mid-agreement payments are a new form of payment option between providers and requestors. Initially introduced in Golem Architecture Proposal 3 (GAP-3), it’s motivated by the fact that requestors may want to run a task that will take quite a long time to complete. Before this improvement, tasks couldn't be too long without an increased risk to the provider of the requestor disconnecting and the provider losing GLM for their computation time. This was previously mitigated by restricting the maximum task length.

Now, with mid-agreement payment functionality,  the task length doesn't need to be restricted, and the risk to the provider for longer tasks can be removed, with payments occurring gradually as the task is running on their system. In a sense, it’s streaming payments, in contrast to payment in bulk at the end of a task. For providers, it offers peace of mind that a task is being paid in increments. For requestors, this can give an advantage over centralized services such as AWS where users pay their bills in bulk at the end of a month.

It involves payments in set, pre-agreed intervals during the course of an agreement. Allowing providers to receive payments during long computation processes by setting:

1. golem.com.scheme.payu.interval_sec? - The interval the Provider expects the Requestor to pay for the usage during a mid-agreement period.
2. golem.com.scheme.payu.payment-timeout-sec? - The time the Provider will be expecting payments from the Requestor within Debit Note being issued during a mid-agreement period.

It's also important to note that this type of payment wouldn’t be as economical without the integration of the Polygon Payment driver, introduced in Beta III. This is primarily related to the fees we can achieve with payments on Polygon which are roughly 150 times cheaper than the fees we were able to achieve on ZkSync, the previous default payment driver.

This isn’t to imply that a tradeoff doesn’t exist between the requestor paying fees for each transfer during mid-agreement payments and the benefit to the provider. Requestors will naturally wish to minimize the transaction fees even with the lower fees offered on Polygon. In the future, there’s potential to further lower fees and make this even more economical for the requestor. For those more interested in approaches, a bit of light reading on the Polygon ZKVerse might spark some interest!

If you’d like to learn more about mid-agreement payments, we recommend diving further into the documentation mid-agreement payment section and GAP-3. For questions, join us in the Golem Discord where our team is active in discussion and support.