Earned Tier Program Rules

Last Updated: September 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.

APPs — software products that run an earned tier using Earnesty. An APP is bound by these Rules through its Earnesty Terms of Service, including for the configuration it chooses, the campaigns it runs, and the instructions it gives its own users.
USERs — end users of an APP who post to earn. A USER is bound by these Rules through the Participation Agreement they accept when they enroll.
Know Reply — we are bound to run verification as described here, to apply it the same way for every post, and to value every Qualifying Post at the rate in force when it was posted.

Defined terms used throughout.

APP — a software product running an earned tier on Earnesty; Know Reply’s paying customer. In USER-facing surfaces the APP is called by its own name.
USER — an end user of an APP who earns a Reward by posting.
Reward — whatever an APP grants its USER for a Qualifying Post, in the APP’s own product. Rewards take whatever form the APP chooses — usage credits, model tokens, seats or licences, entry to a Drop, a bonus month — and an APP may offer more than one form. Earnesty never issues, holds, or transfers a Reward, and never pays money to a USER. A Reward has no cash value, is not redeemable for money, and is not transferable between USERs.
Credits — the most common form of Reward, and the one most of these Rules’ examples use: an APP’s own in-product usage currency, issued by the APP. “Credits” is an example of a Reward, never a limit on what a Reward may be.
Claim — a USER’s standing entitlement to earn a Reward on a Qualifying Post, present automatically from enrollment and gated only by the cooldown (Section 6). Nothing is issued, held, or minted: a Claim describes an entitlement, not an object a USER receives.
Claim Code — a short permanent per-USER string of the form #earnesty_7K4PXM, assigned once at enrollment. It is an identifier and a lookup key, never a disclosure and never a security credential.
Partner Tag — the required disclosure hashtag, of the form #{Brand}_Partner (for example, #Acme_Partner) for a post in English, and of the form #{Brand}_{Term} for a post in another language, where the Term is the word we designate for that language (Section 2.1).
Qualifying Post — a public post on a Supported Platform that passes Verification and earns a reward.
Verification — the mechanical checks in Section 5.
Drop — a bounded campaign an APP may run (Section 9).
Supported Platform — a platform listed at Supported Platforms; see Schedule A.

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.

2.1 The Partner Tag

The required form is #{Brand}_Partner. Each APP is assigned one Partner Tag built from its real brand name plus the relationship term “Partner” — #Acme_Partner for a product called Acme. The tag shape is governed by us: a real brand name and an approved relationship term, never an opaque code, never a coined word, never a tag that only names the product.

Why this form. The FTC’s endorsement FAQ treats a bare relationship tag like #partner or #ambassador as ambiguous and confusing, and says a branded form such as #XYZ_Partner “will likely be more understandable” to readers. We chose the form the FTC’s own guidance discusses rather than inventing one. We use “Partner” rather than “Ad” because posts that earn include bug reports, comparisons, workflow notes, and criticism — content that a reader would not recognize as an advertisement, and that “Ad” would describe inaccurately.

Placement: the check is binary. The Partner Tag has to be in the post. That is the whole test — present or absent, matched case-insensitively. We do not judge where in the post it sits, and a tagged post is never failed or flagged over placement.

This is a deliberate position, not an oversight. A disclosure either exists or it does not, and #{Brand}_Partner names the brand and states the relationship wherever it appears — it does not need surrounding text to be understood, which is exactly why the branded form was chosen over a bare #ad. Posts on these platforms are short; rules about halves and thirds of a post measure nothing real about whether a reader saw the tag.

We still suggest putting it where people will see it. That advice belongs in the copy help we give a USER, not in a machine check that can cost them a reward.

Matching is case-insensitive and exact otherwise. #acme_partner and #Acme_Partner are the same tag. #AcmePartner, #Acme_Partners, and #Acme_Ambassador are not.

