← All legal documents

Earned Tier Program Rules

Last Updated: October 1, 2026

These Program Rules describe how the Earnesty earned tier works in practice: what a post must contain to earn, what Earnesty checks, what a Claim is worth and when, what is not allowed, and what happens when a rule is broken. They are operational rules, and they are binding. They are incorporated by reference into both the Earnesty Terms of Service, which governs the software products that run an earned tier, and the Participation Agreement, which governs the people who post. Where a rule here conflicts with marketing copy, in-product help text, or campaign material, this document controls.

Know Reply Inc. (“Know Reply”, “we”, “us”) operates Earnesty. We are a technology provider: we verify posts against mechanical checks and relay reward instructions. The APP is the advertiser of record for its own product.

1. Purpose and Who These Rules Bind

What this document is for. The earned tier rewards a disclosed act — posting publicly about a product, in your own words, with a disclosure the reader can see. The APP grants its own Reward; Earnesty verifies the post and relays the instruction. That sentence carries obligations under the FTC Endorsement Guides (16 CFR Part 255) and the FTC’s Rule on the Use of Consumer Reviews and Testimonials (16 CFR Part 465). These Rules are how those obligations are met in the mechanic itself rather than in a policy nobody reads.

Who is bound.

Defined terms used throughout.

What these Rules do not do. They do not make the APP’s claims about its own product true, and they do not substitute for an APP’s or a USER’s own legal obligations. Earnesty verifies the participation and disclosure requirements it is configured to check. It supports compliance; it does not guarantee it.

2. Disclosure Requirements

Disclosure is mandatory. A post without it does not qualify, whatever else it contains. A qualifying post carries the disclosure in its text (§2.1), placed as §2.2 says. The platform’s own paid-partnership label, where the Supported Platform has one, is not required for now; we record it and encourage it (§2.4).

2.1 The disclosure

The disclosure is a plain line: a phrase and the APP’s handle. Ad - @Acme. It says the post is advertising and names the advertiser, in words a reader does not have to decode. It is not a hashtag. The phrase is ours, not the APP’s and not the USER’s: nobody types one, so the governed shape cannot be typed around. The handle is the APP’s own handle on the Supported Platform. The approved phrase and the exact APP handle must both appear in the post, but do not need to be adjacent or in the same sentence. Placement rules apply to the phrase.

Why this form. A legal review of the markets an earned tier reaches (September 2026) replaced the branded hashtag these Rules used to require. The FTC treats a hashtag as optional and asks only that a reader understand the connection; a brand-linked form such as #XYZ_Partner has support in FTC staff guidance for the United States and does not carry further. Other markets name the word they expect — “Ad” in the United Kingdom, Werbung in Germany, Publicité or Collaboration commerciale in France — and a plain line naming the advertiser is understood in all of them. These Rules previously explained that “Partner” was chosen over “Ad” because posts that earn include criticism and bug reports. That reasoning is withdrawn: a post rewarded by the advertiser is advertising for the purposes of disclosure whatever it says, and the reader is owed the plain word.

The words follow the language of the post. A disclosure a reader cannot read is not a disclosure. For every language an APP enables we designate the phrase — the plain advertising word that market’s own rules name — and the disclosure is that phrase and the APP’s handle: Werbung - @Acme for a post in German. An APP chooses which languages it enables; it never chooses the words. The current phrases are published in the product and carry a policy version, which is recorded with every verified post.

The USER chooses the disclosure language. The rewards page lets the USER select an APP-enabled language appropriate for the post they intend to write. The USER is responsible for choosing words their readers can understand. Verification checks for a complete approved Disclosure in an enabled language; it does not infer the post’s language or reject it because the platform reports a different language. Quoted text, mixed-language writing and an unknown platform language do not create a language-mismatch failure. A USER may include more than one approved disclosure, but mixing languages does not automatically require two. We record the language of the Disclosure that passed, separately from any platform-reported language metadata.

Matching forgives presentation and nothing else. Case, line breaks, runs of spaces, and the separator before the handle (-, –, —, : or none) do not matter: ad: @acme is Ad - @Acme. We check the complete approved phrase and the exact APP handle independently. The phrase must meet the Market’s placement rule; the handle can appear elsewhere in the post’s own text. A reply addressee alone does not satisfy the handle requirement. Bad @Acme has no approved phrase, and Ad - @AcmeCorp has the wrong handle.

