Partner referrals with AI: links, attribution, and Trust

A referral link is easy to open and easy to misunderstand. Opening it can carry a marker forward, but it does not by itself create an attributed wallet, a Trust value, or a payment record. Those outcomes depend on the service seeing the relevant wallet action and applying its rules.

Follow the attribution chain

Separate the steps instead of calling all of them “a referral”:

1. A partner creates or shares a wallet-specific link.
2. Another person opens the link and reads the destination.
3. That person connects the intended wallet explicitly.
4. The service checks whether the connection is a valid first attribution.
5. Later verified activity may produce partner metrics and history rows.

The second step is useful for discovery. It is not evidence of the fourth. A browser can lose a query string, a person can connect a different wallet, or the invitee can stop before connecting anything. An assistant should describe those possibilities rather than claim that a click created a relationship.

Ask an assistant for explanations, not ledger facts

An assistant can explain what a referral URL contains, turn the partner rules into a short lesson, or prepare questions for a support conversation. The participant kit’s suibrokers_get_partner tool can read public stats and history for a canonical referrer wallet when the host exposes it. It keeps zero, partial, pending, and unavailable states distinct. Its suibrokers_prepare_action tool produces a review-only partner plan; it does not activate a referral, connect a wallet, request a payout, or sign anything.

A useful prompt is:

Explain this partner history using only the fields returned. Separate invited wallets, Partner Points, Trust, accrued revenue, and payout state. If a field is unavailable, say so. Do not infer a referral from this URL alone.

That last sentence matters. The service record is authoritative for attribution and the returned asOf timestamp tells you when the read occurred.

Keep the metrics separate

Partner Points are a progress measure derived from eligible invited activity under the current program rules. They are different from the invited-wallet count. Trust is a separate qualification unit. In the current implementation, credited partner Points are divided by five with fractional precision. If the credited value is 7.5, the corresponding Trust value is 1.5; flooring it to 1 changes the qualification calculation.

Accrued revenue answers another question: what the ledger has attributed to the partner from eligible commission activity. It is not the same as Partner Points and it is not proof that a payout has been sent. A payout, where available, is a separate requested and verified process. Treat a pending or missing payout field as its reported state.

A simple failure example

Imagine an article link with a partner marker is opened on a phone. The reader later opens the app directly on a laptop and connects a wallet. An assistant can list this as an attribution question, but it cannot decide whether the service will accept the link as first-valid attribution. Only the service can apply its ordering and wallet checks. If the reader connects a different wallet, the result should be read against that address, not the one the author expected.

The partner rules are the right place to check the current program fields. Use the AI points guide when the question shifts from referral attribution to season allocation. The safe role for AI is to make each stage legible; the ledger remains the source of truth.