The tag is in the language of the post. A disclosure a reader cannot read is not a disclosure, so the relationship term depends on the language the post is written in. “Partner” is the term for a post in English. For every other language an APP enables, we designate the term — the word that market’s own disclosure rules name, reviewed by counsel — and the tag is built from the same brand name and that word: #Acme_Werbung for a post in German, for example. Where a market requires a plain-words statement as well as a word in a hashtag, we designate that statement too, and the post must carry it. An APP chooses which languages it enables; it never chooses the words.

Which language a post is in is decided by the Supported Platform. We read the language the platform detected for the post and require the tag for that language. A post the platform cannot place in any language qualifies with the tag for any language the APP enables. A post in a language the APP has not enabled does not qualify, and that is reported as the APP’s configuration gap, never as the USER’s mistake. A post that mixes two languages may carry both tags; carrying a tag for a language the post is not in is never held against it.

2.2 The @mention

The post must also @mention the APP’s handle on the Supported Platform. The mention identifies the product to readers, notifies the APP so it can reply in the thread, and gives us a stable, non-editorial way to find the post. The Partner Tag names the relationship; the mention names the product. Both are required.

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. After binding, the Claim Code is no longer required and no longer appears in the suggested copy string; it stays visible on the USER’s status 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 Content Disclosure toggle in the composer. Where it exists:

We ask USERs to turn it on. Platform policy on compensated organic posts is separate from, and additional to, FTC obligations. In-kind value counts as compensation for these policies, in whatever form a Reward takes.
We observe it, we record it, and we nudge. The label’s state is stored on the verification record and surfaced to the APP as evidence of platform-policy monitoring. When it is off, the USER is prompted to add it — on X it can be applied to a post retroactively.
We never gate on it. Label eligibility is not universal, an unset label is ambiguous between “toggle off” and “account not eligible”, and a label can flip on after our first check. Gating would fail small accounts for something outside their control. The Partner Tag in the text carries the load.
A platform label never replaces the Partner Tag. Labels can be removed, can render differently across surfaces, and disappear in syndication.

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

Compliant. Tag present, mention present, USER’s own words:

@acme #Acme_Partner 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:

@acme #Acme_Partner #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:

@acme #Acme_Partner 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:

@acme #Acme_Partner 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. The tag is at the end, in among other hashtags. It is still a disclosure, it still names the brand and the relationship, and this post verifies and earns like any other:

Spent the weekend rebuilding my whole billing workflow and I have thoughts about every tool I tried, but the short version is that the reconciliation step finally takes minutes instead of an afternoon. #buildinpublic #saas #invoicing #acme_partner

Not compliant — no relationship disclosed. A product-name tag is not a disclosure:

@acme #Acme is doing something right with this importer.

Not compliant — no mention. The product is not identified in a form we or a reader can resolve:

#Acme_Partner this importer finally guesses my column names right.

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 reply bonus, to Drop rewards and bonus tokens, to referral windows, 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. Where we offer optional display or curation features, those 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:

