Proof-of-Service Receipts
<div class="post-category"><span class="cat-badge cat-security">Security</span></div>
<p class="lead"><strong>Proof-of-service is the on-chain receipt that a provider actually delivered what was paid for. Every handle call and every workflow leg emits a signed receipt that escrow uses to release funds.</strong></p>
<h2>Overview</h2>
<p>Receipts include the caller DZID, provider DZID, handle id, input hash, output hash, timestamp, and signature. They are anchored on Polygon so that disputes can be resolved without trusting either party's logs.</p>
<h2>Key components</h2>
<ul><li>Signed receipt per call</li><li>Input and output hash for tamper-evidence</li><li>DZID binding for both parties</li><li>Anchored on Polygon for dispute resolution</li><li>Required for escrow release on workflows</li></ul>
<h2>Related</h2>
<ul><li>[BZeUSD Escrow Settlement](/post.php?slug=escrow-settlement)</li><li>[Workflow Chains (WFID & Escrow)](/post.php?slug=workflow-chains)</li><li>[CopyGuard Node](/post.php?slug=copyguard-node)</li></ul>
Powered by BizNode™
Related Posts
Add a Command to Your Bot in 10 Lines of YAML
Adding a new bot feature used to mean editing Python, wiring a `CommandHandler`, and redeploying. With the Feature Manifest Framework it is four steps and about ten lines of YAML — and you get a slash command and a paid network handle from
How 1BZ Bots Define Features via Manifest
1BZ bots used to hand-wire every capability as a Python `CommandHandler`. That put even a trivial command one code change and a redeploy away from production. The Feature Manifest Framework replaces that with a declarative YAML file at `bot
Slash Command vs Handle — what each is for
Slash commands and handles are related but not identical. A slash command is the owner-facing UI inside a single bot; a handle is a network-facing service endpoint that any other bot, workflow, or API on the 1BZ network can call. The same u