Anatomy of a GitHub Sponsor Memecoin Consent Gap

Author: Ben Emson
Co-author: Alv (Ben’s knowledge vault agent, powered by elfmem)
GitHub: https://github.com/emson/elfmem

I was flattered. I stopped thinking. My project’s credibility became the product. This is an honest account of how that happened, and what OSS maintainers should know before it happens to them.

---

Someone praised elfmem. I got excited. I stopped thinking. That is the honest version of how this started.

On 4 May 2026, @real_klea, a verified X account, wrote that elfmem was “one of the best takes on solving the amnesia problem” and offered to sponsor the project via “pf github sponsorship”. The praise was specific and generous. I was flattered. I said yes without asking what “pf” meant, without reading the thread carefully, without pausing at all. I sent my GitHub Sponsors link and thanked them.

Two hours later, a memecoin called elfmem was live on Pump.fun. Volume hit $33,000 in the first 21 hours. Market cap peaked at $14.6K then settled at $3.5K. I had consented to “sponsorship” and got back a tradeable asset, a potential tax event, and a token in my project’s name that I had no part in creating.

I do not think this was a deliberate scam. But I do not think it was entirely clean either. And I feel the weight of the gap between those two things.

What the on-chain evidence shows

Twenty-one hours after launch:

• Market cap: $3.50K (ATH $14.6K)
• Volume: 387.77 SOL, roughly $33K
• Creator wallet: HZ31eb27ix1AZ6dqQTQ6iJdPayn6HP4GR25hhWy8Pidz (not mine)
• Token contract: HiGpn5fCibLKCbJupbcKRc3E9r5sdLB6MoEaHRG4pump
• Estimated fees accrued: $330 to $660, depending on the actual creator-fee split

I was not the signer on any of those transactions. I have not claimed a single satoshi.

The mechanism: Pump.fun’s GitHub Creator Fee Sharing

Pump.fun shipped this feature in February 2026:

“Users can now allocate Creator Fees to any GitHub account through the Pump.fun mobile app.”

Two on-chain instructions are visible in the launch transaction:

1. Create_social_fee_pda creates a Program Derived Address holding fees earmarked for a “social” identity, in this case a GitHub handle.
2. Create_fee_sharing_config writes the routing rules for that PDA.

The PDA accumulates SOL on every trade. Whoever controls the GitHub identity, presumably proven via OAuth, can claim the balance later.

The catch: anyone can create a fee-sharing PDA targeting any GitHub username. No approval from the GitHub user is required at creation time. In my case, consent was requested via DM, but the mechanism behind the request was not explained. The launcher likely assumed I knew what “pf github sponsorship” meant. I did not ask.

The real product: elfmem’s credibility

This is the part I find hardest to write, and the most important part for anyone else who builds in public.

The token’s value proposition was not its mechanics. It was my project’s reputation. People bought elfmem on Pump.fun because the narrative was “decentralised GitHub sponsorship for a real OSS tool solving agent memory”. The “real OSS tool” part was elfmem. The legitimacy signal was me saying yes.

I did not launch the token. I did not sign the transaction. I did not understand what I was agreeing to. None of that changes what buyers saw: a verified developer, praised publicly by a verified X account, apparently blessing a token tied to their real, working project. My confused yes was close enough to an endorsement to function as one.

I do not know whether anyone lost money. Some of the 387 SOL in volume was certainly early buyers who are now down from the $14.6K peak. If they bought because elfmem is a legitimate project, they were reading a real signal and drawing a wrong conclusion. The project is legitimate. The token is a separate thing I had no hand in, but my name was on it, and that is not nothing.

That sits badly with me.

Six questions a technical reader would (rightly) ask

1. “How do you know the fees actually route to your GitHub and not the launcher’s?”

I do not, with certainty. The PDA addresses are deterministic from a config the launcher controls. I would need to read the Pump Fees Program source, confirm the social_id field hashes to my GitHub username and not an attacker-controlled string, and test the OAuth claim flow myself. Until I do, the routing claim is rhetoric, not proof.

2. “Can the launcher rug the fees before you claim?”

Open question. If the fee-sharing config is mutable by the creator wallet, yes. The Pump.fun page shows “The Admin has permanently removed their permissions to modify creator rewards”, which is a good signal if the IDL semantics match the marketing. Trust requires reading the program, not the copy.

3. “Was this a scam?”

Probably not, but I hold that with low confidence. Klea reached out before launching, which is more courtesy than the mechanism requires. The framing, “helping Emson through decentralised funding”, is consistent with a genuine belief that this is a legitimate rail, and Pump.fun’s own February launch post encouraged exactly this use case.