Direct the content. No required scripts, mandated talking points, approved-message lists, or copy the USER must reproduce. Suggested copy exists to help with the blank page and is always optional except for the Partner Tag, the @mention, and (on the first post) the Claim Code.
Gate on tone. No reward, bonus, multiplier, eligibility decision, or Drop invitation may turn on whether a post was favorable.
Solicit reviews or testimonials in exchange for rewards. Earned tier rewards are for posting, not for reviewing. An APP must not present the mechanic to its users as a paid review or testimonial program.
Retaliate. An APP must not ask us to withhold a reward, unenroll a USER, or reduce a USER’s Claim because of the content of a post. We will not act on such a request, and making one is a breach of the Earnesty Terms of Service.
Shape the reward menu around sentiment. Where an APP defines campaign acts, those acts must be act-shaped (“post about how you use it”) and never sentiment-shaped (“share why you love 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, or instructs USERs to omit the Partner Tag. 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.

Display never reaches back into the mechanic. What is displayed, featured, ordered, or left out has no effect on whether a post qualifies, what it earns, what its reply bonus settles at, or a USER’s eligibility. Valuation is complete before any display decision exists, and no display signal is an input to Verification.
A curated display must not misrepresent the overall body of posts. A selection shown as though it were the whole must not be a wall of favorable rewarded posts assembled while the critical, comparative, and mixed posts this program rewards identically are kept out of view. A curated display must be identifiable as a selection, must not select on sentiment, and must not be arranged so that a reader would take it for the full picture.

4. No Outcome-Based Rewards

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 performance outcome. Rewards attach to acts.

No engagement purchase. Earnesty does not buy, sell, broker, or guarantee reach, followers, impressions, likes, reposts, reviews, or ratings. The reply bonus in Section 6 is a bounded, one-time settlement on a post that already qualified; it is not a purchase of engagement. It is counted in distinct replying accounts rather than raw replies, paid on a curve that saturates at a maximum the APP sets, and settled once — so it rewards a post that started a conversation, never volume anyone could buy or manufacture.

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.

Where a referral window rewards, it rewards a bounded act. An APP may choose to run measurement with no rewards attached at all. If it attaches a reward:

The reward must be for a bounded act — entering a valid Claim Code at signup, or posting during a defined window — at a fixed, capped amount stated in advance.
The reward must not be a per-signup, per-conversion, or per-revenue payment, or scale with the number or value of outcomes attributed.
Depth is capped at one level, always. No reward may ever be paid for recruiting another poster, or for the posts or referrals of anyone recruited. Rewards for recruitment are prohibited outright, without exception and without an APP-configurable override.
The reward is granted inside the APP’s own product only — Credits, or whatever other form that APP’s Reward takes — never money.

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:

Public and retrievable. The post is publicly visible and can be retrieved from the Supported Platform’s public API at the time of checking.
Mentions the APP. The post contains an @mention of the APP’s configured handle on that platform.
Carries the Partner Tag, in the post’s language. The APP’s Partner Tag for the language the platform detected the post in is present, matched case-insensitively. Where it sits does not matter (§2).
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.
The post has not been credited before. The platform’s post identifier has never been credited, for any USER, for any APP, ever.
The USER is eligible to earn. The cooldown, measured from the USER’s last credited post (or since enrollment, if they have never been credited), has elapsed.
The USER is enrolled, not waitlisted — and held their enrollment place before the post was made. A post made while waitlisted never qualifies: not on promotion, not retroactively.

Never checked, at any point, for any purpose connected to payment: sentiment, quality, writing, engagement level, follower count, or the platform paid-partnership label.

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 Qualifying Post is valued as of the post’s own timestamp, at the rate the APP had in force at that moment — never as of the time we happened to check it, and never at a rate set before or after. A post’s value is fixed the instant it exists and never changes with how long Verification takes. The reply bonus settles five days after the post’s own timestamp, not five days after Verification, on the dials the APP had in force at the post, so every reply inside that window counts however long we took to look. Both halves hold, and the promise is simple: a post’s earnings do not depend on when we get around to looking — only on when it was posted. A later change to the APP’s dials never reaches a post already made; it governs only what a post made after the change earns.

Verification and delivery are never gated by billing state or plan. Only speed and on-demand depth are priced, and the baseline is a floor every plan gets: a post that is found is verified identically on every plan, including free, and every USER can ask us to look for their own posts on every plan. What a paid plan adds is that we also look on our own, once a day, for posts a USER forgot to check (§5.6). 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; it does not mention the APP; the Partner Tag is missing; the Partner Tag present is for a different language than the post is written in; the post is in a language the APP has not enabled; 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 USER was on a waitlist when the post was made; the APP has suspended the USER’s earning (§7); or the APP’s optional monthly reward pool is fully earned for the rolling 30-day window (§6). Configuration gaps on the APP’s side — no Partner Tag or 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 tag, moving it up, adding the mention — and posting 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 Partner Tag, when its reply bonus settles earns no bonus and has its base grant revoked.

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 YouTube). Both are on every plan. For an APP on a paid plan we also search the platform once a day for posts carrying the APP’s Partner Tag, so a USER who posted and never checked is still found. On a free plan a post is found only when its author asks, and the status page says so; nothing is lost by asking later, because valuation is at the post’s timestamp and the URL fallback has no time limit. 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, gated only by the cooldown 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.

