{"id":"3931fad2-5fc4-4281-bbf3-0c6d66fe8aa3","entityType":"agent","slug":"clawhub-10000-c-tyrpay-seller-skill","name":"Tyrpay Seller Skill","canonicalUrl":"https://www.xpersona.co/agent/clawhub-10000-c-tyrpay-seller-skill","canonicalPath":"/agent/clawhub-10000-c-tyrpay-seller-skill","generatedAt":"2026-10-11T20:59:47.951Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T16:52:29.043Z","emptyReason":null},"description":"Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s179y7my1af239v2k8a8qcad7x86px7g:tyrpay-seller-skill","sourceUrl":"https://clawhub.ai/10000-c/tyrpay-seller-skill","homepage":"https://clawhub.ai/10000-c/skills/tyrpay-seller-skill","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/10000-c/tyrpay-seller-skill","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/10000-c/skills/tyrpay-seller-skill","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Tyrpay Seller Skill technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T16:52:29.043Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T16:52:29.043Z","emptyReason":null},"stars":null,"forks":null,"downloads":1024,"packageName":null,"latestVersion":"0.1.13","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T16:52:29.029Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T16:52:29.043Z","lastCrawledAt":"2026-10-11T16:52:29.029Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T16:52:29.029Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.13","createdAt":"2026-05-15T17:48:53.565Z","changelog":"- Documentation updates in SKILL.md for better clarity and easier onboarding. - No changes to core logic or APIs; workflows and usage remain the same. - Improved wording and expanded guidance for failure diagnosis and storage adapter usage.","fileCount":5,"zipByteSize":6950},{"version":"0.1.12","createdAt":"2026-05-15T17:40:38.940Z","changelog":"- Documentation (SKILL.md) updated for clarity and completeness. - No functional or code changes; documentation only.","fileCount":4,"zipByteSize":4415},{"version":"0.1.11","createdAt":"2026-05-15T17:36:06.010Z","changelog":"- Updated SKILL.md formatting and markdown structure for consistency. - No functional or user-facing changes to the skill's workflow or usage. - Clarified and reformatted documentation without changing its content.","fileCount":4,"zipByteSize":4415},{"version":"0.1.9","createdAt":"2026-05-15T15:47:56.710Z","changelog":"- Documentation updated: Minor edit to SKILL.md; no changes to core functionality. - No new features or bug fixes included in this release. - Ensures current usage notes and workflow details are clear and up to date.","fileCount":4,"zipByteSize":4415},{"version":"0.1.8","createdAt":"2026-05-15T09:33:08.998Z","changelog":"tyrpay-seller-skill v0.1.8 - Documentation updated: Minor amendment to SKILL.md with no change in instructions or technical content. - No functional or code changes in this release.","fileCount":4,"zipByteSize":4415},{"version":"0.1.7","createdAt":"2026-05-15T06:06:53.281Z","changelog":"- Added TeeTLS/TeeML support and related workflow for 0G model endpoint discovery. - Introduced the tyrpay_discover_model_endpoint tool and updated the workflow and usage notes accordingly. - Updated settlement contract requirements: added requiredMinUsage and requiredModelsHash fields. - Expanded tooling notes with model and endpoint binding requirements for 0G TeeTLS. - Improved documentation for provider-specific (0g-teetls) commitment constraints and options.","fileCount":4,"zipByteSize":4415},{"version":"0.1.6","createdAt":"2026-05-14T19:10:33.506Z","changelog":"Initial ClawHub release","fileCount":4,"zipByteSize":3820}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s179y7my1af239v2k8a8qcad7x86px7g:tyrpay-seller-skill","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s179y7my1af239v2k8a8qcad7x86px7g:tyrpay-seller-skill` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/10000-c/tyrpay-seller-skill before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T20:59:47.949Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T16:52:29.043Z","emptyReason":null},"readme":"Skill: Tyrpay Seller Skill\n\nOwner: 10000-c\n\nSummary: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\n\nTags: latest:0.1.13\n\nVersion history:\n\nv0.1.13 | 2026-05-15T17:48:53.565Z | auto\n\n- Documentation updates in SKILL.md for better clarity and easier onboarding.\n- No changes to core logic or APIs; workflows and usage remain the same.\n- Improved wording and expanded guidance for failure diagnosis and storage adapter usage.\n\nv0.1.12 | 2026-05-15T17:40:38.940Z | auto\n\n- Documentation (SKILL.md) updated for clarity and completeness.\n- No functional or code changes; documentation only.\n\nv0.1.11 | 2026-05-15T17:36:06.010Z | auto\n\n- Updated SKILL.md formatting and markdown structure for consistency.\n- No functional or user-facing changes to the skill's workflow or usage.\n- Clarified and reformatted documentation without changing its content.\n\nv0.1.9 | 2026-05-15T15:47:56.710Z | auto\n\n- Documentation updated: Minor edit to SKILL.md; no changes to core functionality.\n- No new features or bug fixes included in this release.\n- Ensures current usage notes and workflow details are clear and up to date.\n\nv0.1.8 | 2026-05-15T09:33:08.998Z | auto\n\ntyrpay-seller-skill v0.1.8\n\n- Documentation updated: Minor amendment to SKILL.md with no change in instructions or technical content.\n- No functional or code changes in this release.\n\nv0.1.7 | 2026-05-15T06:06:53.281Z | auto\n\n- Added TeeTLS/TeeML support and related workflow for 0G model endpoint discovery.\n- Introduced the tyrpay_discover_model_endpoint tool and updated the workflow and usage notes accordingly.\n- Updated settlement contract requirements: added requiredMinUsage and requiredModelsHash fields.\n- Expanded tooling notes with model and endpoint binding requirements for 0G TeeTLS.\n- Improved documentation for provider-specific (0g-teetls) commitment constraints and options.\n\nv0.1.6 | 2026-05-14T19:10:33.506Z | user\n\nInitial ClawHub release\n\nArchive index:\n\nArchive v0.1.13: 5 files, 6950 bytes\n\nFiles: _meta.json (139b), LICENSE.txt (244b), references/tool-reference.md (6108b), skill-card.md (2541b), SKILL.md (4876b)\n\nFile v0.1.13:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`,\n  `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- For provider `\"0g-teetls\"`, `commitment.target.host/path` must match the\n  resolved 0G endpoint, `method` must be `POST`, and `allowedModels` must include\n  the model returned by 0G service metadata. Forward the recommended\n  `providerOptions` from `tyrpay_discover_model_endpoint` to `tyrpay_execute_task`.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.13:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.13\",\n  \"publishedAt\": 1778867333565\n}\n\nFile v0.1.13:references/tool-reference.md\n\n# Tool Reference\n\n## Exported Tools\n\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\n\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\n- `PAID`: task settled, payment released to seller.\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\n## Environment Configuration\n\nCopy these variables into a `.env` file and fill in the values. seller-skill receives all config through constructor parameters; these variables are needed to build those parameters (signer, adapters, contract address, etc.) at application startup.\n\n### Settlement Chain & Wallet (required)\n\n| Variable | Description | Example |\n|---|---|---|\n| `ZERO_G_EVM_RPC` | EVM RPC endpoint for the 0G settlement chain. Used by ethers provider, 0G storage adapter, and on-chain interactions. | `https://evmrpc.0g.ai` |\n| `SELLER_PRIVATE_KEY` | Seller wallet private key (hex, with or without 0x prefix). Used to create the ethers Signer that signs all on-chain transactions. | |\n| `CHAIN_ID` | Settlement chain ID. Must match the network behind `ZERO_G_EVM_RPC`. 16661 = 0G mainnet, 16602 = 0G Galileo testnet. | `16661` |\n| `SETTLEMENT_CONTRACT` | Deployed TyrPaySettlement contract address on the settlement chain. | `0x6D548b2eD427ABeb1564e0A65C5FC8d5A8394ad9` |\n\n### 0G Storage Adapter (production required)\n\nRequired when using `ZeroGStorageAdapter`. Omit when using `MemoryStorageAdapter` (testing only).\n\n| Variable | Description | Example |\n|---|---|---|\n| `ZERO_G_INDEXER_RPC` | 0G storage indexer endpoint for reading stored objects. | `https://indexer-storage-turbo.0g.ai` |\n| `ZERO_G_STORAGE_PRIVATE_KEY` | Private key used to upload proof bundles and receipts to 0G storage. Can differ from `SELLER_PRIVATE_KEY`. | |\n\n### Reclaim zkTLS Adapter (production required)\n\nRequired when using `ReclaimZkTlsAdapter`. Omit when using `MockZkTlsAdapter` (testing only).\n\n| Variable | Description | Example |\n|---|---|---|\n| `RECLAIM_APP_ID` | Reclaim protocol application ID. | |\n| `RECLAIM_APP_SECRET` | Reclaim protocol application secret. | |\n\n### Upstream Model API (runtime required)\n\nThe model API key / URL are typically passed at call time via `providerOptions`, but many integrations load them from the environment.\n\n| Variable | Description | Example |\n|---|---|---|\n| `MODEL_API_KEY` | API key for the upstream LLM provider (e.g. OpenAI, DeepSeek). | |\n| `MODEL_BASE_URL` | Base URL of the upstream LLM provider. | `https://api.openai.com` |\n| `MODEL_NAME` | Model name to use for completions. | `gpt-4o-mini` |\n\n### Verifier (optional)\n\n| Variable | Description | Example |\n|---|---|---|\n| `VERIFIER_SIGNER_ADDRESS` | Verifier signer address registered on-chain. Passed as `verifierSignerAddress` to `SellerSkillConfig`. | `0x2833BfA9a65D77dC61a0A7d2D74d84E73ca60Ab0` |\n| `VERIFIER_CONTRACT` | Deployed verifier contract address (used in some setups). | `0x20Fd439a0BB7F250d7a097Bffe465e8f7D1a97dc` |\n| `VERIFIER_SERVICE_URL` | Local verifier service URL. | |\n\n### Debug / Testing (optional)\n\n| Variable | Description | Example |\n|---|---|---|\n| `tyrpay_E2E_TIMING` | Set to `\"1\"` to enable end-to-end timing logs in `SellerAgent.provenFetch()`. | |\n\nFile v0.1.13:skill-card.md\n\n## Description:\n\nSeller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[10000-c](https://clawhub.ai/user/10000-c)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agent operators use this skill to run the seller side of a TyrPay task: accepting buyer tasks, executing zkTLS-proven API calls, submitting proof bundles, and monitoring settlement.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Wallet private keys, storage private keys, Reclaim secrets, and model API keys are high-value secrets used by the seller workflow.\n\nMitigation: Keep secrets out of version control and logs, and run the workflow only in an environment intended to sign TyrPay settlement transactions.\n\nRisk: Unpinned or unexpected package names could change the behavior of a payment-signing runtime.\n\nMitigation: Use trusted package names and pinned versions where possible before installing the TyrPay seller packages and optional zkTLS dependencies.\n\nRisk: Local memory storage is not retrievable across buyer and verifier processes in real multi-party flows.\n\nMitigation: Use persistent shared storage such as 0G, IPFS, or HTTP for production or cross-agent workflows.\n\nRisk: Incorrect settlement ABI, verifier signer, endpoint, or model commitment data can cause invalid settlement state or proof submission.\n\nMitigation: Verify the current settlement ABI, use the registry-authorized verifier signer, and commit only to the endpoint and model resolved by the 0G TeeTLS adapter metadata.\n\n## Reference(s):\n\n- [Tool Reference](references/tool-reference.md)\n- [Tyrpay Seller Skill on ClawHub](https://clawhub.ai/10000-c/skills/tyrpay-seller-skill)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Shell commands, Configuration]\n\n**Output Format:** [Markdown guidance with tool names, workflow steps, and configuration tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes seller status names, environment variables, and operational constraints for TyrPay settlement workflows.]\n\n## Skill Version(s):\n\n0.1.13 (source: server release metadata and _meta.json)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.1.13:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.\n\nArchive v0.1.12: 4 files, 4415 bytes\n\nFiles: _meta.json (139b), LICENSE.txt (244b), references/tool-reference.md (3237b), SKILL.md (4876b)\n\nFile v0.1.12:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`,\n  `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- For provider `\"0g-teetls\"`, `commitment.target.host/path` must match the\n  resolved 0G endpoint, `method` must be `POST`, and `allowedModels` must include\n  the model returned by 0G service metadata. Forward the recommended\n  `providerOptions` from `tyrpay_discover_model_endpoint` to `tyrpay_execute_task`.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.12:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.12\",\n  \"publishedAt\": 1778866838940\n}\n\nFile v0.1.12:references/tool-reference.md\n\n# Tool Reference\r\n\r\n## Exported Tools\r\n\r\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\r\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\r\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\r\n\r\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\r\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\r\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\r\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\r\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\r\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\r\n- `PAID`: task settled, payment released to seller.\r\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\nFile v0.1.12:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.\n\nArchive v0.1.11: 4 files, 4415 bytes\n\nFiles: _meta.json (139b), LICENSE.txt (244b), references/tool-reference.md (3237b), SKILL.md (4876b)\n\nFile v0.1.11:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`,\n  `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- For provider `\"0g-teetls\"`, `commitment.target.host/path` must match the\n  resolved 0G endpoint, `method` must be `POST`, and `allowedModels` must include\n  the model returned by 0G service metadata. Forward the recommended\n  `providerOptions` from `tyrpay_discover_model_endpoint` to `tyrpay_execute_task`.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.11:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.11\",\n  \"publishedAt\": 1778866566010\n}\n\nFile v0.1.11:references/tool-reference.md\n\n# Tool Reference\r\n\r\n## Exported Tools\r\n\r\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\r\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\r\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\r\n\r\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\r\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\r\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\r\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\r\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\r\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\r\n- `PAID`: task settled, payment released to seller.\r\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\nFile v0.1.11:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.\n\nArchive v0.1.9: 4 files, 4415 bytes\n\nFiles: _meta.json (138b), LICENSE.txt (244b), references/tool-reference.md (3237b), SKILL.md (4876b)\n\nFile v0.1.9:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`,\n  `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- For provider `\"0g-teetls\"`, `commitment.target.host/path` must match the\n  resolved 0G endpoint, `method` must be `POST`, and `allowedModels` must include\n  the model returned by 0G service metadata. Forward the recommended\n  `providerOptions` from `tyrpay_discover_model_endpoint` to `tyrpay_execute_task`.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.9:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.9\",\n  \"publishedAt\": 1778860076710\n}\n\nFile v0.1.9:references/tool-reference.md\n\n# Tool Reference\r\n\r\n## Exported Tools\r\n\r\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\r\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\r\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\r\n\r\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\r\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\r\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\r\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\r\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\r\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\r\n- `PAID`: task settled, payment released to seller.\r\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\nFile v0.1.9:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.\n\nArchive v0.1.8: 4 files, 4415 bytes\n\nFiles: _meta.json (138b), LICENSE.txt (244b), references/tool-reference.md (3237b), SKILL.md (4876b)\n\nFile v0.1.8:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`,\n  `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- For provider `\"0g-teetls\"`, `commitment.target.host/path` must match the\n  resolved 0G endpoint, `method` must be `POST`, and `allowedModels` must include\n  the model returned by 0G service metadata. Forward the recommended\n  `providerOptions` from `tyrpay_discover_model_endpoint` to `tyrpay_execute_task`.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.8:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.8\",\n  \"publishedAt\": 1778837588998\n}\n\nFile v0.1.8:references/tool-reference.md\n\n# Tool Reference\r\n\r\n## Exported Tools\r\n\r\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\r\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\r\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\r\n\r\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\r\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\r\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\r\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\r\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\r\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\r\n- `PAID`: task settled, payment released to seller.\r\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\nFile v0.1.8:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.\n\nArchive v0.1.7: 4 files, 4415 bytes\n\nFiles: _meta.json (138b), LICENSE.txt (244b), references/tool-reference.md (3237b), SKILL.md (4876b)\n\nFile v0.1.7:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`,\n  `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- For provider `\"0g-teetls\"`, `commitment.target.host/path` must match the\n  resolved 0G endpoint, `method` must be `POST`, and `allowedModels` must include\n  the model returned by 0G service metadata. Forward the recommended\n  `providerOptions` from `tyrpay_discover_model_endpoint` to `tyrpay_execute_task`.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.7:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.7\",\n  \"publishedAt\": 1778825213281\n}\n\nFile v0.1.7:references/tool-reference.md\n\n# Tool Reference\r\n\r\n## Exported Tools\r\n\r\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\r\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\r\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\r\n\r\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\r\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\r\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\r\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\r\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\r\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\r\n- `PAID`: task settled, payment released to seller.\r\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\nFile v0.1.7:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.\n\nArchive v0.1.6: 4 files, 3820 bytes\n\nFiles: _meta.json (138b), LICENSE.txt (244b), references/tool-reference.md (2494b), SKILL.md (4007b)\n\nFile v0.1.6:SKILL.md\n\n---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\r\n5. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\r\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\r\n- The agent must produce zkTLS-backed proofs of upstream API calls.\r\n- The agent needs structured task state that is safe to show to an end user.\r\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\r\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\r\n2. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\r\n3. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\r\n4. Once funded, call `tyrpay_execute_task` for each required upstream API call.\r\n5. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\r\n6. Use `tyrpay_check_settlement` to monitor whether verification released payment.\r\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `commitmentHash`, `commitmentURI`, `fundedAtMs`, `proofBundleHash`,\n  `proofBundleURI`, `proofSubmittedAtMs`, `reportHash`, `settledAtMs`,\n  `refundedAtMs`, `status`.\n- `tyrpay_execute_task` requires the `commitment` object returned by `tyrpay_accept_task`.\n- `tyrpay_submit_proof` requires all receipts collected from `tyrpay_execute_task` calls.\n- Seller-facing statuses include `PAID` on successful settlement and `NOT_PAID_REFUNDED` on refund.\n\n## Failure Diagnosis\n\n- If the task exists, seller address matches, and buyer has funded but status or\n  commitment fields look wrong, first inspect the ABI used for `getTask()`. A\n  stale ABI or positional mapping can shift fields and make seller-skill parse\n  `commitmentHash`, timestamps, or `status` from the wrong slot.\n- Do not use `MemoryStorageAdapter` for a real multi-party flow. It returns\n  `memory://` URIs that only the same JavaScript process can read. Buyer and\n  verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.\n- A commitment hash mismatch means the full canonical `ExecutionCommitment`\n  object is different from the object originally submitted. Chain data alone is\n  insufficient to reconstruct it; fetch it from `commitmentURI` or ask the\n  creator for the exact object.\n- `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`,\n  `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install\n  those optional peer dependencies in the runtime that constructs the adapter.\n  Windows runtimes must keep Reclaim TEE mode disabled.\n\n## Resources\n\n- `references/tool-reference.md` for the tool contract and status model.\n\nFile v0.1.6:_meta.json\n\n{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.6\",\n  \"publishedAt\": 1778785833506\n}\n\nFile v0.1.6:references/tool-reference.md\n\n# Tool Reference\r\n\r\n## Exported Tools\r\n\r\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\r\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\r\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\r\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\r\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\r\n\r\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `commitmentHash`, `commitmentURI`, `fundedAtMs`,\n  `proofBundleHash`, `proofBundleURI`, `proofSubmittedAtMs`, `reportHash`,\n  `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\r\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\r\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\r\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\r\n- `PROOF_CAPTURED`: execution proof captured, ready to submit.\r\n- `AWAITING_VERIFICATION`: proof submitted, waiting for verifier.\r\n- `PAID`: task settled, payment released to seller.\r\n- `NOT_PAID_REFUNDED`: task refunded to buyer, no seller payout.\n\nFile v0.1.6:LICENSE.txt\n\nCopyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added.","readmeExcerpt":"Skill: Tyrpay Seller Skill Owner: 10000-c Summary: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement. Tags: latest:0.1.13 Version history: v0.1.13 | 2026-05-15T17:48:53.565Z | auto - Documentation updates in SKILL.md for better clarity and easier onboarding. - No changes to core logic or APIs; workflows and usage remain the same. - I","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\r\nname: tyrpay-seller-skill\r\ndescription: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\r\n---\r\n\r\n# TyrPay Seller Skill\r\n\r\nUse this skill when an agent needs to act as the seller in a TyrPay payment flow.\r\nIt assumes the runtime already has a configured `SellerAgent`, a readable settlement\r\ncontract, and access to the `@tyrpay/seller-skill` tool set.\r\n\r\n## Quick Start\r\n\r\n1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.\r\n2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.\r\n3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.\n4. Call `tyrpay_ready` before the first task workflow.\n5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.\n6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.\n\r\n## When To Use\r\n\r\n- The agent is responsible for accepting and executing TyrPay tasks as a seller.\n- The agent must produce zkTLS-backed proofs of upstream API calls.\n- The agent needs structured task state that is safe to show to an end user.\n- The seller workflow must remain non-blocking and recoverable after network interruptions.\n- When using 0G TeeTLS, the seller can only commit to the actual endpoint and\n  model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a\n  generic upstream endpoint or different model name.\n- When only the model is known, use `tyrpay_discover_model_endpoint` to find a\n  reachable TeeTLS/TeeML endpoint before committing.\n\r\n## Workflow\r\n\r\n1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.\n2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.\n3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.\n4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).\n5. Once funded, call `tyrpay_execute_task` for each required upstream API call.\n6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.\n7. Use `tyrpay_check_settlement` to monitor whether verification released payment.\n\r\n## Tooling Notes\n\n- All tools reject malformed inputs with structured `SellerSkillToolError` errors.\n- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.\n- `verifierSignerAddress` is the registry-authorized verifier signer embedded\n  into `ExecutionCommitment.verifier`; it is not a settlement contract,\n  verifier registry, service URL, or verifier service contract address.\n- The readable settlement contract must expose `getTask(bytes32)` with the\n  current `TyrPaySettlement.Task` field order:\n  `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,\n  `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,\n  `fundedAtMs`, `proofBundleH"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7damjysh059fvz4j4c13qgss86q0dj\",\n  \"slug\": \"tyrpay-seller-skill\",\n  \"version\": \"0.1.13\",\n  \"publishedAt\": 1778867333565\n}"},{"path":"references/tool-reference.md","content":"# Tool Reference\n\n## Exported Tools\n\n- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.\n- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.\n- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.\n- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.\n- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.\n- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.\n\n## Operational Guarantees\n\n- Runtime input validation runs before SDK or on-chain calls.\n- Validation failures surface as `SellerSkillToolError` with stable fields:\n  `code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.\n- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.\n- `ExecutionCommitment.verifier` is the registry-authorized verifier signer\n  address that signs `VerificationReport`; it is not a verifier contract address.\n- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.\n- With provider `\"0g-teetls\"`, the commitment target/model must be the actual\n  0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic\n  upstream endpoint or different model is invalid for TeeTLS execution.\n- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller\n  only has a target model. Its `recommended.host`, `recommended.path`,\n  `recommended.method`, and `recommended.model` are commitment inputs; its\n  `recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.\n- `tyrpay_submit_proof` verifies storage hash integrity after upload.\n\n## Integration Requirements\n\n- The settlement contract ABI must match the current `TyrPaySettlement.Task`\n  struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,\n  `deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,\n  `commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,\n  `proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.\n- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in\n  one process. Production or cross-agent flows need persistent retrievable\n  storage.\n- `commitmentHash` is the canonical hash of the complete\n  `ExecutionCommitment`. It cannot be recomputed from task fields alone.\n- Reclaim proof generation requires runtime installation of optional Reclaim\n  peer dependencies, credentials, and zk resource files.\n\n## Seller-Facing Statuses\n\n- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.\n- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.\n- `READY_TO_EXECUTE`: payment locked, seller can execute the task.\n- `PROOF_CAPTURED`: execu"},{"path":"skill-card.md","content":"## Description:\n\nSeller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[10000-c](https://clawhub.ai/user/10000-c)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agent operators use this skill to run the seller side of a TyrPay task: accepting buyer tasks, executing zkTLS-proven API calls, submitting proof bundles, and monitoring settlement.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Wallet private keys, storage private keys, Reclaim secrets, and model API keys are high-value secrets used by the seller workflow.\n\nMitigation: Keep secrets out of version control and logs, and run the workflow only in an environment intended to sign TyrPay settlement transactions.\n\nRisk: Unpinned or unexpected package names could change the behavior of a payment-signing runtime.\n\nMitigation: Use trusted package names and pinned versions where possible before installing the TyrPay seller packages and optional zkTLS dependencies.\n\nRisk: Local memory storage is not retrievable across buyer and verifier processes in real multi-party flows.\n\nMitigation: Use persistent shared storage such as 0G, IPFS, or HTTP for production or cross-agent workflows.\n\nRisk: Incorrect settlement ABI, verifier signer, endpoint, or model commitment data can cause invalid settlement state or proof submission.\n\nMitigation: Verify the current settlement ABI, use the registry-authorized verifier signer, and commit only to the endpoint and model resolved by the 0G TeeTLS adapter metadata.\n\n## Reference(s):\n\n- [Tool Reference](references/tool-reference.md)\n- [Tyrpay Seller Skill on ClawHub](https://clawhub.ai/10000-c/skills/tyrpay-seller-skill)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Shell commands, Configuration]\n\n**Output Format:** [Markdown guidance with tool names, workflow steps, and configuration tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes seller status names, environment variables, and operational constraints for TyrPay settlement workflows.]\n\n## Skill Version(s):\n\n0.1.13 (source: server release metadata and _meta.json)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."},{"path":"LICENSE.txt","content":"Copyright (c) TyrPay contributors.\r\n\r\nThis skill bundle is packaged from the TyrPay repository.\r\nNo separate license file exists in this package directory at the time of packaging.\r\nApply the repository-level license if and when one is added."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1761,"uniquenessScore":40,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T16:52:29.043Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T16:52:29.043Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:59:47.951Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}