Interface: MarketOptions

market/service.MarketOptions

• DemandOptions

  ↳ MarketOptions

• proposalFilter
• minProposalsBatchSize
• proposalsBatchReleaseTimeoutMs
• subnetTag
• yagnaOptions
• expirationSec
• logger
• maxOfferEvents
• offerFetchingIntervalSec
• proposalTimeout
• eventTarget
• debitNotesAcceptanceTimeoutSec
• midAgreementDebitNoteIntervalSec
• midAgreementPaymentTimeoutSec

• Optional proposalFilter: ProposalFilter

A custom filter checking the proposal from the market for each provider and its hardware configuration. Duplicate proposals from one provider are reduced to the cheapest one.

src/market/service.ts:18

• Optional minProposalsBatchSize: number

The minimum number of proposals after which the batch of proposal will be processed in order to avoid duplicates

src/market/service.ts:20

• Optional proposalsBatchReleaseTimeoutMs: number

The maximum waiting time for proposals to be batched in order to avoid duplicates

src/market/service.ts:22

• Optional subnetTag: string

DemandOptions.subnetTag

src/market/demand.ts:21

• Optional yagnaOptions: YagnaOptions

DemandOptions.yagnaOptions

src/market/demand.ts:22

• 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.

DemandOptions.expirationSec

src/market/demand.ts:45

• Optional logger: Logger

DemandOptions.logger

src/market/demand.ts:47

• Optional maxOfferEvents: number

DemandOptions.maxOfferEvents

src/market/demand.ts:48

• Optional offerFetchingIntervalSec: number

DemandOptions.offerFetchingIntervalSec

src/market/demand.ts:50

• Optional proposalTimeout: number

DemandOptions.proposalTimeout

src/market/demand.ts:52

• Optional eventTarget: EventTarget

DemandOptions.eventTarget

src/market/demand.ts:54

• 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.

DemandOptions.debitNotesAcceptanceTimeoutSec

src/market/demand.ts:66

• 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.

DemandOptions.midAgreementDebitNoteIntervalSec

src/market/demand.ts:81

• 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.

DemandOptions.midAgreementPaymentTimeoutSec

src/market/demand.ts:94