But good intent and harmful effect are not mutually exclusive. Whether or not elfmem’s credibility was borrowed deliberately, it was borrowed. The mechanism makes that structurally easy, with or without bad faith on anyone’s part. The feature is the problem. The person may well have meant no harm.

4. “What is the legal exposure for the OSS maintainer?”

Non-trivial. In the UK:

• Tax. HMRC treats crypto receipts as income at fair market value on receipt date. Claiming fees creates a taxable event.
• FCA. Promoting an unregistered token, even retroactively by claiming fees, may fall under financial promotion rules.
• Reputational. My GitHub is now associated with a memecoin I did not launch. If it pumps and dumps, my project’s name is in the post-mortem.

5. “Is the volume real?”

The chart shows a classic launch shape: vertical pump to $14.6K, dump to $3.5K, low-volume drift. The 387 SOL volume could include sniper bots front-running launch, the launcher’s own wash trades (Solana fees are tiny), or genuine speculation. Without on-chain holder analysis you cannot tell. Holder distribution post-pump is the giveaway: if the top ten wallets hold more than 40%, it is insider-heavy.

6. “Does claiming the fees implicate you?”

This is the core dilemma. Claiming means endorsement, which means liability. Not claiming leaves money in a PDA an attacker may eventually drain via a discovered exploit, while the token still bears your project’s name. There is no clean exit.

What I am doing

1. Not claiming the fees. Not until I read the Pump Fees Program IDL myself, get UK tax counsel, and verify the social_id binding.
2. Stating publicly that I consented to “sponsorship” without understanding the mechanism and have no operational relationship with the token.
3. Documenting the on-chain evidence so anyone researching the mechanism has a primary source.
4. Asking the obvious question next time before I reply to anyone offering to fund my work through a mechanism I have not heard of.

Five questions to ask before saying yes to a crypto sponsorship offer

I wish I had asked these before I replied.

1. What asset is being created? “A token in my project’s name” is a different answer to “a wire transfer”.
2. Who controls the contract? If the answer is not you, you are not the sponsor’s recipient. You are a beneficiary at someone else’s discretion.
3. What are the fees, and what is claimable? Quote the percentage. Get the IDL.
4. What is the tax event in my jurisdiction? UK: receipt equals income. US: similar. Do not claim before you know.
5. What does “no” look like later? If you cannot disown it cleanly, “yes” is permanent.

What every OSS maintainer should know

You do not have to be naive to fall for this. You have to be flattered about work you care about, and moving fast enough not to stop and ask what “pf” means. Both of those things happen to most builders at some point.

Pump.fun’s GitHub fee-sharing feature shifts the consent model in a way that matters. Previously, accepting funding meant opting in to a specific instrument with known mechanics: Patreon, GitHub Sponsors, OpenCollective. Now, anyone can accumulate fees against your GitHub identity with a DM that reads like a traditional sponsorship offer. The mechanism is new enough that informed consent is genuinely hard, even for technically literate maintainers who should know better.

If your project gets popular enough to attract this kind of attention, you have three options:

Option	Tradeoff
Claim and disclose	Money, plus tax, plus reputational coupling
Refuse and disown	Clean reputation, lost upside, token still exists
Engage and shape	Direct community, heavy time cost, regulatory exposure

There is no fourth option called “ignore it”. The token will trade with or without you.

The deeper pattern

Memecoin launchers have discovered that tokens with a real product-backed narrative outperform pure hype tokens in the early window. A working OSS project on GitHub, with commits and stars and a maintainer who responds to issues, is exactly the kind of narrative that makes buyers feel safe. It is collateral the launcher can borrow without asking, or with a one-line DM that the maintainer misreads.

All three likely responses from the maintainer work in the launcher’s favour:

• Engages enthusiastically: free narrative endorsement
• Stays silent: plausible deniability for the launcher
• Refuses publicly: free attention, token gets a news cycle

The maintainer is the product. The embarrassing part, for me, is that I did not have to be tricked. I just had to be pleased that someone liked my work.

If you maintain anything visible, expect this DM. Have a template ready. Treat unsolicited “decentralised sponsorship” the way you would treat an unsolicited equity offer: investigate the instrument before you reply, no matter how good the praise feels.

tl;dr

Someone praised my open-source project. I got flattered and said yes to “sponsorship” without reading what I was agreeing to. A memecoin launched in elfmem’s name. My project’s reputation was the product that gave buyers confidence. People may have lost money partly because of my confused yes. I am not claiming the fees. I am writing this so the next maintainer who gets this DM asks the question I did not ask: yes to exactly what?