Service Rules · September 10, 2026 · Version 2026-09-10-r11

Service Rules

These rules are the plain-language, end-to-end operating policy for newly accepted Herald bookings. They are incorporated into Herald’s Terms and Payment Policy. Exact deadlines and frozen booking terms shown in the booking workspace control each booking.

Defined roles: A “Client” is a person or organization that requests or purchases Provider Services through Herald. A “Provider” is a person or organization that offers or performs those services. A user may act in either or both roles. This is a non-substantive terminology clarification and does not change any accepted right, obligation, fee, or deadline. Other capitalized terms have the meanings stated in the Terms of Service.

Current checkpoint model

For new services, Herald automatically creates a payment checkpoint every three service days and on the final service day if sooner. The client pays the complete fiat Checkout amount upfront. If project-token compensation is included, its direct token portion is funded checkpoint by checkpoint and must be verified before each corresponding work period begins. Each checkpoint’s value is proportional to the service days it covers. The client may approve immediately; otherwise fiat payment releases 24 hours after proof unless the client reports one specific objective mismatch. Missing proof, missing required token funding, or a valid issue pauses future work.

Impressions, views, engagement, clicks, conversions, sales, revenue, return on investment, price movement, token performance, and similar audience or business outcomes are not guaranteed delivery requirements and cannot be used to hold payment. Legacy funded bookings retain their frozen terms.

1. Design principles

2. Request, agreement and payment

A client request creates no charge. The client chooses immediate activation after payment or a specific future start date. A provider who cannot begin on the requested schedule must propose a later start before accepting. The provider has 24 hours to accept, decline, or propose complete service-specific terms. The client has 24 hours to respond to changed terms and, after acceptance, 24 hours to pay.

At acceptance, Herald freezes the exact work, price, fees, start method, service length, automatic checkpoint schedule, provider timezone, and any project-token chain, token address, FMV snapshot, provider wallet, gross token quantity, and provider-net token quantity for both parties. Acceptance alone creates no charge. The client pays the complete fiat Checkout total upfront. For a fiat-only booking, Stripe confirmation funds the booking and authorizes work immediately unless the parties accepted a future date. For a project-token booking, Stripe confirmation instead opens a 24-hour provisional funding window. Herald must verify the first checkpoint’s exact on-chain token transfer before the booking is funded, the disclosed Herald fee is earned, any work is authorized, or any delivery clock begins. The complete Stripe charge remains refundable during that window; an incomplete initial token transfer causes the booking to be unwound.

3. Checkpoint schedule, counted days, and fees

Bookable services must have at least $25.00 of total service value. The client pays the frozen compensation and no separate Herald client fee. Herald deducts a 10% provider fee from each approved or released checkpoint, so the provider keeps 90% before separate third-party payout, wallet, or network charges on work that is actually paid. Both parties see exact totals before commitment. Herald earns no fee when acceptance happens. Herald earns its 10% fee only on checkpoint value that is approved, released, paid to the provider, or otherwise finally awarded to the provider. If unstarted, undelivered, unreleased, or client-blocked work is refunded under Herald’s rules, the allocated Herald provider fee for that refunded work is also returned except for legally required, payment-network, duplicate, erroneous-payment, fraud, chargeback, or separately incurred third-party cost adjustments. A full refund of unreleased service value pays the provider nothing for that refunded work and returns the refundable Stripe charge for that work. An eligible Solana or BNB Smart Chain project-token portion is valued through Jupiter or DEX Screener, respectively, when the client accepts; that acceptance freezes the gross and provider-net token quantities. Only the project’s own token is eligible for this direct-token flow. Stablecoins, SOL, BNB, wrapped or staked versions, and other general-purpose payment or network assets are excluded. The client sends the fixed 90% net token quantity regardless of later market price and remits the token portion’s 10% fee to Herald in fiat through Checkout.

The provider enters only how many days the service takes. Herald adds checkpoints on Day 3, Day 6, Day 9, and so on, plus the final service day when it comes sooner. A five-day service uses Days 3 and 5. A seven-day service uses Days 3, 6, and 7. Payment at each checkpoint is proportional to the number of service days since the prior checkpoint; cent and base-unit rounding goes to the final checkpoint. The first project-token checkpoint must be verified during the provisional funding window. After a checkpoint is approved or released, the next checkpoint’s project-token portion becomes due and must reach at least 100% of its frozen token quantity before that next work period begins. Until Herald verifies it, the next work period and deadlines remain paused and the provider must wait. Herald automatically scans the applicable chain after the client indicates payment, records matching unique finalized or sufficiently confirmed transaction identifiers, and accumulates multiple transfers for the same checkpoint. An underpayment leaves the checkpoint pending with the exact remainder displayed. The client may submit a transaction identifier if automatic discovery does not find a payment. During provisional token funding the complete Stripe charge is refundable even if Stripe does not return its processing cost to Herald. After activation, Stripe, Connect, conversion, wallet-provider, bank, and blockchain-network fees actually incurred are non-refundable except where law or the responsible third party requires otherwise.

