Tyrpay Seller Skill
ReviewAudited by ClawScan on May 14, 2026.
Overview
The skill matches its TyrPay seller purpose, but it gives an agent wallet, blockchain, storage, and API-execution authority without clearly documented approval or limiting controls.
Install this only if you intentionally want an agent to operate as a TyrPay seller. Configure a dedicated limited wallet, pin and review the external packages, require approval before accepting tasks or submitting transactions, and confirm what proof data will be stored or shared.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent using this skill could commit the seller to tasks, spend transaction gas, call external APIs, and submit proof data based on a task workflow without a clearly documented per-action approval step.
These tools can make external API calls, upload task/proof data, and submit blockchain transactions. The artifacts describe validation, but do not clearly define approval gates, endpoint/task allowlists, gas/spending limits, or rollback boundaries.
`tyrpay_accept_task`: builds execution commitment, uploads it, and submits on-chain. ... `tyrpay_execute_task`: performs a zkTLS-proven API call ... `tyrpay_submit_proof`: assembles receipts into a proof bundle and submits on-chain.
Use this only in a runtime that enforces explicit user approval for accepting tasks, executing non-read-only API calls, and submitting on-chain transactions; add task, buyer, endpoint, method, gas, and value limits.
If configured with a powerful wallet or broad credentials, the agent may be able to perform financially meaningful actions or authenticated proof-generation actions.
The skill requires access to a wallet signer and zkTLS-related credentials. This is purpose-aligned for a payment/proof workflow, but it is sensitive delegated authority.
Construct `SellerAgent` with a signer, settlement address, chain ID, storage adapter, and zkTLS adapter. ... Run `tyrpay_ready` to verify signer access ... `ReclaimZkTlsAdapter` needs ... credentials
Use a dedicated low-balance wallet, narrowly scoped credentials, and runtime policies that prevent unauthorized transactions or credential use.
Installing unreviewed or unpinned dependencies could introduce behavior not visible in this skill bundle.
The instruction-only skill depends on external packages and optional peer dependencies that are not pinned or reviewed in the provided artifacts. This is normal setup for an integration, but users must trust the installed packages.
Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter. ... Install those optional peer dependencies in the runtime that constructs the adapter.
Install dependencies from trusted registries, pin versions, review package provenance, and prefer lockfiles or audited builds.
Task details or API-call proof material may be stored in locations visible to other parties or retrievable later, depending on the storage adapter.
The workflow shares commitments, receipts, and proof bundles across buyer, seller, verifier, and storage systems. This is expected for TyrPay, but the artifacts do not detail access controls, encryption, or retention for those shared objects.
Buyer and verifier processes need persistent shared storage such as 0G, IPFS, or HTTP.
Use storage with appropriate access controls and retention policies, avoid including unnecessary sensitive data in proofs, and confirm what data becomes public or shared before submitting.