A later change reaches forward only. If an APP raises or lowers what it pays, the new number governs posts made from that moment on. It never reaches a post already made — what a post earned was settled the instant it existed, at the rate that governed then, and no later event changes it: not a further rate change, not a cooldown change, and not the APP downgrading or cancelling its plan. If an APP downgrades or cancels its earned tier, posts already made and reply-bonus settlements not yet reached still settle at the rate in force when the post was made; only posts made after the change are affected.

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.

Between posts, nothing is refused for budget. A post made before the cooldown has elapsed simply does not earn — not because a budget ran out, but because the timing check in Section 5.1 was not yet satisfied, the same as any other check on that list. We do not verify a post as qualifying and then decline to pay it: a post either meets every check, including timing, or it does not qualify at all. The status page shows the date a USER can earn again.

No forfeiture. Nothing expires, because nothing is issued that could lapse. There is no deadline to be caught by and nothing lost by waiting — a USER who has not posted in months earns the full flat value in force when they next do, on whatever cooldown governs by then. An entitlement that has gone unused never leaves a USER worse off than if they had used it sooner.

An APP may cap its total monthly outlay. Separately from the per-USER cooldown, an APP may set an optional ceiling on the total it pays out across all USERS in any rolling 30-day window. When the ceiling is reached, further posts do not qualify until earlier spend ages out of the window; the USER’s status page states the date earning reopens. The ceiling 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 reply bonus: one settlement, five days after the post. A Qualifying Post can earn a second, additional grant for the conversation it starts. It is granted once, at a single settlement five days after the post’s own timestamp — not five days after Verification. There is no daily accrual and no running total: we read the post once, we settle, and the post is finished. Settlement is run by a daily sweep, so it lands within a day of the five-day mark rather than at a precise instant.

Five days, and why. The Supported Platform’s public search reaches back a fixed number of days — seven, on X today — and no further, at any price. Settling on the last day of that reach would leave no room to recover a failed run. Settling on day five leaves two days of margin, so a run that fails on a Friday can be recovered on Monday and still settle correctly. If a Supported Platform changes that reach, the interval moves with it, and any change is published here before it takes effect.

Counted in distinct replying accounts, never raw replies. The count is of distinct real accounts that replied. Ten replies from one account count as one. Replies 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 to the amount.

Paid at a flat rate, to a ceiling the APP sets. Two dials govern the bonus, both set by the APP, at the rate in force at the same moment that fixes the base value — the post’s own timestamp:

perReplyRate — what one distinct replying account is worth.
maxBonusPerPost — the most one post can ever earn from replies. A hard ceiling, never exceeded, whatever the post does.

The bonus is distinct replying accounts × the rate, capped at the ceiling. Flat rather than curved, deliberately: the earned tier’s own decay curve was removed for being complication nobody asked for, and a curve here would be the same shape. An APP that wants to reward a post that travelled sets a higher ceiling.

Still public, still tagged, at settlement. At the moment we settle, the post must still be public and must still carry the Partner Tag. If either is gone, there is no 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 the tag 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

Real person, own account. A USER must be a natural person posting from a social account they own and control, in their own voice. Agencies, managed accounts posting on someone else’s behalf, and accounts operated by a group are not eligible.
One handle, one USER, per APP. A platform handle binds to at most one USER of a given APP. This is the hijack guard, and it is enforced at the database level.
Several handles may bind to one USER, and the USER admits them. A USER — an organization, for example — may bind more than one account over time. The first account binds on its own qualifying post. Because the Claim Code is public once that post carries it, later accounts join in one of two ways, both decided on the status page: by posting a single-use invite code issued there, which connects the account immediately; or by posting the public Claim Code, which records a request that an existing member approves or refuses. A refused request cannot be made again. A post that asked to join is credited if, and only if, it is approved and the cooldown allowed a credited post at the moment it was made. Each account may be disconnected individually: by the person, on the status page, or by the APP.
An APP may suspend a USER’s earning. While suspended, the USER’s posts do not qualify and their status page says earning is off; everything already credited stays. Suspension and reinstatement are both recorded.
One enrollment per person per APP. A person may not hold multiple USER accounts with the same APP to earn more often than the cooldown allows.
Minimum age: 18. A USER must be at least 18 years old. Participation is acceptance of compensation for a public endorsement, so the floor is 18 — not the lower age that would suffice for privacy purposes alone. An APP must not knowingly enroll anyone under 18.
Where you are. Participation is not available where it would be unlawful, or where an applicable platform’s terms prohibit compensated posting by that account.
Platform rules still apply. A USER remains subject to the Supported Platform’s own terms, including its paid-partnership policy. We cannot cure a USER’s platform-level exposure; we can only tell them plainly that it exists.

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.

