Offering Satsignal inside your product.
The one-page rider for platforms, agent runtimes, and tools that want to anchor proofs for their customers through Satsignal — who may do it, in which mode, under whose name, and what flows down to your end customers.
DRAFT v0.1 — prepared 2026-06-11, pending counsel review. This rider is a complete working draft published so prospective platform partners can see the intended structure before counsel finalizes it. It has not been reviewed by counsel, is not yet offered for signature, and may change. Embedding and resale today are arranged by direct written agreement: hello@satsignal.cloud.
Paid or signed design-partner customers only.
Embedding Satsignal anchoring in a product you offer to others, and reselling anchoring capacity, are rights granted only to customers on a paid plan or under a signed design-partner agreement. The free tier is for your own evaluation and internal use — it carries no right to embed, resell, or otherwise offer anchoring to third parties.
For qualifying customers, the grant is: a non-exclusive,
non-transferable right, during your agreement’s term, to
call the Satsignal API from your product to create proofs for
your end customers and to deliver the resulting
.mbnt bundles and verification links to them.
Verification needs no grant at all — anyone may verify any
bundle, free, forever.
You must make the resulting .mbnt bundle reasonably
available to your end customer — not only a hosted verification
link — so they can preserve and verify the proof independently if
your product or Satsignal is unavailable. The downloaded bundle is the
durable artifact; a link alone is not.
Your end customers’ fingerprints stay non-enumerable.
Embedded anchoring under this rider is limited to Sealed mode unless a signed agreement expressly permits Standard-mode embedding. The reason is your end customers’ privacy, and it is structural: a Standard proof is deliberately hash-discoverable — anyone holding the same payload (or its SHA-256) can confirm a matching proof exists via the public lookup. That is the right default when you anchor your own material knowingly; it is the wrong default to impose silently on a third party’s data. A Sealed anchor is a salted commitment: it is not resolvable through the public lookup and exposes no value an observer can test candidate payloads against, so embedding Sealed keeps your end customers’ fingerprints non-enumerable by design.
Default: “proofs by Satsignal”. White-label by addendum.
Default (attribution). Embedded surfaces that show a proof to an end customer carry a “proofs by Satsignal” attribution with a link to the verifier or to satsignal.cloud, and you may use the Satsignal name solely for that attribution, accurately and per section 05.
White-label (by written addendum). Removing attribution
— presenting anchoring under your own brand only — is
available by a written white-label addendum to a design-partner
agreement. Even white-labeled, two things never disappear: the
.mbnt bundle format stays the open, documented
format (so your end customers can verify independently), and you
may not misstate who operates the anchoring infrastructure when
an end customer or auditor asks.
One level deep.
The grant covers your product serving your end customers. It does not include the right to sublicense embedding or resale onward — your end customers and downstream partners do not acquire the right to embed or resell Satsignal anchoring through you. A downstream platform that wants to embed becomes a Satsignal customer under its own agreement. You also may not share, pool, or proxy your API keys outside your own product; each embedding customer holds its own keys and its own quota.
Accurate, nominative, revocable.
“Satsignal” and the Satsignal mark belong to Satsignal LLC. Under this rider you may use them only to truthfully identify the service (the section 03 attribution, factual statements in your docs), following any brand guidelines we publish. You may not use the mark in your own product name, company name, or domain, imply endorsement or partnership beyond what your agreement says, or use the mark on surfaces that misstate what a proof establishes (terms, section 02). Trademark permission ends with the agreement; already-delivered bundles keep verifying regardless, because verification never needed the mark.
What your terms must tell your customers.
Your end-customer terms must carry the substance of these items downstream:
- Scope of a proof — tamper-evidence and timing, not authorship or fact (terms, section 02); your product may not present proofs as more than that.
- Permanence — anchors are written to a public chain — permanent for as long as that chain operates — and cannot be deleted by you, Satsignal, or the end customer (terms, section 05).
- Acceptable use — restrictions at least as protective as terms, section 08, applied to what your end customers anchor.
- Data handling — if your end customers’ personal data is involved, your privacy terms must reflect the flows in the DPA; a signed DPA between you and Satsignal covers our processing on your behalf.
- Disclaimers and liability — warranty disclaimers and liability limits in favor of Satsignal at least as protective as terms, sections 10–11, extended to Satsignal as the upstream provider.
Per agreement.
Wholesale and platform pricing — volume tiers, invoice terms, and any committed capacity — are set per agreement: hello@satsignal.cloud. Public plan pricing is on the pricing page; the design-partner track there is the entry point for embedding conversations today.