Interface: DemandOptions
market/demand.DemandOptions
Hierarchy
DemandOptions
Table of contents
Properties
- subnetTag
- yagnaOptions
- expirationSec
- logger
- maxOfferEvents
- offerFetchingIntervalSec
- proposalTimeout
- eventTarget
- debitNotesAcceptanceTimeoutSec
- midAgreementDebitNoteIntervalSec
- midAgreementPaymentTimeoutSec
Properties
subnetTag
• Optional
subnetTag: string
Defined in
yagnaOptions
• Optional
yagnaOptions: YagnaOptions
Defined in
expirationSec
• Optional
expirationSec: number
Determines the expiration time of the offer and the resulting activity in milliseconds.
The value of this field is used to define how long the demand is valid for yagna to match against. In addition, it will determine how long the resulting activity will be active.
For example: if expirationSec
is set to 10 minutes, the demand was created and starting an activity required 2 minutes, this means that the activity will be running for 8 more minutes, and then will get terminated.
IMPORTANT
It is possible that a provider will reject engaging with that demand if it's configured without using a deadline.
GUIDE
If your activity is about to operate for 5-30 min, expirationSec is sufficient.
If your activity is about to operate for 30min-10h, debitNotesAcceptanceTimeoutSec should be set as well.
If your activity is about to operate longer than 10h, you need set both debitNotesAcceptanceTimeoutSec and midAgreementPaymentTimeoutSec.
Defined in
logger
• Optional
logger: Logger
Defined in
maxOfferEvents
• Optional
maxOfferEvents: number
Defined in
offerFetchingIntervalSec
• Optional
offerFetchingIntervalSec: number
Defined in
proposalTimeout
• Optional
proposalTimeout: number
Defined in
eventTarget
• Optional
eventTarget: EventTarget
Defined in
debitNotesAcceptanceTimeoutSec
• Optional
debitNotesAcceptanceTimeoutSec: number
Maximum time for allowed provider-sent debit note acceptance (in seconds)
Accepting debit notes from the provider is used as a health-check of the agreement between these parties. Failing to accept several debit notes in a row will be considered as a valida reason to terminate the agreement earlier than expirationSec defines.
Accepting debit notes during a long activity is considered a good practice in Golem Network. The SDK will accept debit notes each 2 minutes by default.
Defined in
midAgreementDebitNoteIntervalSec
• Optional
midAgreementDebitNoteIntervalSec: number
The interval between provider sent debit notes to negotiate.
If it would not be defined, the activities created for your demand would probably live only 30 minutes, as that's the default value that the providers use to control engagements that are not using mid-agreement payments.
As a requestor, you don't have to specify it, as the provider will propose a value that the SDK will simply accept without negotiations.
Accepting payable debit notes during a long activity is considered a good practice in Golem Network. The SDK will accept debit notes each 2 minutes by default.
Defined in
midAgreementPaymentTimeoutSec
• Optional
midAgreementPaymentTimeoutSec: number
Maximum time to receive payment for any debit note. At the same time, the minimum interval between mid-agreement payments.
Setting this is relevant in case activities which are running for a long time (like 10 hours and more). Providers control the threshold activity duration for which they would like to enforce mid-agreement payments. This value depends on the provider configuration. Checking proposal rejections from providers in yagna's logs can give you a hint about the market expectations.
Paying in regular intervals for the computation resources is considered a good practice in Golem Network. The SDK will issue payments each 12h by default, and you can control this with this setting.