The Partner Tag alone is not enough for an insider. An employee, officer, director, contractor, agency, investor, or immediate family member of any of them, in each case with respect to the APP, may participate only if the post also discloses that relationship in plain words, in the post text, near the start — for example, “I work at Acme” or “I’m an Acme investor”. The Partner Tag discloses that the post is rewarded; it does not disclose that the poster is an insider.
APPs must identify their insiders. An APP must not enroll its own personnel or their immediate family in its earned tier without applying the insider disclosure requirement, and must not solicit posts from insiders as if they were ordinary USERs.
No incentivized insider reviews. An insider must never be rewarded for posting to a review site, app store listing, ratings platform, or comparison directory. Nothing in the earned tier rewards reviews on any surface, and this prohibition is absolute for insiders.
We do not police employment status. We cannot see who works where. Compliance with this subsection is the APP’s obligation and the USER’s representation, and both make it in their respective agreements.

8. Prohibited Conduct

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

Purchased or manufactured engagement. Buying replies, likes, reposts, views, or followers, or arranging reciprocal engagement, on a post that earns or is intended to earn.
Bot and sock-puppet accounts. Automated accounts, burner accounts, or additional accounts created or operated to earn more than once, or to inflate the number of distinct accounts replying to a post.
Duplicate or recycled posts. Reposting the same or substantially the same text to earn again, deleting and reposting to earn a second time, or scheduling a rotation of near-identical posts.
Cross-APP reuse. Claiming one post at more than one APP. We detect this across the whole platform; a post credits exactly once, ever, regardless of how many earned tiers the poster participates in.
Coordinated posting rings. Groups organizing to post, reply to, or amplify each other’s earning posts, including private groups, paid pods, and Drop-timed brigades.
Undisclosed automation. Generating or scheduling posts through automation without a person’s actual authorship, or using automation to submit posts for checking at scale.
Deleting or editing away the disclosure. Removing the Partner Tag after a post has been checked, or making a post non-public after it has qualified.
Misrepresenting the relationship. Claiming an APP endorses, employs, sponsors, or has verified the USER beyond the actual relationship, or presenting a post as unpaid.
False statements about the product. A USER’s opinions are their own and are never checked. Statements of fact must not be knowingly false, and a USER must not describe features or results they have not actually experienced.
Circumvention. Evading caps, cooldowns, binding, or enrollment limits by any means, including sharing Claim Codes between people to redeem.

8.1 Consequences

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

The post fails Verification. The ordinary outcome. No credit, no penalty, and the USER can post again immediately.
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.
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, open Drop windows, and reply-bonus settlements not yet reached settle on the rates 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 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. An APP sets a budget for the Drop, and the outstanding obligation is finite and computable at every moment of its life.

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.

Bonus tokens are act-shaped. A Drop may pay extra for the presence of specified elements — a campaign hashtag, a quote of the anchor, attached media. These are presence checks. They are never sentiment-shaped, never interpreted, and never a required script.

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 contests reward performance.

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, and any nudges issued. For every USER: enrollment state — a place or the waitlist — 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 distinct-account and repost figures are read there once; 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 (Partner Tag placement, mention, observed platform label), nudges issued, 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 reply-bonus settlements 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.