DAISY

A Uniswap v4 hook that pays the referral chain behind a swap, in the same transaction as the swap.

Overview

DAISY records who introduced whom, and pays that relationship out of swap volume. A wallet links to one referrer, permanently. From then on, every swap that wallet makes on a DAISY-enabled pool routes a portion of the fee up the chain to the two wallets above it.

The whole thing lives in the hook. There is no backend keeping score, no code to redeem, and no payout schedule. If the swap succeeds, the referral is paid.

Why this exists

Referral is the most reliable growth loop in crypto and the least trustworthy piece of infrastructure attached to it. Someone tells a friend about a pool, the friend trades, and the value of that introduction accrues entirely to the protocol.

Where referral programs do exist, they run off-chain:

• Codes expire. The volume you brought stops counting when someone else ends the campaign.
• Numbers are unverifiable. Your earnings live in a database you cannot read or audit.
• Payment is discretionary. There is no contract — only a promise and a spreadsheet.

None of these are technical limitations any more. A v4 hook can read the relationship and settle it during the swap.

Glossary

Swap lifecycle

The hook attaches to beforeSwap and afterSwap on the PoolManager. A swap on a DAISY-enabled pool runs through four steps.

The link

The link is a soulbound token minted to the referred wallet at the moment it attaches to a referrer. It is the only state DAISY stores per user.

Rules

• One referrer per wallet. Set once. There is no function to change it.
• Non-transferable. The token cannot be sold, moved, or reassigned. Referral position is not a tradeable asset.
• Self-referral is rejected. A wallet cannot link to itself.
• Cycles are rejected. A wallet cannot link to anything already downstream of it.
• Linking is free. It costs gas and nothing else. There is no entry fee and no position to purchase.

Fee split

The referral fee is a proposed 0.25% of swap volume, split three ways.

The treasury share funds audits, infrastructure, and the graph explorer. Its address and spending policy will be published before deployment.

Edge cases

Most of a referral system's honesty is in what it does when the chain is short or broken.

Attaching a referrer

A frontend attaches a referrer by calling the link function once, before or alongside the user's first swap. The draft interface:

interface IDaisyRegistry {
    /// @notice Permanently link msg.sender to a referrer.
    /// @dev Reverts if already linked, if referrer == msg.sender,
    ///      or if referrer is downstream of msg.sender.
    function link(address referrer) external;

    /// @notice The direct referrer of `wallet`, or address(0).
    function referrerOf(address wallet) external view returns (address);

    /// @notice Referrer and level 2 in one call.
    function chainOf(address wallet)
        external view returns (address l1, address l2);

    event Linked(address indexed wallet, address indexed referrer);
    event ReferralPaid(
        address indexed wallet,
        address indexed l1,
        address indexed l2,
        uint256 l1Amount,
        uint256 l2Amount,
        uint256 treasuryAmount
    );
}

Frontend guidance

• Show the referrer address before the user signs. A permanent action deserves an explicit confirmation, not a silent parameter.
• Say plainly that the link cannot be changed. Users who discover this later will be angry, and they will be right.
• If the wallet is already linked, disable the action and show the existing referrer rather than failing on-chain.

Reading the graph

The referral graph is public. Every link is an event, and the full structure can be reconstructed from Linked logs without any indexer of ours.

This matters more than it sounds. It means anyone can independently verify who was paid what, and it means the graph outlives the project — if the frontend disappears, the relationships remain readable on-chain.

Design constraints

Why two levels

Two levels reward the person who made the introduction and the person who made that introduction. That is where the causal link to real volume ends. Beyond it, payouts stop tracking contribution and start tracking position in a structure — which is the mechanic regulators, exchanges, and users all recognise as a pyramid.

The cap is in the contract rather than in a policy document, because a policy can be revised and a deployed constant cannot.

Why volume, never purchases

Payment is triggered by swap volume only. Nobody earns because the wallet they referred bought a particular token. Tying rewards to purchases would make the referrer's income depend on recruiting buyers rather than bringing traders, and that is the exact inversion that turns a referral program into a scheme.

Why soulbound

If referral positions were transferable, a market in graph positions would form immediately, and the graph would stop describing who actually introduced whom. Soulbound keeps the data honest at the cost of flexibility.

Not a downline

DAISY pays multiple levels, which is a structure worth being precise about rather than defensive over. Three properties separate it from a multi-level scheme:

1. Income comes from swap volume. Not from the purchases, deposits, or recruitment of the people below you.
2. Depth is capped at two, in code. There is no third tier and no mechanism to unlock one.
3. There is no entry cost. You never buy in, and there is nothing to sell to the person you refer.

These are structural claims, not reassurances — each one is verifiable in the contract once it is published. Judge them then.

Security

Self-referral across wallets

A trader can create a second wallet, link their main wallet to it, and collect the 60% themselves. DAISY does not prevent this and cannot. Any on-chain identity check strong enough to stop it would exclude legitimate users.

The mitigation is economic rather than technical: self-referral returns 60% of a fee the trader would not otherwise have paid, so it is a discount, not an exploit — the trader is strictly worse off than not linking at all. The design goal is that it stays uninteresting, not that it becomes impossible.

Audit status

No audit has been commissioned. No code has been published. Treat every number and interface in this document as a proposal.

Known open questions

• Gas overhead per swap, and whether the fee remains sensible for small trades.
• Behaviour under multi-hop routes where a single transaction touches several pools.
• Whether the treasury share should decrease over time and how that would be governed.

Status

FAQ

Can I change my referrer?

No. The link is set once and there is no function to modify it, including for the team.

Does this take money from liquidity providers?

No. The referral fee sits on top of the pool's LP fee. LP earnings are unchanged.

What if my referrer stops using the protocol?

They keep earning from your volume. The link records who made the introduction, and that fact does not expire.

Why Robinhood Chain?

Referral is the mechanic Robinhood's own growth was built on. Building the on-chain version of it there is a deliberate echo — and nothing more. DAISY is not affiliated with, endorsed by, or connected to Robinhood in any way.

Is there a token?

Not yet. Nothing has been deployed. Any token claiming to be DAISY today is not ours.

When?

No date. The specification is public first so it can be argued with before it is written into a contract.