What makes Tyrpay Seller Skill notable?

1K downloads. Trust evidence available

How should Tyrpay Seller Skill be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Tyrpay Seller Skill

Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.0k

Updated

Oct 11, 2026

Version

0.1.13

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.1.13release · observed May 15, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s179y7my1af239v2k8a8qcad7x86px7g:tyrpay-seller-skill

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: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-10000-c-tyrpay-seller-skill/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

67,134 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: tyrpay-seller-skill
description: Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.
---

# TyrPay Seller Skill

Use this skill when an agent needs to act as the seller in a TyrPay payment flow.
It assumes the runtime already has a configured `SellerAgent`, a readable settlement
contract, and access to the `@tyrpay/seller-skill` tool set.

## Quick Start

1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.
2. Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter.
3. Register `createSellerTools({ agent, contract, verifierSignerAddress })` with your tool-calling runtime.
4. Call `tyrpay_ready` before the first task workflow.
5. For 0G TeeTLS/TeeML work, call `tyrpay_discover_model_endpoint` with the target model.
6. Use `tyrpay_accept_task` when you receive a `taskId` from a buyer.

## When To Use

- The agent is responsible for accepting and executing TyrPay tasks as a seller.
- The agent must produce zkTLS-backed proofs of upstream API calls.
- The agent needs structured task state that is safe to show to an end user.
- The seller workflow must remain non-blocking and recoverable after network interruptions.
- When using 0G TeeTLS, the seller can only commit to the actual endpoint and
model resolved by the 0G TeeTLS adapter/service metadata. Do not commit to a
generic upstream endpoint or different model name.
- When only the model is known, use `tyrpay_discover_model_endpoint` to find a
reachable TeeTLS/TeeML endpoint before committing.

## Workflow

1. Run `tyrpay_ready` to verify signer access and storage adapter connectivity.
2. For 0G TeeTLS/TeeML, call `tyrpay_discover_model_endpoint` and keep the recommended endpoint.
3. When a buyer shares a `taskId`, call `tyrpay_accept_task` with your execution terms.
4. Wait for the buyer to fund the task (poll with `tyrpay_check_settlement`).
5. Once funded, call `tyrpay_execute_task` for each required upstream API call.
6. Collect the returned receipts and call `tyrpay_submit_proof` with the full set.
7. Use `tyrpay_check_settlement` to monitor whether verification released payment.

## Tooling Notes

- All tools reject malformed inputs with structured `SellerSkillToolError` errors.
- `tyrpay_accept_task` reads the on-chain task to derive buyer and verifier addresses.
- `verifierSignerAddress` is the registry-authorized verifier signer embedded
into `ExecutionCommitment.verifier`; it is not a settlement contract,
verifier registry, service URL, or verifier service contract address.
- The readable settlement contract must expose `getTask(bytes32)` with the
current `TyrPaySettlement.Task` field order:
`taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`, `deadlineMs`,
`requiredMinUsage`, `requiredModelsHash`, `commitmentHash`, `commitmentURI`,
`fundedAtMs`, `proofBundleH

_meta.json

{
  "ownerId": "kn7damjysh059fvz4j4c13qgss86q0dj",
  "slug": "tyrpay-seller-skill",
  "version": "0.1.13",
  "publishedAt": 1778867333565
}

references/tool-reference.md

# Tool Reference

## Exported Tools

- `tyrpay_ready`: checks seller signer reachability and storage adapter configuration.
- `tyrpay_discover_model_endpoint`: given a model, discovers matching reachable TeeTLS/TeeML endpoints and returns host/path/model/providerOptions for the seller workflow.
- `tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain.
- `tyrpay_execute_task`: performs a zkTLS-proven API call and returns a delivery receipt.
- `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.
- `tyrpay_check_settlement`: returns raw protocol status and seller-facing payout status.

## Operational Guarantees

- Runtime input validation runs before SDK or on-chain calls.
- Validation failures surface as `SellerSkillToolError` with stable fields:
`code`, `message`, `field`, `received`, `suggestion`, `retryable`, `causeName`.
- `tyrpay_accept_task` reads the on-chain task record to validate task existence before submission.
- `ExecutionCommitment.verifier` is the registry-authorized verifier signer
address that signs `VerificationReport`; it is not a verifier contract address.
- `tyrpay_execute_task` validates that `request.host`, `request.path`, and `request.method` match the commitment target.
- With provider `"0g-teetls"`, the commitment target/model must be the actual
0G TeeTLS endpoint/model resolved by the adapter. A commitment to a generic
upstream endpoint or different model is invalid for TeeTLS execution.
- Use `tyrpay_discover_model_endpoint` before accepting a task when the seller
only has a target model. Its `recommended.host`, `recommended.path`,
`recommended.method`, and `recommended.model` are commitment inputs; its
`recommended.providerOptions` should be forwarded to `tyrpay_execute_task`.
- `tyrpay_submit_proof` verifies storage hash integrity after upload.

## Integration Requirements

- The settlement contract ABI must match the current `TyrPaySettlement.Task`
struct order: `taskId`, `taskNonce`, `buyer`, `seller`, `token`, `amount`,
`deadlineMs`, `requiredMinUsage`, `requiredModelsHash`, `commitmentHash`,
`commitmentURI`, `fundedAtMs`, `proofBundleHash`, `proofBundleURI`,
`proofSubmittedAtMs`, `reportHash`, `settledAtMs`, `refundedAtMs`, `status`.
- `MemoryStorageAdapter` and `memory://` URIs are valid only for local tests in
one process. Production or cross-agent flows need persistent retrievable
storage.
- `commitmentHash` is the canonical hash of the complete
`ExecutionCommitment`. It cannot be recomputed from task fields alone.
- Reclaim proof generation requires runtime installation of optional Reclaim
peer dependencies, credentials, and zk resource files.