For an immediate multi-day service, both Stripe confirmation and the verified initial token transfer together set the funding time. Confirmation at or before 12:00 noon in the frozen provider timezone makes that date Day 1. Confirmation after noon authorizes work immediately, but the next calendar date becomes Day 1. Checkpoint proof submission opens on the displayed checkpoint date and remains due through the end of that date. Early completion does not move the counted service calendar or later checkpoint dates.

4. Questions and drafts before delivery

There is no separate required client-approval step before work. Providers and clients may use Herald messages to share drafts, ask questions, and confirm details. Messages do not expand the frozen scope or silently change funded deadlines.

5. Client dependencies

If performance requires an agreed client input that has not been supplied, the provider may open one consolidated dependency hold for that delivery before the delivery deadline. Booking timing pauses, and the client has 24 hours to supply it or explain that it cannot be supplied. When the hold ends, eligible upcoming deadlines shift by exactly the documented pause and the provider is not marked late. Later clarification stays in Messages and cannot create another hold or reset the clock. If the client cannot supply it or does not respond, affected unperformed work follows the rule-based refund path and the provider is not marked late.

6. Checkpoint proof

The provider must submit proof by the displayed checkpoint deadline in the frozen provider timezone. Proof may be one or more work URLs, up to six images, a written completion note, or any combination. At least one URL, image, or nonblank note is required. URLs may be added individually, and Herald may normalize a missing HTTPS prefix. The completion time defaults to the current time and cannot predate confirmed payment or the applicable service period.

Herald keeps original and corrected proof versions and their images in the permanent shared history. Booking messages or private agreement do not change a funded deadline. Only a system-recorded hold or binding legal, safety, platform, payment, or administrative correction changes it.

7. Missed proof deadline

If proof is missing at the deadline, future work pauses and Herald automatically opens a 24-hour cure period. Proof submitted during cure enters normal review but is recorded as late cured even if the underlying work occurred on time. The pause remains until review resolves. If proof remains missing when cure expires, the refundable compensation for that delivery returns with the allocated Herald fee and the provider receives a missed outcome.

The client then has 24 hours to continue. Ending the booking or silence follows the same refund rule for every future delivery without valid proof already submitted. Unpaid future token portions are cancelled; tokens already transferred cannot be reversed by Herald. Previously released work remains final.

8. Client acceptance and payment release

After proof is submitted, the client has 24 hours to confirm the delivery was completed as agreed or report an objective mismatch with a frozen deliverable or proof requirement. Acceptance releases eligible fiat payment only after any required project-token transfer is verified for the exact token, chain, wallet, and frozen checkpoint quantity. Client silence automatically releases payment when those requirements are satisfied. General dissatisfaction, changed preferences, lower-than-expected impressions or engagement, conversions, sales, price movement, other audience or business outcomes, and requests for extra work do not stop release.

9. Objective correction path

A valid problem report must identify the unmet frozen requirement and describe the objective mismatch. The provider then has 24 hours to:

If the provider takes no action, the rule-based delivery refund applies. This correction path is not an open-ended revision process and does not permit new scope. If the client believes corrected work still fails the same frozen requirement, the provider cannot submit another correction to restart review; the parties use direct resolution before Herald review is available.

10. Direct resolution before Herald review

A provider disagreement opens a 24-hour direct-resolution window, not an admin case. The booking remains paused while the parties use the retained workspace. The provider may correct or agree to refund; the client may withdraw the report and approve; and the parties may agree to end future work.

Both parties see the same deadline and receive the opening notice plus essential reminders approximately 12 hours and two hours before it ends. Only an unresolved contested issue may escalate to formal Herald review. Both parties then see the case, evidence, deadlines, and final rationale. Formal review remains exceptional; each party generally has five business days to submit evidence.

11. Mutual termination

