Launch a coin for any person via their social handle. Owners claim trading rewards after bio verification. X Money payouts for eligible US users on X platform.
Person is now live on Robinhood Chain!
CA: 0x70d3e2fc29fbd88e2c7f9ebd1f1e66055c52ed34
Introducing https://t.co/4CJ8Y6RVQG, the first launchpad on Robinhood Chain that connects social media accounts to tradable coins, credits the person behind each account with 2% of every trade, and lets them verify ownership with one code in their bio.
X Money payments are available to eligible US users who have had a coin launched for their X account.
Launch a coin for any person. Give them a share of the activity around their name.
A creator posts. A streamer goes viral. Someone becomes the person everyone is talking about. A community forms around them, and someone launches a coin.
https://t.co/4CJ8Y6RVQG connects that coin to the person from the first transaction. Every buy and sell credits their rewards. They can discover the coin later, prove the account is theirs and claim what has accumulated.
The community starts the market. The person has something waiting when they arrive.
Your community trades. You earn. Now choose how to receive it.
On https://t.co/4CJ8Y6RVQG, 2% of every trade in a coin linked to your profile accrues to you, even when someone else launched it. Our optional X Money delivery flow gives eligible US users another way to receive their ETH rewards: as a USD payment to their X Money account.
Verify your X identity, request delivery, and authorize the claim after approval. Our team then handles conversion and manual payment, while you track the request through the Claim page. A familiar payout destination, connected to the activity happening around your coin.
The community can launch it. You can claim your share.
ETH rewards only. Subject to availability, eligibility and approval. A 5% service fee plus applicable external costs applies. Delivery is manual, not instant. https://t.co/4CJ8Y6RVQG is not affiliated with or endorsed by X or X Money.
How should we choose what https://t.co/4CJ8Y6RVQG needs next?
A new feature adds another possibility. A reliability fix can improve every attempt at something people already do. Clearer wording can remove a misunderstanding before it becomes a support request.
All three matter, but they solve different problems.
A useful way to assess the next piece of work is to ask who it helps, how often the problem occurs, what happens when it goes wrong and how we will know the change worked.
That also makes development updates more useful. Each release can explain the problem it addressed and show the resulting behavior.
As https://t.co/4CJ8Y6RVQG grows, the aim should be to make more of the existing journey dependable while adding capabilities people have a reason to use.
Which part of that journey deserves attention next?
Someone tells you a token has been launched for you.
What is your first question?
Who created it? Why your name is attached? Whether you need to do anything? What receiving fees means?
We would like to hear from creators who do not spend their day using crypto products.
Open https://t.co/4CJ8Y6StGe and tell us what you would need explained before deciding whether to participate. You do not need to buy anything or connect a wallet to share that first impression.
The most useful feedback may be a question we assumed the page had already answered.
Understanding that gap can change the order of information, the language on a screen or the explanation beside an action.
What would you ask before taking the next step?
A green indicator should not be the only explanation that an action succeeded.
For https://t.co/4CJ8Y6StGe, clear interaction design means pairing visual states with information people can actually use.
An error needs a readable explanation. A waiting state needs to remain distinguishable from a completed one. A focused button needs to be visible when someone navigates with a keyboard.
Motion deserves the same consideration. An animation can help explain a transition, but the action should remain understandable when motion is reduced.
These are practical criteria for reviewing the interface as it develops.
People use different devices, different input methods and different display settings. The product should communicate what happened and what comes next across those conditions.
That is the standard worth building toward.
A mobile crypto flow can cross several apps before one action is finished.
You open a link in a social app, move into a browser, switch to a wallet and then return to the page.
For https://t.co/4CJ8Y6StGe, that whole journey matters.
Does the page preserve what you entered? Can you see the next action when the keyboard is open? When you return from your wallet, is it clear whether the request is still waiting, was rejected or was submitted?
Those are the questions a useful mobile review needs to answer.
A layout fitting on a phone is only the starting point. The flow also needs to survive interruptions and app switching.
If you have hit an awkward step on mobile, tell us which phone, browser and wallet you were using, and where the flow stopped making sense.
A useful small-fix post should show the exact problem, the changed behavior and how that behavior was checked. “Improved UX” tells you very little. Showing that a failed attempt no longer makes someone re-enter their work tells you something concrete.
If you have used https://t.co/4CJ8Y6RVQG, tell us about one place where you paused because the next step was unclear.
The screen you were on, what you expected and what happened instead are enough to start a useful investigation.
You open a coin page for the first time. What happened before you arrived?
A useful future addition to https://t.co/4CJ8Y6RVQG could be a chronological activity view: the launch, published updates and messages from the person, each with a timestamp and a link to its source.
That would give a new visitor somewhere to start without having to reconstruct the history across separate views.
There are important details to get right.
An edited update should remain distinguishable from its original version. An onchain event and an offchain message should show their different sources. Two events happening close together should not be presented as proof that one caused the other.
The purpose would be to make the history easier to inspect and let visitors form their own understanding.
When a product is built around people, those people need a say in how they appear.
Someone may discover https://t.co/4CJ8Y6RVQG because a community created a token for them. Their next question could be about their profile rather than their earnings.
Can they introduce themselves? Choose which links to share? Explain how they want to be contacted?
For future profile tools, a useful starting point is separating information imported from a social account from information the verified person adds themselves.
Preparing a token launch and authorizing it are two different moments.
You may want to work on the image, check the description, review the selected person and come back later before sending anything onchain.
A feature we would like to explore for https://t.co/4CJ8Y6RVQG is saved launch drafts with a clear preview.
The engineering detail is where the draft ends and the transaction begins.
Saved inputs should remain editable. Anything that can change with the market needs to be refreshed before signing. The final review should make clear which choices will be committed onchain.
A saved draft should preserve your work without suggesting that an old estimate is still valid.
The goal would be simple: prepare carefully, return when ready, and review the actual launch before authorizing it.
A notification should earn the interruption.
If we add notifications to https://t.co/4CJ8Y6RVQG, the first design decision should be which events deserve your attention.
A person you follow publishing a message is different from another trade happening in a busy pool. A change that needs your action is different from an update you could comfortably read tomorrow.
What would you actually want https://t.co/4CJ8Y6RVQG to notify you about, and what would make you turn notifications off?
Who would you follow on https://t.co/4CJ8Y6RVQG?
You might discover someone through one token, then want to keep up with the other activity around their profile. Finding that person again should not depend on remembering a ticker or keeping a browser tab open.
One direction worth exploring is a personal watchlist for both people and tokens.
Following a person could bring together new launches and their own messages. Following a token could keep your attention on that specific market.
Those are different interests, and the design should let you choose between them.
Before turning this into a feature, there is a useful question to answer: when you return to https://t.co/4CJ8Y6RVQG, are you usually looking for a person, a particular coin, or something that changed since your last visit?
Nice to see our ideas/technology finding a second home.
To everyone discovering $SEND on Solana: https://t.co/mhMSzdx1IL might look familiar.
People will find their way from the copy to the original.
We’ll be here building. You’re welcome anytime.
Every coin launched about a creator earns fees.
The creator never sees them.
SEND fixes that.
Launch a coin for anyone on X, TikTok, YouTube, IG, Twitch, Kick, Facebook, Reddit, Telegram or Snapchat
CA: 2XuQnYQ1q3oTjPL9j4PfhV1AEqcZ6Hq2PzPzuxaASEND
An update from the team: Protocol Analytics is now live on https://t.co/4CJ8Y6RVQG
-> https://t.co/VqwNtBlRlC
We built this to make activity across the protocol easier to inspect, beyond individual coin pages and personal earnings.
The dashboard brings together trading fees, onchain recipient claims, volume, new launches and earning profiles across 24h, 7d, 30d and all-time views.
A big part of the work was getting the accounting right.
Buyback sweeps also emit a claim event at the contract level. We exclude those from recipient claims so the same movement doesn’t tell the wrong story.
Different quote assets stay separate, every report shows its indexed coverage, and CSV exports preserve exact amounts.
The goal is simple: give the community useful data they can explore and check for themselves.
@vovweb3@bazingahappy On-chain. The trading hook accrues fees with each swap, and the contracts handle claims. Our off-chain attester only verifies account ownership to link your wallet. It never holds or moves funds. No relayer is needed for fee accrual.
Following many requests from our community, we’ve built a dedicated Compare section for https://t.co/4CJ8Y6StGe and $PAID.
View Here: https://t.co/eOtEJpwzOR
It puts 33 features side by side, covering supported social platforms, reward claims, launch mechanics, identity verification and payouts.
From a developer’s perspective, those details matter. Where do the fees accrue? Who authorizes a claim? Can the recipient keep their rewards onchain? What does the person actually need to do to receive them?
These are the questions we wanted the page to help answer.
We’ve included contract addresses, source links and regularly updated token prices and market caps, so you can check the underlying information yourself.
There’s also a separate section explaining the Fiat Route we’re working toward, including automated X Money payouts and additional crypto-to-fiat options under evaluation.
This is our comparison, published openly for anyone to use in their own research. Explore the differences, check the sources and draw your own conclusions.
One integration detail can determine whether a token is actually ready to generate payable fees.
For $PAID documented https://t.co/792N3baLr6 route, launching the token is followed by configuring fee sharing: assigning 100% to the UsePaid treasury and revoking the configuration authority. The token is not payable through that route until the required configuration is permanent.
https://t.co/4CJ8Y6StGe builds the person relationship into the launch itself.
The factory derives the person key from the selected platform and handle. The pool’s person-fee accounting is attached to that key, and the escrow uses the bound wallet to authorize claims.
The launcher does not need to complete a separate third-party fee-sharing setup after creating the coin.
From a developer’s perspective, this removes an extra configuration step that users would otherwise need to understand and complete correctly.
The person still needs to verify and bind before claiming. But the token’s person-fee relationship is established when it launches.
A payment receipt tells you money was sent. It does not tell you what the recipient thinks about the token.
$PAID explicitly says that receiving a payment does not constitute endorsement. That is an important distinction whenever anyone can launch a token for someone else.
On https://t.co/4CJ8Y6StGe, verified person messages give the person a way to speak directly on the coin page.
They can introduce themselves, answer a question, explain their involvement or clarify that a community launched the token independently.
The message is signed by a wallet. The service checks that signer against the wallet bound to the coin’s person key before assigning the verified badge.
The badge identifies the author. The message itself tells you what they have chosen to say.
That is a useful part of a person-focused launchpad: visitors can hear from the person instead of inferring their position from a payout, a profile picture or a token name.
Making crypto earnings easier to receive should also leave room for people who want to keep them onchain.
UsePaid’s documented recipient payout is in dollars through X Money.
On https://t.co/4CJ8Y6RVQG, a direct wallet claim delivers the pool’s quote asset. ETH-denominated fees can be claimed in ETH. Supported stock-token fees can be claimed in that stock token.
That lets the person receive their earnings without first converting them into dollars through a payout operator.
At the same time, we’re working on automated X Money delivery and evaluating additional crypto-to-fiat routes for people who would rather receive familiar money in a familiar account.
Both needs deserve a place in the product.
A creator new to crypto may want fiat delivery. Another person may already use a wallet and want the asset their fees were earned in.
Our direction is to make receiving easier while preserving that choice.
What happens when a person cannot receive an X Money payment?
$PAID documentation gives an ineligible recipient’s held balance a seven-day window. After that, it passes to the protocol treasury.
https://t.co/4CJ8Y6RVQG gives the person another way to receive their fees: a direct onchain wallet claim.
Once the person has verified their identity and bound a wallet, their fees are excluded from the unbound-person sweep. They can accumulate until the person chooses to claim, without needing an eligible X Money account.
There is a separate rule for people who never bind: after a 90-day cycle, their coin’s unclaimed person fees become eligible for a buyback and burn of that coin.
That distinction matters. Being unable to use a particular payment service should not prevent a verified person from accessing their earnings through the wallet route.
We’re developing automated fiat delivery alongside that existing choice.
As we work toward automated fiat payouts for https://t.co/4CJ8Y6StGe, one of the questions we’re working through is what the recipient should see between requesting their earnings and receiving them.
An onchain claim can succeed while the fiat payment is still being processed. A conversion can complete before the destination account is credited. A payout provider can reject a transfer after an earlier step has already succeeded.
Those are different states, and the product needs to explain them clearly.
Our goal is for a creator to open https://t.co/4CJ8Y6StGe and understand where their payout stands, what amount has been confirmed, and whether anything needs their attention.
That also means connecting each step to its own record. A claim transaction proves the crypto moved. It does not, by itself, prove that money reached someone’s account.
We’re evaluating payout integrations with that full journey in mind, including how failures are reported and resolved.
For someone receiving their first earnings from a token, “processing” should not become a dead end.
Making payouts accessible means making them understandable from request to receipt.