These Terms of Service ("Terms") are a business-to-business agreement between [Company], Business ID [ID], registered at [ADDRESS] ("zkLicensing", "we") and the business or professional registering a software product for licensing on the zkLicensing platform ("Vendor", "you").
These Terms govern: (a) your registration and listing on the zkLicensing directory, (b) deployment of License Contracts through our tooling, (c) use of the Keeper service and SDK, and (d) the protocol royalty. They do not govern sales between you and your buyers: you are the seller of record for every license sold for your products, and the sales contract exists solely between you and the buyer, on your own checkout, under your own terms.
3.1 Registration requires: your legal name, full billing address and country, a contact email, and either (i) an EU VAT identification number, which we validate against VIES and log with a timestamp, or (ii) equivalent evidence of business status for non-EU vendors, or (iii) an explicit declaration that you are not a VAT-registered business, in which case consumer-treatment invoicing applies to our fees.
3.2 You warrant this information is accurate and will keep it current. We review vendor registrations against the EU Consolidated Sanctions List and may refuse or suspend registration where required by law.
3.3 Your legal identity (name, country, and a contact route) will be disclosed on directory listings and must be displayed on your own checkout pages, as required by consumer-protection law. Vendor anonymity is not possible on this platform; buyer pseudonymity is (see the Privacy Policy).
4.1 Deployment fee: a one-time fee in MINA per Instance, payable at deployment. The current amount is published on the Pricing page at zklicensing.com/pricing and is the amount in effect at the moment your deployment transaction is signed. For invoicing and tax purposes the fee's euro value is fixed at the exchange rate recorded at the time of the transaction, and the invoice states that euro amount. Invoiced by [Company] with [JURISDICTION] VAT, EU reverse charge, or out-of-scope treatment according to your Section 3 status. The MINA-denominated fee amount may be revised per Section 4.4 to reflect market conditions; revisions apply to future deployments only.
4.2 Protocol Royalty: 2% of each sale, executed inside the Circuit at the moment of purchase or renewal. Because the split is compiled into the Circuit, it cannot be changed for deployed Instances by either party.
4.3 No subscription. Your obligations are limited to the Registration Fee at deployment (Section 4.1) and the Protocol Royalty on each sale (Section 4.2). The dashboard, online verifier, and data-availability endpoints are provided at no additional charge. Devnet deployments are free.
4.4 Fee schedule changes apply to future deployments only.
5.1 Each Instance is immutable after initialization, with one exception: the tier price schedule may be updated for future purchases. Existing licenses are unaffected. There is no revoke method, no admin key, and no platform override — once a license is issued, neither you nor zkLicensing can cancel it.
5.2 Every purchase is escrowed on-chain for 14 days, during which the buyer holds a unilateral, contract-enforced right to a full refund. Escrow releases to your address (98%) and the Protocol Royalty address (2%) after the window closes. Renewals pay out immediately and are non-refundable provided the waiver in Section 7.3 was validly obtained. Exception: during a pre-hardfork freeze window (Section 8.2), new purchases proceed escrowless under a Section 7.3 waiver, because a 14-day refund window cannot outlive the fork; the Protocol Royalty split still applies at the moment of purchase. In-flight escrows across a freeze: for purchases made before the freeze slot whose 14-day escrow window has not yet closed when the freeze begins, the on-chain escrow is settled early (before fork activation) so that no buyer funds cross the fork. The on-chain refund flow is therefore unavailable for the remainder of that window; any statutory refund rights the buyer holds for the unused portion of the 14 days are handled off-chain by the vendor under Section 7.4.
5.3 A 7-day grace period after expiry allows continuity-preserving renewals. Licenses whose expiry falls inside a hardfork freeze window renew fresh rather than stacked (Section 8.4).
6.1 The Keeper is currently the sole proving service: purchases, renewals, refund proofs, and migrations are constructed through it. We operate it on a commercially reasonable-efforts basis.
6.2 The Keeper is a relay, not an authority: the generation list it serves is signed with
zkLicensing's offline platform key and verified by the SDK against pinned public keys. Freeze
schedule data is currently served unsigned via the Keeper's /health endpoint; the on-chain
freeze gate remains the authoritative enforcement point. Funds are never held or routed by
the Keeper; all value transfer is wallet-to-contract or contract-to-wallet.
6.3 Continuity — wind-down covenant. Upon permanent discontinuation of the platform services, [COMPANY] will release the then-current Circuit, Keeper, and SDK source under the Change License defined in Section 9 within [60] days, and hereby brings forward the Change Date of all versions to the date of discontinuation.
7.1 Checkout disclosures. Your buy, renew, and refund pages must display your legal identity and country before purchase, the net price with applicable VAT shown as a separate line (0 with reverse-charge note for verified cross-border B2B) and the total, the statutory withdrawal information, and must deliver a durable confirmation artifact (downloadable record of the transaction, terms, and any waiver) at completion. The SDK reference components implement this; if you replace them, the obligations remain yours.
7.2 Taxes. You are responsible for VAT/GST registration, remittance, and record retention (up to 10 years under EU OSS rules). Where your jurisdiction requires buyer-country evidence at checkout, you must implement that capture in your own storefront — the platform does not collect it for you.
7.3 Renewal and no-escrow waivers. Where a purchase or renewal relies on the withdrawal waiver (all renewals; freeze-window escrowless purchases), the waiver checkbox must be rendered unticked and enabled, must gate the buy action, must carry the express consent-and-acknowledgment wording provided in the SDK, and its acceptance must be recorded in the durable confirmation. A forced or pre-ticked waiver is invalid, and any resulting statutory refund obligation is yours and is not payable from on-chain escrow.
7.4 Refunds beyond the window. Statutory rights that outlast the 14-day on-chain window (e.g., conformity remedies) are your off-chain responsibility.
7.5 Technical upkeep. You will maintain your /.well-known/zklicensing/<appId>.json file,
update your published contract address after Generation migrations, and ship app updates on a
cadence compatible with Mina protocol hardforks (Section 8.5). You are responsible for the
security of your domain and wallet keys.
7.6 Lawful products only. You warrant that listed software does not infringe third-party rights and complies with applicable law, including export and sanctions rules.
7.7 Trust-anchor badge. You may display the zkLicensing trust-anchor badge (or any
functionally equivalent "trust anchor by zkLicensing" mark) on pages that offer, describe, or
distribute your application only while your live deployment passes the
zklicensing-verify-trust CLI shipped in the SDK — that is, all findings return ok when the
CLI is run against your production origin and the zkApp address of your live-generation
deployment, with the platform manifest public key pinned from the attestation table at
zklicensing.com/trustanchor. Passing the CLI is a
continuing condition: if a chain-side check (verification-key hash, permission locks, zkApp
URI, on-chain existence) or manifest-side check (signature, address-in-generations) starts
failing, you must remove the badge from all vendor-controlled surfaces within a reasonable
period after you knew or ought to have known, and either restore compliance or stop using the
mark. Use of the badge outside these conditions is a directory-rule breach under Section 10.1
and may result in delisting.
8.1 Mina protocol hardforks do not preserve verification of prior verification keys. Each hardfork therefore retires all existing Instances and requires deployment of a successor Generation.
8.2 Ahead of an announced hardfork we publish a freeze schedule declaring the freeze slot and the fork activation slot. From the freeze slot, new renewals are suspended (Section 8.4 explains how expiries that fall inside the window are bridged into the successor Generation), while new purchases switch to escrowless mode under a Section 7.3 waiver — a 14-day refund window cannot outlive the fork, so the buyer expressly waives it and the sale finalizes at purchase. Outstanding pre-freeze escrows are settled by the Keeper before fork activation so that no buyer funds cross the fork; buyers whose 14-day refund window had not yet closed at that point lose the remaining on-chain refund path for that window, and any statutory refund rights that survive fall to the vendor off-chain under Section 7.4 (Section 5.2).
8.3 After redeployment, buyer licenses migrate into the successor Instance free of charge via the contract's migration method, preserving recorded expiry. Migration may be buyer-initiated or performed by the Keeper on buyers' behalf.
8.4 Automatic grace extension across the fork. When a license is migrated to the successor Generation (Section 8.3), if its original expiry fell before the fork activation slot the Circuit automatically bumps that expiry forward to the fork activation slot on the successor. The standard 7-day grace period then runs from fork activation, giving the buyer 7 days after fork activation to renew and preserve continuity — the renewal stacks on the bumped expiry rather than resetting. Buyers whose original expiry was already past fork activation are migrated with expiry unchanged. Buyers who do not renew within the post-fork grace window follow standard reset semantics (Section 5.2). This mechanism ensures no license loses continuity purely because its expiry landed inside a freeze window in which renewals were suspended.
8.5 Disclosure you accept: verifiers embedded in your applications stop accepting current-Generation proofs at each hardfork. Your application update cadence is therefore coupled to Mina's hardfork cadence. This is a property of the underlying protocol, not a defect in the platform.
8.6 Vendor redeployment duty. After a hardfork activates and the successor Generation's redeployment window opens, you must redeploy your Instance to the successor Generation, within a reasonable period, using the vendor-signed redeployment flow in the SDK and dashboard. Redeployment is a wallet-signed on-chain action taken by you as the on-chain vendor; the platform supplies the successor verification key, preflight checks, and tooling, but does not sign the transaction for you except as provided in Section 8.7. You bear the on-chain costs of redeployment: the Mina protocol account-creation fee for the successor zkApp (currently 1 MINA, set by the Mina protocol and not by us) and the Mina network transaction fee. No further platform deployment fee under Section 4.1 is charged on a redeployment. Purchases, renewals, and refunds cannot be processed on-chain until you redeploy. Between activation of the successor protocol and completion of your redeployment, buy, renew, and refund flows are unavailable on your Instance because those flows require a live current-Generation verification key, which the Mina protocol upgrade (and not any action by us) has retired, and which only the redeployed successor carries. Off-chain obligations that survive the gap (for example statutory refund duties under Section 7.4) remain yours. Existing buyers retain their migration rights under Section 8.3 in the meantime. If you do not redeploy within a reasonable period after the window opens, we may suspend new sales and renewals for your Instance in the directory and may delist you under Section 10, without affecting buyers' migration rights under Section 8.3.
8.7 Platform-initiated redeployment for security or integrity. We may — but are not required to — redeploy your Instance on your behalf, using a platform-controlled deployment key, where in our reasonable judgement it is necessary to (a) address a security vulnerability, exploit, or defect in the Circuit or a prior-Generation Instance; (b) preserve the integrity or availability of the on-chain licensing state; or (c) comply with a legal obligation binding on us.
Scope of the platform-controlled key. The platform-controlled deployment key can sign only the redeployment transaction that installs the successor verification key at a new zkApp address; it cannot issue, revoke, or alter licenses, move escrow, change prices, or take any other action, all of which remain Circuit-enforced consistent with Section 5.1. Ownership and payouts are preserved: the successor Instance is initialized with your vendor address (read from the retired Instance's on-chain state), so escrow releases continue to route to your wallet in the split defined by Section 4.2. A redeployment under this Section 8.7 uses the same generation-chain migration mechanism as Section 8.3; recorded buyer expiries are preserved.
Costs and notice. Where we initiate a redeployment under this Section 8.7, we bear the Mina protocol account-creation fee and the Mina network transaction fee for that redeployment. We will notify you by email at the vendor contact address on file, using commercially reasonable efforts to do so in advance, unless prior notice would in our reasonable judgement materially prejudice the remediation or the interests of buyers, in which case we will notify you promptly after the fact.
No assumption of seller obligations. A redeployment under this Section 8.7 does not make us the seller of record for your product; you remain responsible for buyer communications, refunds, tax reporting, and post-migration support for the resulting successor Instance.
The Circuit is proprietary; its integrity is evidenced by the published verification-key attestation table rather than by source availability. The SDK, reference components, and deployment tooling are licensed under the Business Source License 1.1 with an Additional Use Grant permitting production use to license your own products (as seller of record), and prohibiting operation of a competing licensing marketplace or licensing-as-a-service offering; each version converts to Apache 2.0 on its published change date. The full license text governs; this paragraph is a summary.
10.1 Prohibited: name-squatting, impersonation of third-party products, malware, and unlawful content. We operate a notice-and-action process consistent with the EU Digital Services Act; listings may be suspended or removed on substantiated notice.
10.2 Effect of delisting or termination: we may remove your listing and refuse Keeper service for new operations. We cannot and will not revoke licenses already issued — issued licenses continue to verify per Section 5.1. You remain responsible to existing buyers.
Our processing of your registration data is described in the Privacy Policy at [URL]. The platform does not capture buyer-country or other buyer-side evidence on your behalf; where you collect such data through your own checkout, you are the controller. For royalty accounting we act as an independent controller.
12.1 We warrant that published verification-key hashes correspond to the Circuit identified in the attestation table. All other services and software are provided "as is." We do not warrant uninterrupted Keeper availability, Mina network performance, block inclusion times, MINA exchange rates, or the conduct of buyers.
12.2 You acknowledge blockchain-inherent risks: hardforks, protocol changes, wallet key loss (unrecoverable by anyone), transaction fees, and token volatility. Permanent unavailability of the Mina protocol itself is addressed separately in §13.4 (Protocol sunset); zkLicensing does not assume responsibility for the unused portion of a license term in that scenario.
12.3 To the maximum extent permitted by law, neither party is liable for indirect or consequential damages, and our aggregate liability is capped at the fees you paid us in the 12 months preceding the claim. Nothing limits liability for willful misconduct, gross negligence, or liability that cannot be limited under applicable law.
13.1 These Terms apply from acceptance until terminated by either party on 30 days' notice, or immediately for material breach. Sections 5, 7.4, 10.2, 11 and 12 survive.
13.2 We may amend these Terms with 30 days' notice by email and dashboard notice; material changes require re-acceptance at next login. Each version is identified by number and document hash.
13.3 Vendor sunset (voluntary or forced deactivation of a listing).
(a) A vendor who wishes to stop offering an app must give buyers at least 30 days' prior notice by (i) marking the listing as sunsetting in the vendor dashboard, which publishes a banner on the app's marketplace page, and (ii) emailing every buyer whose invoice email is on file. During the notice period the listing remains visible as "sunsetting" and buyers may continue to renew, refund (within their statutory 14-day window), or migrate their license.
(b) At the end of the notice period the listing is deactivated: new purchases and renewals are blocked, but already-issued licenses remain valid on-chain for the full term the buyer paid for — the smart contract cannot be revoked by the vendor and continues to answer verify calls (see §7). A Perpetual (1000-year) license issued before sunset is therefore unaffected by the sunset itself.
(c) No refund is owed at sunset for the unused portion of the term. Buyers paid for a fixed-term license that is fully preserved on-chain; the withdrawal of the vendor's ongoing support, updates, or hosted resources does not reopen the 14-day statutory refund window, which has already expired. Vendors may voluntarily offer pro-rata refunds via the standard refund flow, but are not required to.
(d) 30 days after deactivation (i.e., 60 days after the initial buyer notice), the vendor's account data is purged in line with the Privacy Notice §5. Financial and accounting records subject to statutory retention (Privacy Notice §3.1) are kept for the periods required by law and are not affected by the purge. On-chain data (transactions, license issuance, refund events) is public and permanent and cannot be erased by anyone (see §5, §12.2).
(e) We may deactivate a listing on shorter notice — or immediately — where required by law, regulator order, sanctions, court order, or in response to a material breach of these Terms. In that case we will notify affected buyers as soon as reasonably practicable and (where the breach is on the vendor's side) apply the same no-refund rule in §13.3(c) to the vendor account; buyers retain any rights they have under mandatory consumer-protection law.
13.4 Protocol sunset (Mina network unavailability).
(a) The Circuit runs on the Mina blockchain. If the Mina protocol becomes permanently unavailable — for example the network is shut down, all producing nodes cease operation, or an incompatible protocol change is deployed for which no successor Generation of the Circuit can be published — on-chain verification of licenses stops functioning and no migration path exists. This is a systemic risk of the underlying protocol, distinct from the vendor-side sunset in §13.3.
(b) We do not warrant Mina network availability or continuity (see §12.1 and §12.2), and zkLicensing does not assume responsibility for the unused portion of any license term affected by permanent protocol unavailability. No refund is owed by zkLicensing or by vendors when a license cannot be verified because the underlying protocol is no longer operating; the risk was accepted at purchase as a blockchain-inherent risk (§12.2).
(c) Where we become aware of a Mina protocol shutdown or an incompatible change with no successor Generation, we will publish notice on the platform and, where feasible, contact vendors and buyers whose contact details are on file. Publishing such notice does not create any refund or replacement obligation.
(d) On-chain data issued before a protocol sunset (transactions, license issuance events) remains whatever the underlying chain preserves — we cannot restore access to it after the protocol ceases to operate.
13.5 These Terms are governed by the laws of [JURISDICTION], excluding conflict-of-law rules. Disputes are settled in the District Court of [VENUE], without prejudice to mandatory venue rules.
Acceptance is recorded with your vendor account: Terms version, document hash, timestamp, and the acting registrant.