Herald FAQ

Work never starts before payment. The clock starts when payment is confirmed or on the agreed future start date, whichever is later. Payment by noon in the provider’s timezone makes that date Day 1. After-noon payment lets the provider begin immediately, but the next date becomes Day 1.

The provider enters the exact work, total price, and how many days the service takes. Herald automatically adds a checkpoint every 3 days and on the last day. A 5-day service has checkpoints on Days 3 and 5. A 7-day service has checkpoints on Days 3, 6, and 7. Each payment is proportional to the service days it covers.

The service clock keeps running during a normal 24-hour checkpoint review. If the client reports a valid specific problem, future work and deadlines pause while that checkpoint is corrected, refunded, or resolved.

Multi-day services use counted calendar days in the provider’s recorded timezone. For an immediate service, activation by noon makes that date Service Day 1. After-noon activation authorizes preparation immediately, but the following date becomes Service Day 1. The workspace displays every checkpoint, proof deadline, client response period, pause, and payment release.

Herald no longer adds a separate required approval step before work. Providers may share drafts or ask questions in booking messages. Payment checkpoint protection still applies to the agreed final work.

There is no separate approval process before work. The provider begins after confirmed payment or the agreed future date and submits proof at each automatic checkpoint. The client can approve a checkpoint immediately or report a specific problem during the 24-hour review.

Proof submission opens on the displayed checkpoint date and remains due through the end of that date. The provider submits at least one of these: a work URL, an image, or a written completion note. Providers can add multiple URLs, upload up to 6 images, and include an optional comment. Early completion does not move later checkpoint dates, and Herald keeps the submitted evidence with the booking.

The client has 24 hours to approve or report an objective mismatch with the accepted terms. Approval releases payment. If the client does not respond by the displayed deadline, Herald automatically approves the delivery and releases payment.

If required proof is missing, Herald opens a final 24-hour cure period. Proof submitted during cure is recorded as late—cured and enters normal review. If proof remains missing, the affected checkpoint is recorded as missed—refunded.

For a multi-day service, future work pauses. After an uncured miss, the client has 24 hours to continue; ending the service or remaining silent refunds eligible future checkpoint payments.

If an agreed client input is missing, the provider may open a documented dependency hold before the deadline. The client has 24 hours to provide the input or explain that it cannot be supplied. A valid hold pauses eligible deadlines. If the input cannot be supplied or the client remains silent, affected unperformed work may be refunded without marking the provider late. Ordinary messages do not automatically extend deadlines.

Herald evaluates whether the provider completed the frozen, accepted deliverables—not whether the service produced the client’s hoped-for business result. An objective problem may include missing work, the wrong account or platform, an incorrect quantity or duration, a missing required element, a material difference from approved content, unverifiable proof, or an inaccessible deliverable. The report must identify the specific accepted requirement that was not met.

Lower-than-expected impressions, views, engagement, clicks, conversions, sales, revenue, return on investment, price movement, token performance, or other audience and business outcomes do not stop payment. Herald’s sitewide policy does not permit providers to guarantee those outcomes. Changed preferences, requests for extra work, and general dissatisfaction without an objective mismatch are also not delivery failures.

Those experiences may still inform an honest final verified review. Payment issues address objective compliance with the accepted delivery requirements.

Yes. The provider has 24 hours to make one objective correction with updated proof, agree to the applicable refund, or contest the report and begin direct resolution. A correction is not an unlimited revision round and cannot expand the original scope. Corrected work receives one new 24-hour client review.

Most situations are resolved through delivery review, one correction, an automatic refund, or direct discussion. If the provider contests the report, the parties receive a 24-hour direct-resolution period. Only an unresolved, genuinely contested issue normally proceeds to formal Herald review, where both parties may submit retained evidence and can see the final rationale and financial outcome.

Not unilaterally. Before payment, either party may withdraw or decline without a charge. After payment, either party may propose mutually ending remaining unstarted work, but the other party must affirmatively accept. A termination proposal does not pause current work or deadlines while it is being considered.

The client pays the complete fiat Checkout amount upfront. Herald divides the service value across automatic checkpoints based on the number of service days each checkpoint covers. If the agreement includes project-token compensation, those tokens move directly to the provider checkpoint by checkpoint rather than being paid in full through Checkout. The client can approve completed work immediately. Otherwise that checkpoint’s fiat payment releases 24 hours after proof unless the client reports a specific problem. Missing proof, missing required token funding, or a valid problem pauses future work.

The parties choose fiat, an eligible Solana or BNB Smart Chain project token, or both. The direct-token option is only for the project’s own token; stablecoins, SOL, BNB, wrapped or staked versions, and other general-purpose payment assets are excluded. A stablecoin offered by Stripe remains a way to pay the USD-denominated fiat portion, not project-token compensation. When the client accepts the final terms, Herald uses current market data to freeze the exact gross and 90% provider-net token quantities. The market price may change later, but the client must send—and the provider agrees to accept—the recorded token quantity at each checkpoint. The first token payment must be verified before the booking starts. After each completed checkpoint, the next token payment must be fully verified before the provider begins the next work period; until then, the schedule pauses and the provider waits. The token moves directly between their wallets and is not held in Herald escrow.

Acceptance alone does not charge a fee. Herald earns its disclosed 10% fee checkpoint by checkpoint, only when work is approved, released, paid to the provider, or finally awarded to the provider. If unreleased work is refunded because it was unstarted, undelivered, mutually terminated, client-blocked, or otherwise refundable under Herald’s rules, the allocated Herald fee for that work is returned too. Previously released work stays paid unless fraud, payment reversal, legal requirement, or an administrative correction applies. Stripe, Connect, currency-conversion, bank, wallet-provider, and blockchain-network fees already incurred may still be non-refundable except where law or the responsible third party requires otherwise.

The authenticated booking workspace shows the accepted scope, payment confirmation, start and checkpoint deadlines, approval submissions, messages, retained files, proof, review periods, corrections, holds, refunds, and payment releases. Emails and notifications are reminders; the exact workspace record controls.

Published service content must remain available while the provider controls it and continued publication remains lawful, safe, and permitted by the platform. If the frozen URL becomes unavailable, the provider has 24 hours to restore it or document a permitted reason. An unexplained controllable removal may affect the provider’s account, but it does not ordinarily reopen a completed payment.