Either party may propose mutual termination for all remaining unstarted work while the booking is active and unpaused. The proposal is an offer, not a pause: existing work and deadlines continue during the 24-hour response window. Both parties see the reason, exact deliveries, protected value, and response deadline. The other party must affirmatively accept in Herald. If any listed delivery changes before acceptance, the offer expires rather than silently changing scope. A declined or unanswered proposal also expires, changes nothing, and the booking continues under its existing agreement. If accepted, refundable fiat compensation for unstarted deliveries returns without retaining the allocated Herald fee, unpaid future token portions are cancelled, and delivered, approved, released, or already-transferred token portions keep their existing status. A unilateral client cancellation is not available after funding.

12. Continuing publication

Published service content must remain available indefinitely while the provider controls it and continued publication remains lawful, safe, and permitted by the platform. This obligation applies across bookings and is not a minimum live-period payment lock. Payment releases under the normal 24-hour review rule.

If content becomes unavailable, the client may report the frozen URL. The provider has 24 hours to restore it or document one permitted reason: a client instruction, a legal or safety requirement, platform-enforced removal, or loss of account control. The provider must choose the category and record specific facts, dates, and supporting links in the shared booking record. An unexplained controllable removal is recorded as a compliance violation and may lead to warning, suspension, or delisting. It does not ordinarily reopen a completed payment.

13. Reliability and enforcement

Herald keeps system-measured activity separate from subjective user ratings. It retains delivery outcomes including on time, late cured, missed, excused, client blocked, and platform excused. Delivery performance is measured by verified proof-submission time: proof supplied after the displayed deadline remains late even if the provider reports that the underlying work occurred earlier. Client-blocked, excused, and platform-excused outcomes do not reduce the provider’s on-time rate.

To reduce retaliation and small-sample distortion, Herald publishes an on-time percentage only after at least five settled deliveries and always shows its denominator. Late-cured and missed-and-refunded counts remain distinct so clients can understand the difference between a corrected delay and non-delivery.

Herald may also display provider response activity based on append-only request and decision timestamps from the previous 180 days. The typical-response label uses the median provider decision time. An unanswered eligible request counts against the response rate after its frozen 24-hour deadline; a request withdrawn sooner without a provider response is excluded. Public response time and rate appear only after at least five eligible request cycles and include the sample size.

In its sole reasonable discretion and based on available information, Herald may immediately and without prior notice reject or cancel a request, pause eligible payment release, require evidence, restrict features, hold a payout where lawful, hide a listing, suspend, delist, or terminate an account when it believes abuse, fraud, fee avoidance, false proof or transaction evidence, token or wallet misconduct, illegality, sanctions, security, payment, safety, marketplace-integrity risk, or another material or repeated violation may exist. Herald may preserve evidence, recover or offset amounts where permitted, notify affected service providers, and report or cooperate with authorities. When practical and legally permitted, Herald will provide notice after an immediate action and an opportunity to respond, but need not disclose confidential fraud, legal, security, or risk controls. Non-waivable rights and already-earned payment obligations remain protected.

14. Shared booking timeline, notices and records

Both parties receive the same authenticated booking record. Overview keeps the current decision, money summary, and progressively disclosed frozen terms together. Each delivery has a collapsed, append-only proof and approval history with retained files attached to their exact submission version. Messages retain ordinary collaboration and direct-resolution discussion. Timeline shows the requested start, agreement, payment authorization, any partial activation day, counted Day 1 and final service day, delivery periods, timezone, proof and cure deadlines, submission, client review, delivery value, approval, refund, and provider-payment status. For project-token terms it also retains the chain, token address, quote source and time, agreement-time FMV, frozen gross and provider-net quantities, receiving wallet, transaction hash or signature, verification result, and confirmation status. It also retains workflow holds and their exact duration, pre-publication decisions, dependency reports, issue responses, termination proposals, content-compliance outcomes, formal-review evidence and rationale, status transitions, and party or automatic actions.

Herald sends essential money-moving and deadline notices even when optional marketing or activity notices are disabled. Reminders supplement the shared record and do not replace it. Rule-based release and refund jobs are isolated from unrelated maintenance so an optional task cannot block a financial deadline. A payout cannot outrun a valid refund marker, unresolved objective problem, client dependency, or missing required token transfer.

15. Versioning and legacy bookings

These rules govern services accepting Payment Policy version 2026-09-10-r11. A funded service keeps the policy version and commercial terms accepted at funding. Bookings funded under r10, r9, r8, r7, r6, r5, r4, r3, or older policies retain their accepted fees, refund treatment, schedules, proof rules, and response windows; Herald does not retroactively replace them.

16. Contact and governing documents

Read these rules with the Terms of Service, Payment, Refund and Dispute Policy, Provider Marketplace Agreement, and Acceptable Use Policy. Questions may be submitted in the booking workspace or to [email protected].