## Seller-Facing Statuses

- `READY_TO_ACCEPT`: buyer created the task, waiting for seller commitment.
- `WAITING_FOR_BUYER_FUNDING`: commitment submitted, waiting for buyer to lock payment.
- `READY_TO_EXECUTE`: payment locked, seller can execute the task.
- `PROOF_CAPTURED`: execu

skill-card.md

## Description:

Seller-side TyrPay workflow for LLM agents. Accept tasks, execute zkTLS-proven API calls, submit proof bundles, and monitor settlement.

This skill is ready for commercial/non-commercial use.

## Publisher:

[10000-c](https://clawhub.ai/user/10000-c)

### License/Terms of Use:

MIT-0

## Use Case:

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

### Deployment Geography for Use:

Global

## Known Risks and Mitigations:

Risk: Wallet private keys, storage private keys, Reclaim secrets, and model API keys are high-value secrets used by the seller workflow.

Mitigation: Keep secrets out of version control and logs, and run the workflow only in an environment intended to sign TyrPay settlement transactions.

Risk: Unpinned or unexpected package names could change the behavior of a payment-signing runtime.

Mitigation: Use trusted package names and pinned versions where possible before installing the TyrPay seller packages and optional zkTLS dependencies.

Risk: Local memory storage is not retrievable across buyer and verifier processes in real multi-party flows.

Mitigation: Use persistent shared storage such as 0G, IPFS, or HTTP for production or cross-agent workflows.

Risk: Incorrect settlement ABI, verifier signer, endpoint, or model commitment data can cause invalid settlement state or proof submission.

Mitigation: 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.

## Reference(s):

- [Tool Reference](references/tool-reference.md)
- [Tyrpay Seller Skill on ClawHub](https://clawhub.ai/10000-c/skills/tyrpay-seller-skill)

## Skill Output:

**Output Type(s):** [Guidance, Shell commands, Configuration]

**Output Format:** [Markdown guidance with tool names, workflow steps, and configuration tables]

**Output Parameters:** [1D]

**Other Properties Related to Output:** [Includes seller status names, environment variables, and operational constraints for TyrPay settlement workflows.]

## Skill Version(s):

0.1.13 (source: server release metadata and _meta.json)

## Ethical Considerations:

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

LICENSE.txt

Copyright (c) TyrPay contributors.

This skill bundle is packaged from the TyrPay repository.
No separate license file exists in this package directory at the time of packaging.
Apply the repository-level license if and when one is added.

Github ReposUpdated 2d agoRank 70

AionUi

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!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

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

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.