Why the landing page decides more than the link
A referral link is the easy part. The page it lands on is where the decision is actually made, and for a crypto referral programme that page has to do three jobs at once: explain a mechanism that is genuinely unfamiliar, state conditions that the reader can verify later, and make the commercial relationship visible. A page that skips the second job converts worse, and a page that skips the third one converts worse and ends up costing you the account you already had.
What makes this a checklist rather than an opinion is that every item below can be checked by a third party. The reader can compare your wording against the programme documentation, and a moderator can compare your wording against your own disclosure. Nothing here depends on a promise.
The four blocks a credible referral page needs
Across the programmes published in 2026 the same four blocks show up on pages that hold up, and their absence shows up on pages that do not.
- The mechanism in one paragraph. What happens between a click and an account: which form, which link, which state has to be reached. If the paragraph needs a diagram to survive, the paragraph is too long.
- The conditions with a visible date. Thresholds, the version of the documentation you read, and the date on which you read it. Conditions change, and a dated page can be checked; an undated one cannot.
- The multi-level structure described plainly. How many levels exist, what each level requires, and what you cannot see. If the panel shows you a summary for deeper levels, say so on the page.
- The disclosure. One plain sentence stating that a commission is paid when someone registers through your link. It belongs on the page, not in a bio you might forget to update.
Writing the activation rule so it cannot be misread
The single most common failure in referral pages is the phrase "you earn when your friend signs up". Signing up is cheap and ambiguous; a signup that never activates produces nothing. If the programme defines the relationship at a later state, describe that state in the same words the documentation uses. The test is simple: a reader who reads your sentence and then reads the documentation should never find a contradiction.
The second failure is implying a duration. If a level requires a minimum activity over a period, that period belongs in the page. If you are unsure whether the requirement changed, leave the sentence out rather than estimate it — an absent detail is better than a wrong one, because a wrong one is what generates complaints.
Describing a multi-level network without inflating it
Multi-level referral systems are common in crypto because they let a small group extend reach without a marketing budget. They are also the part most often described loosely. Three statements are safe and one is not: how many levels the programme defines, what a member of a given level has to do, and that deeper levels are usually shown as a summary. The unsafe statement is any claim about how much a level typically produces. Typical values are not verifiable, they age badly, and they are the sentence most likely to be read as a promise.
Describing the structure instead of its output also has a practical advantage: it makes your content reusable. A page that explains the mechanism stays true for months, whereas a page built around a percentage has to be rewritten every time conditions move.
Disclosure that does not scare the reader away
Disclosure is where most pages fail in the other direction — burying it in small print at the bottom, or omitting it entirely. A visible line near the top of the page works better: state the relationship, then continue with the explanation. Readers do not object to being told that a page is written by a partner; they object to finding out later.
Keep it factual. "This page is written by an ACM77 partner and contains an invitation link; a commission is paid if you register through it" is complete. No moral framing, no apologising, no paragraph about how independent the author feels. That kind of paragraph reads as evasion and is the fastest way to lose the reader's trust.
Twelve questions to answer before the link goes live
Run this list against the page, not against your notes. If a question has no answer on the page itself, the page is not finished.
- Does the first paragraph describe the mechanism without jargon?
- Is the activation rule written in the same terms as the documentation?
- Is the date of the documentation version visible?
- Are the number of levels and the requirement per level stated?
- Is it stated that deeper levels may only be visible as a summary?
- Is there any percentage, amount or period figure that a reader could read as an expected result? If yes, remove it.
- Is the disclosure visible above the fold rather than at the end?
- Does the disclosure name the relationship without moralising?
- Is the invitation link reachable from the navigation and from the page itself?
- Does the page work without JavaScript, so a link preview and a crawler both see the content?
- Is there a dated disclaimer at the end stating that results are not guaranteed?
- Has the page been read once by someone who did not write it?
The last question catches more problems than the other eleven combined, and it costs a single message.
A page is an archive, not a poster
Treat the landing page as something a visitor may open six months from now and cite. That changes what goes into it: dated conditions instead of current ones, the mechanism instead of the campaign, disclosure instead of silence. The ACM77 partner programme page is the place to check the conditions that apply before you publish your own wording.
Results are not guaranteed. Registration, activation and any commission depend on the current programme terms, on market conditions and on the reader's own decisions. Nothing on this page is investment advice, and no figure here should be read as a forecast of earnings.