ETHGlobal X/Twitter referral system#

From the ETHGlobal Tokyo hackathon onwards, accepted participants could share a personal referral link on X and get half off their stake once we verified the post. The stake is a deposit paid in Ethereum (ETH) to confirm a spot at the hackathon. Other accepted participants who used the link could get half off too. I worked on the flow from reading the post to generating the discount and applying it at checkout.

I found this feature to be particularly interesting to work on, and wanted to write about it. not much seem to happen on the surface, but lots occurred in the background to get this through.

The full Tokyo demo on prod follows the referral link from sharing on X to verification and a stake that drops from 0.02 ETH to 0.01 ETH.

Verify the post#

Participants share their referral link on X and paste the post URL back into the event page. Verification starts with a Mastra agent tool call.

We accessed Grok 4.3 through OpenRouter. Grok’s built-in X Search let us look up profiles and fetch posts without paying for direct access to the official Twitter API. I built and tested tools to resolve X profiles and retrieve a post’s text and author from its exact URL.

Apply the reward#

Once we verified the post, we still had to get the reward onto the right checkout. Applying it meant plugging the referral flow into five existing ETHGlobal data models. The payment fields are internal, so I’ll stick to what each table does and how they fit together.

campaign: Defines the reward for an event, including whether it’s a percentage or a flat amount and how much to take off. Our referral campaign offered 50% off.
prices: Lists what someone can pay for at an event. A ticket to Pragma, ETHGlobal’s one-day conference, has its own price. So does the deposit for a hackathon.
campaign_incentive: Joins a campaign to a price and defines how the offer applies to that price. A price is eligible only if that pair has an incentive record. We linked the referral campaign to the hacker stake price.
discount: Once a participant qualifies, we generate a discount from the matching campaign incentive row and link it to that participant and their payment.
payments: Each payment represents a checkout. Once the discount is applied, the hacker sees the lower stake here.

We added a marker to the tables’ flexible JSON meta field. We included that marker in the external metadata so eligible participants could apply the discount themselves.

This is where the edge cases got interesting. Here they are, and my solutions for each one:

Missing or mismatched X account. We required a connected account and checked that it matched the post’s author.
Referral link submitted on its own. We required an X post containing the participant’s own referral link or code.
Failed verification. The participant could retry with a new post.
Switching X accounts. We kept any discount already earned. To verify posts from the old account, the participant had to reconnect it.
Repeat submissions. We recorded the X post ID in the discount’s metadata. Prisma supports JSON field lookup in PostgreSQL, so we directly use a where clause with a JSON path to look for the ID. A match blocked a second redemption. With no match, the post could still qualify.
Self-referrals. The poster couldn’t use their own link to claim a second discount; similarly stored in the campaign that we generated for them. Other accepted participants could still use it.
Existing discounts. If someone already had 50% off or more, we kept their existing discount.

End result: The hacker gets their Ethereum discount. In the demo, the checkout drops from 0.02 ETH to 0.01 ETH. Pretty proud of this one since lots of people are using it, search “I’m going to ETHGlobal” on X, and see the posts.