Services and agreements

Paxeer X turns a service into a verifiable agreement between a provider and a customer. An offer defines price, Asset, terms, deliverable specification, deadlines, and acceptance policy. Agreements bind those terms to an escrow; commitments and execution attestations establish the work performed; delivery records bind the resulting artifacts to their availability references.

Choose a service model

Model	Use it for	Completion evidence
Deliverable agreement	Research, generated assets, analysis, computation, and agent tasks.	Commitments, signed tool execution, delivery hashes, acceptance or dispute ruling.
Paid API	Immediate access to a query result, data resource, or tool endpoint.	Verified payment receipt and a durable fulfillment record.
Metered or recurring API	Usage draws and subscription periods authorized by a payer grant.	A distinct signed receive activity for each draw or renewal.

Use the service module for negotiated work with delivery and acceptance. Use paid API middleware for an HTTP resource that releases its response after receipt verification. Both use the native payment plane; the service module itself does not modify balances.

Register and discover an offer

Publish an offer with LX_SERVICE_OFFER_PUBLISH. Give customers the offer identifier and a human-readable description of its terms and deliverable specification. Content hashes commit to the exact documents; host the documents and artifacts where the customer can retrieve and verify them. Discovery identifies a suitable offer; the customer checks its Asset, price, expiry, and policy before proposing an agreement.

Offer field	Meaning
`offer_id`, `asset_id`, `price`	Nonzero offer identity, payment Asset identity, and positive integer price.
`terms_hash`	Commitment to the terms the customer accepts.
`deliverable_specification_hash`	Commitment to the expected result.
`delivery_deadline`, `offer_expiry`	Delivery limit and the offer validity boundary.
`acceptance_window`, `dispute_window`	Nonzero windows controlling review and disputes.
`default_outcome`	`1` accepts or `2` rejects when the review policy applies.

Withdraw an offer with LX_SERVICE_OFFER_WITHDRAW. An unavailable offer or mismatched terms prevents a new agreement from proceeding.

From offer to invocation

Read the offer and verify the terms and deliverable documents against their hashes.
Prepare payment escrow through 402LXP and retain its identifier.
Propose an agreement with agreement_id, offer_id, terms_hash, and escrow_id using LX_SERVICE_AGREEMENT_PROPOSE.
The provider accepts with LX_SERVICE_AGREEMENT_ACCEPT.
Commit a task using LX_SERVICE_COMMIT_TASK, binding its task hash, escrow, positive deadline, and resource bound.
Execute the agreed capability, publish signed execution attestations, and report progress.
Deliver artifacts for customer acceptance; resolve escrow through the payment lifecycle.

Commitments and execution attestations

A task commitment records commitment_id, agreement_id, task_hash, escrow_id, deadline, and resource_bound. An abandoned commitment carries an explicit reason through LX_SERVICE_COMMIT_ABANDON.

LX_SERVICE_TOOL_EXEC_ATTEST records the tool identifier, input and output commitments, execution window, resource units, attestor identity, availability reference, public key, and signature. Verification checks the attestor; invalid signatures or execution evidence are refused as LXP_ERR_INVALID_ATTESTATION.

LX_SERVICE_PROGRESS_REPORT binds a report and note hash to a commitment and availability reference. Progress is an integer from 1 through 10000 basis points. Progress cannot regress.

Deliver and review

LX_SERVICE_DELIVER carries one to sixteen artifacts. Each item contains a nonzero hash, a positive byte size, and an availability reference. The protocol checks the deliverable specification, data availability, and deadline. Retain the bytes corresponding to every declared hash so the customer can verify the result.

delivery_id32 || agreement_id32 || count:u8
|| { hash32 || artifact_size:u64 || availability_reference32 } × count

The customer accepts with LX_SERVICE_ACCEPT or rejects using LX_SERVICE_REJECT, a rejection reason, and contested hashes. Protocol batch maintenance applies the agreement's default review policy when the acceptance window ends.

Disputes and resolution

LX_SERVICE_DISPUTE_OPEN binds a dispute identifier and evidence hashes to the agreement. Only an authorized disputant can open the dispute within its window. LX_SERVICE_DISPUTE_RESOLVE supplies a nonzero ruling, the provider's allocation in basis points, and the escrow resolution identifier. Allocation ranges from zero to 10000.

Activity reference

The service module ID is 5; record version is 1, encoded by the prefix bytes 00 01. Identifiers and hashes are 32 bytes. Submit canonical activities through the native protocol path.

Activity	Type	Payload bytes including version
Offer publish / withdraw	`0x00050001 / 0x00050002`	179 / 34
Agreement propose / accept	`0x00050003 / 0x00050004`	130 / 34
Task commit / abandon	`0x00050005 / 0x00050006`	146 / 36
Tool execution attest / progress	`0x00050007 / 0x00050008`	Variable / 134
Deliver / accept	`0x00050009 / 0x0005000a`	67 + 72 per item / 34
Reject / dispute open	`0x0005000b / 0x0005000c`	37 + 32 per hash / 67 + 32 per hash
Dispute resolve	`0x0005000d`	72

Handle refusals and retries

Preserve the agreement, commitment, activity, and escrow identifiers across retries. Check status before resubmission after a timeout. Sequence reuse, unauthorized debit, unavailable offers, terms mismatch, and invalid agreement state are distinct refusals; changing payment identity to escape uncertainty can create a second economic action.

Delivery errors distinguish LXP_ERR_DELIVERABLE_MISMATCH, LXP_ERR_DA_MISSING, and LXP_ERR_DELIVERY_DEADLINE_PASSED. Dispute errors distinguish an unauthorized actor from a closed window. Correct the refused condition before submitting a new action.

Continue building

Connect immediate resource access with paid APIs and x402, explore SDK integrations, and inspect the protocol modules.