2.2 Where the disclosure goes: the APP’s market

The APP declares where it promotes: Global, or one region. Global is the default. The market decides one thing — where in the post the disclosure must sit — by one rule with two values:

Global requires the disclosure at the start, which is the strictest rule and so is right in every market. A region uses the rule for that region: anywhere for the United States, Canada, Brazil, the Netherlands and Japan; at the start for the United Kingdom, Germany, France, Spain, Italy, Portugal and South Korea. Where a region names its own phrase for posts in its own language — Sponsored by @Acme in the United States — that phrase is used; the language’s plain advertising word always qualifies as well, placed the same way, because it is the stronger of the two.

“Anywhere” is not measured. We do not test whether a disclosure late in a long post falls behind the platform’s “Show more”. A USER cannot tell where the platform will cut a post, and a rule they cannot check before posting would refuse posts that did what was asked. An APP that wants the stricter reading chooses Global.

A post is judged under the market in force when it was made. A USER posts first and asks for the check afterwards. If an APP changes its market in between, the post is held to the market it was written under.

We make placement hard to get wrong. The USER’s rewards page shows the disclosure for their language and offers a control that opens the platform’s own composer with it already in place, first in the post. Nothing is posted on a USER’s behalf.

2.3 The Claim Code

The first post a USER makes for an APP must also carry their Claim Code (#earnesty_7K4PXM). That post binds the USER’s account to their public handle, which is how every later post is recognized without asking anyone to authorize an app. The Claim Code is identity, not disclosure, and may sit anywhere in the post. After binding it is no longer required and no longer appears in the suggested text; it stays visible on the USER’s rewards page. Posting it again is never a condition of earning — its one later use is binding an additional account (§7).

2.4 The platform paid-partnership label

Several Supported Platforms offer a native paid-partnership label — on X, the Paid Partnership setting on the post. Where the platform has one that we can read:

TikTok’s commercial content setting is the creator’s obligation. TikTok’s Branded Content Policy requires its in-app commercial content disclosure setting on a post made for a reward. No TikTok interface lets us read that setting, so we do not check it and it is not a condition of a Reward. The USER instructions tell the USER to turn it on, and doing so is the USER’s obligation under TikTok’s policy. The Disclosure in the caption is required either way.

2.5 Category limits

Some platforms prohibit paid-partnership content in specific categories. X prohibits it for financial products and services (including crypto, lending, buy-now-pay-later, and investment services) and for gambling. APPs in those categories cannot run an earned tier on X compliantly, and are screened at onboarding.

2.6 Worked examples

The platform label does not change any of these results (§2.4). The first five are for an APP whose market is Global.

Compliant. Disclosure first, USER’s own words after it:

Ad - @acme reconciled three months of invoices in one pass this morning. The CSV importer guessed my column names correctly, which I did not expect.

Compliant — first post, carrying the Claim Code:

Ad - @acme #earnesty_7K4PXM been using this for two weeks for client billing. Setup took about ten minutes.

Compliant — critical. This earns exactly what the two posts above earn:

Ad - @acme the importer is good but the mobile app is rough — filters reset every time I background it. Two months of asking. Fix the filters.

Compliant — comparative. Also earns identically:

Ad - @acme switched from Bettersheet after their price change. Acme’s exports are worse, the reconciliation is better. Net win for me, might not be for you.

Compliant — a post in German, for an APP that enabled German:

Werbung - @acme der Import errät meine Spaltennamen endlich richtig.

Not compliant under Global — the disclosure is not first. The same post qualifies for an APP whose market is the United States:

Spent the weekend rebuilding my whole billing workflow, and the reconciliation step finally takes minutes instead of an afternoon. Sponsored by @acme

Not compliant — the retired hashtag. It is not a disclosure under these Rules any more:

@acme #Acme_Partner this importer finally guesses my column names right.

Not compliant — no disclosure. Naming the product says nothing about the reward:

@acme is doing something right with this importer.

Compliant — the phrase and handle can be separate. The phrase is upfront and the exact APP handle appears in the post:

Ad — Having fun using @acme. Look what I built! @EarnestyRewards

Not compliant — denying the commercial relationship. A disclosure must not be contradicted by the post:

Not an ad, I just like it. Thanks @acme.

Not compliant — vague or ironic disclosure. Coined vocabulary, ambiguous stems, and jokes that undercut the literal statement all fail:

@acme #earnedtier #sponsoredmaybe great importer.

3. Sentiment Neutrality

The rule. No reward under these Rules may be conditioned, in whole or in part, on a post expressing any particular sentiment about an APP or its product. This applies to base Claim value, to the performance bonus, to Drop and Milestone rewards and bonus tokens, and to discretionary rewards.

Earnesty does not evaluate sentiment. Verification checks presence, identity, and uniqueness. It checks nothing else. There is no tone model in the loop and no human review of content as a condition of earning. Nothing about a post’s content affects whether it qualifies, what it earns, or your eligibility. The insight we give an APP about how its product is discussed, including sentiment, and any display or curation features, never feed back into Verification, valuation, or eligibility.

Critical, comparative, and mixed posts earn identically. A post that criticizes the APP, compares it unfavorably to a competitor, documents a bug, or lands somewhere in the middle earns precisely what a positive post of the same type earns, at the same value, under the same schedule. There is no positive-post premium and no negative-post penalty. Nothing in the mechanic can express one, because the value is computed before anything about the post’s content beyond disclosure is known.

What APPs may not do. An APP must not, whether through Earnesty or outside it:

Why the rule has this shape. 16 CFR Part 465 prohibits, among other things, providing compensation conditioned expressly or by implication on a review or testimonial expressing a particular sentiment. A program that pays for praise cannot be cured by disclosing that it pays for praise. So the program does not pay for praise: it pays for a disclosed act, evaluated mechanically, with critique explicitly and equally in scope. Bug reports, comparisons, and complaints are not tolerated exceptions in this system — they are ordinary Qualifying Posts, and their presence in the feed is part of the evidence that the rule is real.

Enforcement. We may suspend an APP that conditions rewards on sentiment, directs content, instructs USERs to omit the Disclosure, or discourages USERs from using the platform label (§2.4). That is enforcement of these Rules, not editorial control over what anyone says.

3.1 Display and Curation

Separately from earning, we may offer an APP optional features that display verified posts on the APP’s own surfaces — an embed, a quote wall, a selection of posts to feature. Those are display features, and two rules govern them.

4. No Rewards for Commercial Outcomes

The rule. No reward under these Rules may be conditioned on a signup, an install, an activation, a conversion, a subscription, a sale, revenue, or any other commercial outcome for the APP. The bounded bonus in Section 6 may depend on the public performance of the USER’s own post; it never depends on customer acquisition or revenue.

No engagement purchase. Earnesty does not buy, sell, broker, or guarantee reach, followers, impressions, likes, reposts, reviews, or ratings. The performance bonus in Section 6 is a bounded, one-time settlement on a post that already qualified, paid to its author for how their own post performed; it is not a purchase of engagement, and nobody is ever paid to like, reply to, repost or follow anything. It is a rank against the APP’s other recent posts rather than a rate per interaction, it never exceeds the maximum the APP sets, it needs a minimum of reported views, and it is settled once. Buying or manufacturing engagement on one’s own post is prohibited conduct under Section 8.

Measurement is separate from payment. An APP may measure whether the earned tier works. It may ask new signups where they heard about the product, accept a Claim Code at signup to attribute a signup to a post, and join its own activation and retention data to Earnesty’s enrollment records to compare cohorts. All of that is measurement, and it is invisible to USERs by design, so it cannot shape what anyone posts. Measurement never changes what a post earns.

Attribution is measured, never paid on. A Claim Code entered at signup may support attribution, but entering it, referring a customer, or producing a signup or sale earns no referral reward for either person. No reward may be paid for recruiting another poster or for the posts or referrals of anyone recruited. A campaign may reward a qualifying post during a defined window under Section 9; that is a posting reward, not a referral reward.

No per-post causality claims. We do not tell an APP that a specific post produced a specific customer, and an APP must not tell a USER that it did, or make rewards appear to follow from it.

5. Verification

Verification is the complete and definitive set of checks between a public post and a reward. It is mechanical, it is the same for every post and every APP, and nothing outside this list affects whether a post qualifies.

5.1 The checks

A post qualifies if, and only if, all of the following hold:

  1. Public and retrievable. The post is publicly visible and can be retrieved from the Supported Platform’s public API at the time of checking.
  2. Carries an approved Disclosure. A complete phrase in an APP-enabled language, chosen by the USER for their intended post, appears with the APP’s handle (§2.1). We check the phrase and handle, not a guessed or platform-detected language. The phrase must meet the Market’s placement rule, and the exact APP handle must appear in the post’s own text. These are separate checks; adjacency is not required.
  3. Carries it where the APP’s Market asks. At the start of the post, or anywhere in it, under the Market in force when the post was made (§2.2).
  4. The author is identified. Either the posting account is already bound to a USER of this APP, or the post carries that USER’s Claim Code — required only on their first qualifying post — which creates that binding. One platform handle binds to at most one USER per APP.
  5. The post has not been credited before. The platform’s post identifier has never been credited, for any USER, for any APP, ever.
  6. The USER is eligible to earn. The applicable cooldown has elapsed; a USER who has never been credited may earn on their first Qualifying Post. Drops and Milestones are outside the recurring cooldown as Section 9 describes.
  7. The USER is enrolled with the APP. Registration is free and unlimited; there are no paid seats or enrollment waitlists. New acceptance also requires an active offer, available funding, and remaining allowance under any applicable USER reward limit.

Never checked for reward decisions: sentiment, writing quality, or follower count. Public engagement counts are used only for the bounded performance bonus in Section 6, not as a condition for the base posting Reward. The platform’s paid-partnership label is read and recorded when a post is verified, and is not one of the checks (§2.4).

5.2 One post, one credit, once

A platform post identifier credits exactly once, ever. This is enforced by a uniqueness constraint in our database, not by a policy or a review step. Re-submitting a post, submitting it to a second APP, editing it, or having it re-observed by our poller cannot produce a second grant.

5.3 Valuation at post timestamp

A post’s base Reward and performance-bonus terms are taken from the terms in force at the post’s own timestamp, not the time we check it. That fixes the applicable rate, not a right to acceptance: posting does not reserve funding or a Drop place. New acceptance still depends on the offer being active, available funding, and the applicable eligibility and reward limits. Once accepted, the work is paid for and is delivered and reviewed despite later billing changes. The settlement review is due a set period after the post’s timestamp (Section 6), and a TikTok post has none; the public counts used for a bonus are those available when the review runs, not a historical reconstruction of counts at an exact instant.

Every post is verified the same way, for every APP. There are no plans, so there is no better or faster check to buy: a post that is found is verified identically, every USER can ask us to look for their own posts, and we also look on our own, once a day, for posts a USER forgot to check (§5.6). An APP’s funding decides one thing only — whether a new post can be accepted (§6) — and never what has already been accepted, which is delivered and reviewed regardless. An integrity hold under Section 8.1 can pause eligibility and new grants while we review — that is an integrity control, never a billing or an editorial one.

5.4 What causes a post to fail Verification

A post does not qualify when: it is not public or cannot be retrieved; the Disclosure is missing; the Disclosure is not at the start of the post where the APP’s Market requires that; the author cannot be identified and no Claim Code is present; the posting handle is already bound to a different USER of that APP; the post identifier was already credited; the USER’s cooldown has not yet elapsed; the APP has suspended the USER’s earning (§7). Configuration gaps on the APP’s side — no handle configured — also prevent qualification, and are reported as the APP’s issue, never as the USER’s mistake.

5.5 Failing Verification is not a penalty

Most posts we observe were never trying to earn. A post that does not qualify is reported with a reason and nothing else happens: nothing is consumed, no strike is recorded, no eligibility changes, and the USER can post again immediately. Fixing the post — adding the Disclosure, moving it to the start — and checking again is a normal path, not an appeal. Settlement has its own later check, with its own consequence — see §6: a post that is gone, or has lost its Disclosure, at the settlement review earns no bonus and has its base grant revoked. A TikTok post has no settlement review, so this never applies to one.

5.6 Discovery

We find posts when a USER asks us to: by the USER’s own “check now” button, which searches the Supported Platform for that USER’s posts, and by a paste-the-URL fallback that works on every platform (and is the only path on TikTok, where a post is checked once, when it is submitted). On YouTube a USER does not sign in to YouTube: their channel is connected by their first qualifying video, which carries their Claim Code in its description, and after that we look at the channel’s new public videos when the USER asks us to check for them. Instagram and Threads posts that mention the brand are credited automatically. The APP connects its own Instagram or Threads account once, and the platform then sends us each public post that mentions that account. A post that carries the Disclosure and comes from an account connected to a USER, or carries the USER’s Claim Code (which connects the account), is credited within minutes with nothing for the USER to do; pasting the post’s link remains a fallback. A mention from anyone who is not a USER, or without the Disclosure, is discarded and nothing about it is kept. A USER never signs in to Instagram or Threads. We also look once a day, for each USER, for posts that name the APP, so a USER who posted and never checked is still found while the APP’s Wallet can cover it. Asking later does not change the applicable rate, but can affect acceptance if an offer stops, funding runs out, or a Drop closes or fills. A URL lookup remains subject to platform availability. Discovery method never affects valuation.

6. Claim Mechanics

Nothing is issued in advance. A Claim is not an object a USER receives, holds, or is given — it is the standing entitlement to earn a Reward on a Qualifying Post, present automatically from enrollment. There is no minting, no slot to fill, and no moment at which “a Claim opens”: the entitlement is simply there, from enrollment onward, subject to the cooldown, active offer, funding and applicable reward limits below.

What a post earns. A Qualifying Post earns the value the APP has in force at the post’s own timestamp — one flat number, the same whether the post is the USER’s first or fiftieth. There is no curve, no floor, and no trajectory. It is not the value in force when we happen to check the post, so how long Verification takes never changes it, and a USER loses nothing by waiting: there is no rate that falls the longer they hold off, and no deadline that makes waiting costly.

Rates and acceptance are separate. A later rate change never reprices a post: if accepted, it uses the terms in force when posted. Publication alone does not commit funding or guarantee acceptance. Pausing or stopping an offer or program, or insufficient funding, can prevent acceptance of a post that has already been published but not yet accepted. Accepted Rewards and their settlement reviews continue under their original terms. Drops and timely requests at scheduled closing follow Section 9; explicit cancellation stops unaccepted requests, including queued ones.

Cooldown. The APP sets a cooldown in days: the minimum spacing between credited posts. A USER may earn again once that many days have passed since their last credited post — measured against the cooldown that governed that post, never the APP’s current dial, so lengthening the cooldown never retroactively extends a wait a USER is already serving. A USER who has never been credited may earn on their first Qualifying Post. Nothing else has to happen first — no report from the APP, no action by the USER, and in particular no requirement that the USER have used what they already earned. Earning again is a matter of time passing, not of anything being minted or reopened.

Posts per month follow from the cooldown. The cooldown is the only limit on how often a USER can earn, and the most credited posts one USER can make in a rolling 30-day period follows from it arithmetically: posts must be at least the cooldown apart, and the window is measured back exactly 30 days, so a 7-day cooldown allows five and a 10-day cooldown allows three. Only credited posts are counted — a post that fails Verification is never counted. The APP’s status page and configuration screen both state that number rather than leaving the arithmetic to anyone.

There was previously a second, separately configured cap on posts per month. It has been removed. Two limits on the same behaviour could disagree, and when they did, whichever was tighter governed without either surface saying so. Removing it can only ever allow a USER more, never less: no post that would have earned under the old pair fails to earn now.

A post either qualifies or it does not; we never accept one and then decline to pay it. A post made before the cooldown has elapsed simply does not earn, because the timing check in Section 5.1 was not yet satisfied, the same as any other check on that list. The same is true when the APP cannot cover a new post: an APP pays Earnesty for each post we accept, and a post cannot be accepted while the APP cannot cover it. In both cases the USER’s rewards page says so before they post — the date they can earn again, or that the APP’s rewards are paused — but the page is a current status, not a reservation: funding or offer availability may change before acceptance. What we have accepted is always paid for already, and is delivered and reviewed whatever happens to the APP’s funding afterwards.

No expiring Claim. Nothing is issued that could lapse. A USER returning after months may post under the terms then in force, subject to the offer, funding, cooldown and reward limits. This does not extend a Drop window, preserve an old rate, reserve funding, or guarantee that an offer remains available.

An APP may limit what one USER can earn in total. Separately from the cooldown, an APP may set a lifetime limit per USER on a kind of Reward. When a USER reaches it, further posts do not earn that kind of Reward, a grant or a later bonus is reduced to whatever remains, and the USER’s rewards page says the limit has been reached. Offers paying a different kind of Reward are unaffected. The limit is forward-only: it never reduces or reverses anything already credited.

Reporting stays honest when the cooldown changes. The status page reports what a USER was actually credited in the last 30 days and the date their next post can earn. It does not report a monthly quota, because there is none: the most a USER could earn in 30 days is a figure derived for the APP’s own budgeting, and showing it to a USER would read as an entitlement they cannot always reach. Lengthening the cooldown never rewrites history — a USER who posted five times under a 7-day cooldown still shows those five credited posts after the cooldown is set to 30 days. Posts already credited are never clawed back, reduced, or reversed because the cooldown later changed.

The performance bonus: one review, a set period after the post. Where the APP offers one, a Qualifying Post on X, YouTube or Instagram can earn a second, additional grant for how it performed. It is decided once, at a single settlement review a set period after the post’s own timestamp, not after Verification. On X that period is five days. On YouTube and Instagram it is a set number of days we publish for each platform, five unless we announce a longer period, because a video keeps gathering views for longer than an X post; the period that applies to a post is fixed when it is verified. There is no daily accrual and no running total: we read the post once, we settle, and the post is finished. The review is run by a scheduled sweep, so it lands within a day of the due time rather than at a precise instant.

Why a review period. The review provides a defined period for the post to remain public and disclosed and for its performance to develop. Settlement reads the post itself; it does not search for replying accounts. The review is subject to platform availability and ordinary retries.

What is measured: the public counts on the USER’s own post. On X: views, likes, replies, reposts, quotes and bookmarks. On YouTube: views, likes and comments. On Instagram: likes and comments, because Instagram reports no view count. Each is taken as the platform reports it at the review. They are counted, never read: a critical reply counts exactly as a favorable one does, and no reply’s content, tone or author is an input. We never read who replied to, liked or reposted a post — no account but the USER’s own is looked at. A post needs at least ten reported views and one interaction to be ranked at all; on Instagram, at least ten likes and one comment.

TikTok: the base Reward only, checked once. A TikTok post earns the base Reward only. There is no performance bonus on TikTok until the bonus read from the brand’s own TikTok account is live. A TikTok post is checked once, when it is submitted, and its base Reward is final when that check passes: there is no later review, and a TikTok post’s grant is never revoked for what happens to the post afterwards.

Threads: the base Reward only. A Threads post earns the base Reward only: Threads reports no counts we can read on a USER’s post, so there is nothing to rank, and an offer that pays only a performance bonus pays nothing on Threads. A Threads post is still checked again at its settlement review, a set number of days after it goes up, and is revoked if it is gone or has lost its Disclosure, as on X.

How the amount is set: a rank, not a rate. The post’s counts are ranked against the APP’s other posts on the same platform reviewed in the previous thirty days, and the band it lands in pays a share of the performance maximum the APP set, at the terms in force at the post’s own timestamp: below the fortieth percentile, nothing; from there to the seventieth, a quarter; from there to the ninetieth, half; the top tenth, the whole maximum. It never exceeds the maximum, and it is reduced to whatever remains of any lifetime limit. An APP may set a performance maximum with no base Reward at all. A bonus, once paid, is final: later posts are ranked against a later window and never re-rank an earlier one.

It measures post performance, never opinion or commercial outcomes. It is not a payment for engagement: nobody is paid to like, reply to, repost or follow anything, and a USER who buys or fakes engagement on their own post commits the fraud Section 8 prohibits, and what the post earned may be reversed. It never depends on sentiment, conversions, signups or sales.

Still public, still disclosed, at settlement. On X, YouTube, Instagram and Threads, at the moment we settle, the post must still be public and must still carry the Disclosure it qualified under, in the place it qualified under. We judge this against what the post qualified under, recorded when it was verified — never against the APP’s Market or handle as they stand later, so a change by the APP cannot revoke a USER’s post. The platform label is not part of this check, and turning it off revokes nothing (§2.4). If the post or the Disclosure is gone, there is no performance bonus — and the base grant is revoked, because the reward was earned under a disclosure that no longer exists. A revocation is recorded, reported to the APP with the grant’s own reference, and shown to the USER on their status page. It is final for that post: restoring it afterwards changes nothing, and the USER’s next qualifying post earns normally. Whether value already delivered inside the APP’s product is recovered is the APP’s decision — Earnesty never debits an APP’s systems.

Granted as the APP’s own Reward. The bonus is granted by the APP, in the same form as the base grant, and is subject to every rule in these Rules that governs the base grant — including sentiment neutrality in Section 3 and the outcome-based reward prohibition in Section 4.

7. Eligibility and Account Integrity

7.1 Employees, contractors, and insiders

This is a specific concern under 16 CFR Part 465, which reaches reviews and testimonials written by insiders, and under the FTC Endorsement Guides, which treat an employment relationship as a material connection a reader would want to know about.

8. Prohibited Conduct

The following are prohibited for USERs and, where applicable, for APPs that arrange, encourage, or tolerate them:

8.1 Consequences

Enforcement follows a ladder, applied to conduct and never to sentiment:

  1. The post fails Verification. The ordinary outcome. No credit, no penalty, and the USER can post again immediately.
  2. Eligibility is delayed pending review. Where signals suggest manufactured activity — unusual posting velocity, cross-APP reuse, a briefly-public post, engagement patterns inconsistent with the account — eligibility and new grants may be held while we review. We tell the USER that a hold is in place.
  3. Participation ends. For serious or repeated violations, we may end a USER’s participation in an APP’s earned tier, or across Earnesty. A Reward already granted and delivered to the USER is the APP’s to manage under the APP’s own terms.

For APPs, the ladder runs from notice, to suspension of new grants, to termination under the Earnesty Terms of Service. In every case, posts already credited and settlement reviews not yet reached settle on the terms in force when they were made.

Never for sentiment. No step of this ladder may be triggered, at an APP’s request or on our own initiative, by what a post said about a product. If you believe an action was taken against you because of the content of a post, write to us at the address in Section 12 and we will review it.

9. Drops, Milestones and Campaigns

A Drop is a bounded campaign an APP may run on top of the ordinary mechanic: a time-boxed entry in the rate a Qualifying Post can earn — a larger value, a campaign window, an optionally different credited act — matched against a post the same way the standing rate is: at the post’s own timestamp, from what is in the post. Nothing is issued or transformed in a USER’s account; a Drop is simply active or it is not, and a post made while it is active earns its terms.

Bounded by definition. Every Drop has exactly one configuration, one window, one audience, and one reward rule, all fixed and published before the Drop opens, and it cannot be changed once it has. A Drop is either limited to a published number of rewarded places or open to a defined group of USERs for its window. A USER can earn a given Drop once.

A Drop is funded like every other offer. The APP pays Earnesty for each Drop post when we accept it, from the same funding as its other offers. A Drop may publish a number of places, the most posts it will reward; a Drop without one rewards every eligible USER once before it closes. Nothing is set aside for them in advance, and adding USERs to a Drop raises that number without setting anything aside. Publishing a Drop does not commit funding: while the APP cannot cover a new post, the Drop is paused like the APP’s other offers, the USER’s rewards page shows it as not currently available, and a Drop may therefore not run to its published end.

A Drop post is outside the cooldown. A Drop pays Qualifying Posts on X, YouTube, TikTok, Instagram and Threads, and on each of them a Drop post neither waits for the USER’s cooldown nor restarts it. A post that carries a Drop’s campaign tag and does not meet the Drop — the window, the requirements, a place, or because the USER has already earned it — is not refused for that: it is judged as an ordinary post, and the USER’s rewards page says which Drop it missed and why.

Places go in the order requests reach us. A USER posts first and then asks us to check. Where places are limited they are allocated in the order those requests arrived, with a fixed tie-break — never by which check happened to finish first. The post must have been made before the request. A check that finds nothing holds no place for a later post, and a repeated request changes nothing. The number of places shown as remaining is information, not a reservation for the person looking at it.

The closing time is the cut-off for asking. A request made before a Drop’s published closing time is still resolved after it, and keeps the place it needs until it is; like any request, it is accepted only if the APP can cover it at that time. An APP may cancel a Drop early: that stops requests not yet accepted, including queued ones, and what was already accepted stands. We also look once a day for posts a USER forgot to check, and that can award remaining places only while the Drop is open and after earlier requests.

Milestones are once-per-USER firsts. An APP may offer a Milestone: a Reward a USER can earn once, for a post that carries the Milestone’s campaign tag, or — for the welcome — for the USER’s first Qualifying Post. A Milestone post is outside the cooldown in the same way a Drop post is, carries the same Disclosure, and is subject to every rule here. Milestones are earned on X posts only. A Milestone is paid from the APP’s ordinary funding, like a Drop, so it is on offer only while the APP can cover it, and the rewards page says when it is not.

The credited act is objective. Where a Drop credits something other than an ordinary post, it is an act our systems can observe without interpretation — most commonly a quote-post of the APP’s campaign anchor post, verified by the quoted post’s identifier.

Requirements are act-shaped. A Drop or a Milestone may require the presence of specified elements — its campaign tag always, and optionally a quote of the APP’s anchor post or attached media. These are presence checks. They are never sentiment-shaped, never interpreted, and never a required script. A campaign tag sits beside the Disclosure and never replaces it.

Campaign rules never override the baseline. No Drop, and no campaign material, may relax or replace the disclosure requirements in Section 2 or the sentiment neutrality rule in Section 3, and no Drop may attach a reward to an outcome under Section 4. A Drop can change what a post is worth and when. It cannot change what a post must contain, and it cannot change the fact that criticism earns identically.

No paying for engagement on the APP’s own post. Drops credit standalone posts on the USER’s own timeline. Rewards are never paid for likes, replies, or engagement on the APP’s own posts — a like cannot carry a disclosure, and paying for engagement on your own content is platform manipulation under most Supported Platform policies.

No public leaderboards, ever. We do not publish rankings of USERs, and an APP may not require or arrange one as part of a Drop. An APP can see its own top posters privately; competitive ranking as a public surface turns posting into a contest, and public competitive ranking is outside this program. The private ranking used for the performance bonus is permitted.

Spot rewards — discretionary, after the fact, with no promise made in advance — are permitted, subject to Sections 3 and 4. A discretionary reward may never be presented, before a post, as something a favorable post might earn.

10. Record-Keeping

What we retain as compliance evidence. For every verified post: the platform post identifier, the public URL, the post timestamp, the verification result and reason, the granted value, the rate in force at the post’s timestamp, the observed state of the platform paid-partnership label, the applied Disclosure, Market, language, placement and policy version, and correction requests. For every USER: enrollment state and timestamp, the platform binding (platform, author identifier, public handle, and the post that created the binding), earning history, and Reward-grant records. Across the Service: an audit log of configuration changes, campaign configurations, and enforcement actions — suspensions, reinstatements, and revocations included.

Post content and engagement metrics track the platform. Post text is checked against the Supported Platform at settlement, and the post’s public engagement counts are read there at the settlement review: on X six counts, on YouTube views, likes and comments, and on Instagram likes and comments; all of it is removed when the source post is deleted or stops being public, as Supported Platform developer agreements require. What we keep after that is the minimal settlement record — post identifier, timestamp, granted value, rate applied, verification result — needed to evidence a completed transaction and to satisfy disclosure-compliance record-keeping.

How long. Compliance records are retained for Retention: five years from the date the reward is granted. Account data is retained for the life of the account. Full detail, including the controller and processor split, is in the Privacy Policy.

Compliance reports for APPs. An APP may obtain a compliance report for its own earned tier, covering the verified posts in a period, the disclosure state of each (the Disclosure it passed under, its Market, language, placement and policy version, and the platform label as observed), verification failures by reason, enforcement actions taken, and the Drop configurations active during the period. Reports cover the APP’s own program only. Request one at the address in Section 12.

11. Changes to These Rules

We may update these Rules. We will post the updated version with a new Last Updated date and, for material changes, notify APPs by email and USERs on their status page before the change takes effect.

Never retroactive. A change to these Rules does not reach posts already credited, Drop windows already open, or settlement reviews not yet reached. Those settle on the rate in force when the post was made, under the Rules as they read at that time. A change can alter what happens next; it can never unwind a promise already made.

Continuing to participate. For APPs, continued use of the Service after a change takes effect constitutes acceptance, as provided in the Earnesty Terms of Service. For USERs, continued posting to earn after a change takes effect constitutes acceptance; a USER who does not agree can stop posting, and Rewards already delivered are unaffected.

12. Contact Us

Questions about these Program Rules, a verification result, an enforcement action, or a compliance report: hello@earnesty.app.

To report prohibited conduct, use the same address with the subject line “Program Rules Report”, and include the post URLs and any supporting detail you have. We investigate every report.

Data and privacy requests: privacy@earnesty.app.

Schedule A — Supported Platforms

The Supported Platforms, with the discovery methods available on each and the native disclosure label each offers, are listed at Supported Platforms. That list is incorporated into these Rules by reference and is the controlling version.

We update it as platforms are added or removed. Adding or removing a platform is not a change to these Rules and does not affect posts already credited or windows already open.