Proof of Delivery

There is nothing to submit. The bot publishes every accepted booking itself, and it records the proof in the same breath: the live link, the message id (every message of an album), the agreed creative frozen as a baseline, and the clocks that govern payment. You never paste a link, never press a "delivered" button, and never need to keep screenshots — the record is built by the platform, at the moment of publication, on every single booking.

How the ad gets published — and removed at the end of the run — is covered in Posting the ad.

Proof is recorded against one booking, identified by its OFO- order id — the reference on the booking card. If you run several placements in a day, that id is how you tell their records apart. See Your Onflow Ads IDs.

What is recorded at publication

In the same transaction that records the post as live:

• The post's own identity — the channel, the message id, and the id of every message in an album, so the monitor and the end-of-run removal always know exactly which messages are the ad.
• The public link to the post, exactly where it landed.
• The agreed creative, frozen as a booked baseline — the booked caption and a manifest of the booked media, hashed and signed into the proof archive. A later dispute is argued against what the ad looked like on day one, not against recollection.
• The delivery clocks — the advertiser's review window, your payout release date, and the removal time for the end of the booked in-feed duration.

Because the bot itself is the publisher, the old failure modes of a pasted link — the wrong message, a private t.me/c/… address, a link the monitor cannot parse — cannot happen. The monitor always knows which message to watch, because it is watching the message the platform published.

What publication sets in motion

Five clocks start the moment the ad is live:

1. The booking moves to Delivered, and the advertiser is asked to verify. Their review window is the ad's promised duration capped at 48 hours. Inside it they can confirm the post — which releases your payout immediately — or raise a concern, which holds it. Letting it lapse counts as delivered.
2. Your payout release date is fixed. It is computed at that moment from your plan's payout schedule and written onto the booking. It never moves afterwards, even if your subscription changes. The card shows it as "Delivered — funds release on …". See Escrow and getting paid.
3. The monitor starts watching the post — that it still exists, unedited, and what it really delivers in views, forwards, reactions and clicks. On a placement that bought the pin extra, the pin is applied in this same step and stays for the whole campaign. See Delivery monitoring and your reliability.
4. The proof archive opens with the frozen baseline described above, and the monitor appends to it as the run goes on.
5. Any retention hold opens its clock, measured from delivery, because what it measures is whether the post survives. See Escrow and getting paid.

A sixth clock starts here too, and it is the one owners forget: the format's opening window, in which nothing else may be published in the channel. Publication is the bot's job; keeping the ad newest in the feed for those hours is yours. See The quiet window you owe.

The end of the run is recorded too

When the booked in-feed duration has fully run, the bot takes a final metrics reading — the last honest sample of views, forwards and reactions — writes it into the delivery report, and then removes the post. The removal is part of the record: the report shows a placement that ran its full window and came down on schedule, which is exactly the shape a payout release wants to see.

The proof archive

The archive is append-only and cryptographically signed. Every row's signature is recomputed from its own stored contents when it is read, so a tampered archive fails on itself rather than being quietly believed.

• The booked row is written once per placement, at publication. A retry that eventually lands keeps one baseline — the creative as booked — rather than minting a second one with drifted contents.
• Monitor rows are appended as the placement runs, each carrying the live caption where it could be read, the sampled counts, and an edited flag driven by Telegram's own edit signal.
• Both parties read the same trail. A dispute is argued over one shared record rather than over screenshots and recollection.

Leave the published post alone

The archive records edits and removals. The bot published the post; the bot will remove it. Editing it, unpinning a paid pin, or deleting it yourself reads as tampering with a placement under contract — early removal is confirmed on two separate checks before anything counts against you, and it is the single most expensive mistake an owner can make. If you believe the ad genuinely must come down early, report the campaign instead — our team can stop it properly, without it counting against you.

What you see of the trail, and how to get the rest

From your side the archive shows up as the badge on the booking and the delivery report on the card. If you need the trail itself for a dispute, ask support with the booking's OFO- — it is already on file and does not depend on you having kept anything.

After publication: what you should see

Card state	Meaning
"Delivered — funds release on [date]"	The ad is live and recorded; the release date was fixed at publication
"Instant payout opens [date]."	Early release becomes available after the advertiser's review window
"Delivery verified — the hold has cleared." with Claim $X payout	Claimable now
"We've flagged a problem with this placement — the payout is paused until it's resolved."	The monitor found the post missing or edited, or a bought pin removed — see Delivery monitoring
"A fraud concern on this booking is under review"	The advertiser raised a concern — see Disputes

If something goes wrong

What happened	What it means	What to do
The window opened but nothing was published	The bot could not post — usually a rights problem	The card and a notification name the cause; restore the bot's admin rights and the next retry lands. See When publishing fails
The post is live but looks wrong to you	The bot publishes exactly what was booked	Compare against the booking card; if the campaign itself is the problem, report it
The post vanished mid-run and you didn't remove it	Telegram-side removal, or someone else with rights	The monitor confirms a removal on two separate checks before anything counts against anyone; a removal we can't attribute goes to a human, not against you
The run ended but the post is still up	The bot's Delete Messages right was taken away	Restore the right; the bot retries the removal and the leftover post is never read as your breach unless you caused the rights loss
You believe the campaign should stop early	Breach of your rules, or of the platform's	Don't touch the post — report the campaign with your evidence and our team can stop it

Related

• Escrow and getting paid — when the money leaves escrow, and how to take it sooner.
• Delivery monitoring and your reliability — what the monitor does with the post the bot published.
• Disputes — the seller's side — what the archive is for.
• Posting the ad — the window, the rights the bot needs, and the automatic removal.