When the day came to introduce the world to the Pump.fun app (meme coin trading), it made sense to go all in with React Native, due to the small team and existing familiarity with JavaScript/React/etc. React Native has delivered on all those things, allowing us to rapidly build and support both major platforms while making the barrier of entry very straightforward for the existing folks used to building for the web with no/limited mobile experience (including myself).

The Pump.fun app mirrors the functionality of the website, as well as extending it in many areas, utilizing the functionality and features of smart phones to make the best possible experience. For example, features like notifications, biometric unlocking, etc.

This development velocity has been crucial to delivering so much customer value in a short time, but due to the nature of the app and the direction we wanted to take it in, to show as much real time price data as possible, we started to run into a few performance issues.

Performance issues

When a coin is very active, it can receive ~1000 trades a second, which our indexing service broadcasts over a Nats subject over websockets. For some of our screens, we show 10 or more coins at a time, all which can be in this hot state, resulting in 10,000 events per second in a “worse case scenario”.

Naturally, the human eye could not perceive 1000 price updates a second, nor could React Native adequately render that many at once. To this end, we are throttling the updates at 5hz per coin, which can still result in 50 updates per second on some screens. These updates are rendered in the form of a flashing price change indicator powered by Reanimated (see an example in the right hand column of the home screen) and also power the mini graphs (also visible in the screenshot).

When this screen receives a large number of price updates, our telemetry shows that the JS thread tends to drop significantly (can be in the 20FPS on high end devices), as well as the screen getting into a non nominal thermal state. We capture this telemetry by regular sampling of these metrics and sending them to DataDog, as well as some useful metadata such as the current route, device, etc so we can quickly see which screens are most problematic.

We needed to make this significantly better and the first thing was to find out where time is being spent on the JS thread.

A solution?

A colleague who was working on upgrading our app to Expo 54 recently also added a library React Native Release Profiler that allows profiling in a release build, something we previously couldn’t easily do. We ran the movers screen for about 30 seconds and then looked at the heavy left view in Speedscope. One of the first things that we saw was that about 3.5% of CPU time was spent applying styling via cssInterop, courtesy of Nativewind.

One of the first decisions made when initially setting up the app was to use Nativewind as Tailwind was also used in our web codebase, further reducing the barrier to entry. The library is working very well for us, and we hadn’t observed any issues prior to seeing this. The same colleague recommended we try out a new project called React Native Tailwind (RNT) that converts the className prop to StyleSheet.create() calls during the build phase.

This seemed like an easy win, due to the fact that it should be a drop in replacement and then everything would just work at build time, resulting in much faster style application (numerous benchmarks show that this method is the fastest way to set styling).

In the real world though, things don’t usually work out so easily. On adding this library, many parts of the app styling was broken. We wanted to push on anyway and try and get this working, as performance improvements which affect the runtime across the board (such as styling) usually pay a good dividend.

Limitations of RNT

One of the first things observed was that the library didn’t support (at the time) the size-n method of defining width and height in one class. I figured the fastest way to fix this would be to add a pre-processor Babel plugin that converts size-n into w-n and h-n and then let RNT do its job of converting them as normal. This seemed to work for those cases, but there were still a number of broken styles.

Some other ones that were not supported that we added support for are the “gap” classes, such as gap-n which decay to styles like column-gap and row-gap. These (and ones like it) are added as a separate StyleSheet object and then merged later into the one output from RNT in our postprocessor babel transform.

Another issue discovered was the pointer-events-none class which was not supported by RNT but actually worked in practice with Nativewind. These don’t become styles per se, but add the pointerEvents prop to a View/Text component.

Fortunately, during the build time phase, RNT logs the classes in use that it cannot convert, so it was reasonably trivial to go through each example and figure out why and how it’s used. To our surprise, we had about a dozen classes that flat out didn’t exist and even more “in use” that didn’t actually apply to React Native, but were carried over from Tailwind and marked as “web only” in the Nativewind documentation (we target only mobile platforms with our app).

Establishing the baseline

To stop the bleeding of this issue, I added a package that provides the no-custom-classname eslint rule that would flag classes that didn’t exist in Tailwind. Unfortunately this seems like it was built for web only, so while it did capture flat out hallucinations, it wouldn’t capture the cases where we used a web only class.

In order to find these, I extended the config of our existing “forbidden classes” eslint rule to catch these web only classes. I implemented a blocklist based on the Nativewind documentation, and then went through each newly issued flagged by eslint with a small test harness, to verify that the class actually was useless in RN. This now gave us a good baseline that only useful classes would be added, but I still saw many classes flagged that RNT didn’t have support for. I added support for these remaining classes.

Runtime classes are still necessary

Some of the classes we used had to be present at runtime for Nativewind, such as the “safe” prefixed classes which determine a safe area to render something, using the safe insets. I considered extending the transformer to import and use useSafeInsets and add to the style attribute manually, but decided against it for now and just mark them as runtime classes and not process them during build time.

Some others are the “disabled” and “active” prefixes to classes. These are supported by RNT, but only if you use the specific wrappers in the library, which I didn’t want to do for now (as we have hundreds of usages I’d need to manually verify). Some others were the transition and animation classes.

To make this work, the pre-processor rewrites any runtime classes to a expando-like prop to the component, which then a post-processor writes back to the className prop to be picked up by Nativewind during runtime.

Dynamic classes aren’t convertible

For many components we also use Class Variance Authority in multiple places, and the library does not currently support these. For now, these are applied still at runtime. There is an open PR (at time of writing) to add support for this.

Class concatenation problems

A lot of our existing design system components took a className prop which was merged with the existing className of the internal wrapper component, in order to customize the component. This seemed an anti-pattern, since we desired consistency in the design system, and all bets were off when giving this escape hatch to all implementers.

The biggest issue here however was that due to runtime className concatenation, we could not convert these safely to build time. This was made especially difficult by some components taking both a className and a style prop, but applying them to different components internally.

For example, if a component takes a className prop (which can be dynamic), which was joined with existing classes internally, and we convert those internal classes to style with the tw template tag, these will take precedence over the externally provided runtime className, resulting in broken styling (the className no longer overrides any existing classes as they’re now defined in the style prop).

In the example below, we cannot statically determine the className to apply here (well we could in this toy example with a little effort but imagine it comes from a deeper call stack), so if we render both of these components with identical props, the first one (using internal build time styles) will have a yellow background (unintended) and the second one (using runtime styles) will have a pink background (as intended).

function getClassName() {
  return "bg-pink-500";
}

// Build time internal styles
function ClassNameExample({
  className,
  style
}: {
  isActive: boolean;
  className: string;
  style: TwStyle;
}) {
  const backgroundColor = tw`bg-yellow-500`;
  return (
    <View className={className} style={[backgroundColor.style, style]}>
      <Text>👀</Text>
    </View>
  );
}

// Run time internal styles
function ClassNameExample2({
  className,
  style
}: {
  isActive: boolean;
  className: string;
  style: TwStyle;
}) {
  const backgroundColor = "bg-yellow-500";
  return (
    <View className={cn(backgroundColor, className)} style={style}>
      <Text>👀</Text>
    </View>
  );
}

// Yellow background ❌
<ClassNameExample className={getClassName()} />

// Pink background ✅
<ClassNameExample2 className={getClassName()} />

There are thousands of examples of these, so it’s not feasible to go and re-write each one right now and verify. The plan is to use more focused props where possible on building block/design system components, so we can apply the right styles internally, which will also have a win for consistency. We are currently overhauling these design system components.

In addition, we have an existing cn() function too which drops falsey values so we can do things like cn(“p-2”, isRed && “bg-red-500”). This obviously isn’t supported by RNT as it’s unique to us. To make this existing pattern work, I converted it to string templates in the preprocessor, which RNT does support.

Tooling

During the process, it was very useful to be able to see the input file and the transformed file, to manually verify what the output is and if it appears correct. To that end, I put together a quick script that would show the input file on the left and the transformed file on the right, which made it simple to see if the code was doing the right thing. This was much quicker than trying to find the source code in the JS bundle in the RN developer tools, but I still used this to verify too (as we have multiple Babel transforms that work together outside of styling, such as the React Compiler).

Shipping it

Due to the nature of this change, I considered it high risk as if I didn’t catch all cases correctly, the app’s UI could render wrong and the app would become unusable. I verified as many screens as we could, but the app is reasonably mature with a lot of surface area and there were many states the app could be in (first time user, funded user, etc). To increase confidence, I utilized the internal QA team with instructions to “test every single screen in every single state”.

The QA team completed this monumental task, and found a few issues with text being clipped. I fixed this by adding a line-height in the preprocessor for text sizes. Some complex screens with Reanimated also showed some strange behaviour, so I timeboxed fixes for these, and in some cases used the ignore functionality from Babel to skip converting some files, which in the end only amounted to a handful.

The outcome

Profiling the identical scenario on the native build, I was able to identify that the 3.5% of time spent during cssInterop dropped to 0.01%. I was very excited to see this! In addition to freeing up this runtime cost, I also saw faster route changes in the order of about 10%.

The biggest change, however, which we expected to influence but not to this magnitude, was the app startup time. On iOS, the app startup time in our telemetry averaged around 1.5s, and this dropped to about 110ms on the day I shipped this change to our customers. In addition, it became significantly faster on Android too.

Not only did we improve the general performance of our app, but we made the TTI much quicker for our users. Given this was a build time change, we couldn’t traditionally a/b test this change, but many previous experiments showed correlation between trading volume (one of our topline metrics) and performance improvements.

Before & after during the home screen rendering:

What’s next?

One of the goals of RNT was to be able to drop Nativewind entirely, and save on the bundle size of this. Unfortunately, due to the aforementioned runtime classes and the way we joined them, this proved impossible for the time being.

Not long after we shipped this, RNT added support for size-n classes so I was able to remove that portion of the pre-processor from our own code.

I will go further on converting more leftover runtime styles to build time where possible. We are currently building a new design system which will consider build time styles as a first principle, allowing us to squeeze a bit more performance.

Massive thank you to Olivier Louvignes for the RNT library itself. be good to contribute some of the missing functionality in RNT back to the library itself to benefit all.

Want to get involved?

We’re hiring software engineers, data scientists and machine learning engineers for Baton Corporation, the development company behind Pump fun.

We helped develop one of the fastest growing crypto platforms in history, with ambitions to create a global consumer brand that tokenizes the world’s highest potential, early-stage ideas. Being the first mover in our space, we reward hard workers that think from first-principles, are data-driven, and love taking big risks.

With roles ranging between $300k-$1.5m in base salary + ~$75k-$500k in $PUMP tokens, we offer some of the most competitive compensation packages across every level of seniority.

Apply now: https://jobs.ashbyhq.com/batoncorporation

If you’re reading this, a community has launched a token for you on pump.fun and is asking you to “claim” it. You are likely receiving messages, questions, and may be unsure what this actually means.

This guide is here to help you understand what claiming a token means, what your options are, and how to confidently navigate your next steps.

Let’s start at the beginning.

What is Pump.fun?

Pump fun is a platform where creators, founders and communities can instantly launch & trade tokens for free in just a few clicks.

Pump fun is responsible for billions of dollars in revenue, tens of millions of tokens launched & has proved itself as the most exciting ecosystem on the internet for creators & traders.

To get started, download the free Pump.fun mobile app: https://join.pump.fun/HSag/x

What is a token?

A token is a digital asset which represents a project, idea, person, or community that can be traded on the internet.

Pump.fun tokens are free to launch, with millions of traders actively participating in trading these tokens — some of which reach valuations in the billions.

What are Creator Fees?

Every Pump fun token uses Creator Fees, which means every trade on a token contributes a small percentage towards that token’s Creator Fees, which are then instantly claimable by fee recipients.

Creator Fees enable individuals, builders & communities to bootstrap their projects or ideas with potentially significant rewards which can accelerate projects & tokens further.

Rewarding creators means more alignment with token communities, as the more effort and success the creator drives towards the token community, the more trading takes place on the token, meaning more fees generated for the creator.

Why were Creator Fees allocated to me?

If Creator Fees were allocated to you, it’s a strong signal that people believe in your idea, your brand, or what you represent.

They see opportunity in you as a creator and want to support you.

What happens if I claim Creator Fees?

Claiming Creator Fees is your right as a creator and signals to a community that you have acknowledged the token and may engage with it in the future.

It is highly recommended that you claim Creator Fees from only one token, as token communities rally around a specific token which they feel best represents your project or idea, often deeming it the canonical token for you as a creator.

Claiming fees from multiple tokens may cause uncertainty in the community. If you have the privilege of having multiple token communities rallying behind you, reach out to our support team via Intercom on our mobile app or website.

Overall, claiming Creator Fees is an exciting moment for both token communities and creators which can lead to further interest & growth.

What does it mean to claim Creator Fees?

Claiming Creator Fees is an action that can be seen by anyone, meaning traders & token communities will be aware of which tokens you are claiming fees from.

Claiming fees signals your potential interest to token communities, and as such it is recommended that you are aware of the implications when it comes to claiming Creator Fees and engaging with token communities.

You should consider not claiming Creator Fees if:

• You don’t see yourself actively engaging with the token community.
• You are unsure whether the token aligns with your idea, brand or project.
• You are actively engaging with multiple token communities.

If you claim Creator Fees and actively support the token community, you may open the door to a powerful, aligned community who’s ready to help you grow. Your support may unlock further alignment, momentum, and more opportunities.

If you claim Creator Fees but don’t want to be associated with your token, be honest & transparent with the community. Transparency can prevent further speculation, tagging, and unwanted messages.

If you decide to claim Creator Fees, here are a few important next steps to consider:

1. Reach out to Pump fun support

Reach out to our support team via Intercom on our mobile app or website. Support may connect you with an affiliate who can provide tailored insights to help you better understand your situation and how to navigate it. Pump fun support has your & the token community’s best interests in mind.

2. Make sure you are supporting the right token community

There may be multiple token communities asking you to claim fees on different tokens. While these tokens may be very similar in appearance, the community often decides which token they think should be the canonical token for you or your project.

Before claiming fees on a specific token, identify if you are claiming fees on the token which the token community thinks should be your canonical token.

Token communities may reach out to you to make you aware of a well-performing token for your project or idea. It’s important to make sure you are supporting the right community, as there may be multiple communities encouraging you to claim.

Each community & token may differ in traction, social reach, market cap, and member count, so be thoughtful and selective in your decision.

Claiming & engaging with multiple communities or claiming fees from multiple tokens at the same time may split attention and, in most cases, reduce momentum for all of them. This ultimately causes them to fade out, which results in significantly less creator fees generated.

3. Consider if you want to hold some supply of your token

Some token communities may offer to send you tokens as an additional incentive to claim fees & support that token community. This aims to make you more aligned with your token community as well as rewarding you even more as the token grows.

Before claiming the fees, consider whether you’d like to purchase any tokens for yourself, or if community members are willing to make you more aligned with free tokens. You can do this by sharing your public wallet address and asking the community to send tokens directly to it. This is not a required step, but may be worth considering if you are prepared to support the token and community long term.

4. Have a clear path

Be prepared to stay active in the token community by posting updates, sharing progress, creating content, and answering questions.

5. Ensure you trust the token you are claiming from

Every token has one Coin Admin who can allocate fees, change fee allocations & more. Every Coin Admin has privileges to update creator fee settings, unless they revoke their privileges, which is the maximum sign of trust.

To check if a Coin Admin has revoked their privileges, check the token on the Pump fun mobile app:

How are creator fees allocated?

Creator fees are managed by a Coin Admin, meaning one person can:

• Edit fee recipients: This allows the Coin Admin to add up to 10 fee recipients.
• Edit fee distribution: This allows the Coin Admin to set specific percentages of fees to each recipient.
• Transfer admin privileges: Coin Admins can transfer their privileges to a new Coin Admin, thereby revoking their own privileges
• Revoke admin privileges: This is the highest signal of trust. Coin Admin’s can revoke all rights to editing creator fees, meaning all existing settings are permanently locked*

*As part of Pump.fun’s Community Takeover system, some tokens may be approved for a manual community takeover which will result in a new Coin Admin being assigned and fee settings being unlocked.

What to do after claiming creator fees

1. Once you claim the fees, make a public statement about the token, set expectations of what is coming and what people can expect from you:

For example: “Hey guys! Thank you for all the support, I’ve decided to claim the fees for [TOKEN], here is what you can expect from me…”

As many tokens share the same name or ticker, the token community may want you to clarify which token you are referring to. To do this, you can share the contract address, which is a long string of characters specifc to your token, such as: pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn

You can copy the contract address (CA) from the Pump fun mobile app:

2. Build trust — trust is the most important factor in whether people choose to support you. You build trust by being consistently active, supporting your community, etc. Without this, token communities may get the impression you are only interested in collecting fees.

3. Align the token with your brand or idea; explain how the token connects to what you’re building, your vision, or your long-term direction.

4. Use creator fees wisely; although it is completely up to you how the creator fees are used, directing a portion of them back into the project/token helps build trust and confidence in you.

For example, the fees can be used for marketing efforts, rewarding community members, or anything else needed to support the growth of your brand or idea.

5. Stay safe; be very careful about who you choose to get help from. Crypto has many supportive people, but as with any industry where money is involved, there may be bad actors looking to capitalize on your momentum. If you have any questions, reach out to our support team via Intercom on our mobile app or website.

6. Ignore hateful texts. The internet can be an unfriendly place, and unfortunately this may pertain to creators like yourself who are doing something great. The best approach is to ignore them and not give them any attention.

Final notes

With everything said, remember to have fun and keep building. Opportunities like this can be life changing, so give it your best. If you have any questions, reach out to our support team via Intercom on our website or mobile app and you may be connected with a Pump fun affiliate who can offer tailored insights specific to your situation.

Legal disclaimer: Trading fees are paid automatically by smart contracts on the Solana blockchain & it’s generally legal to receive them anywhere it’s legal to receive crypto. Tokens like those launched on pump.fun aren’t intended to be securities and many governments, including in the US, have stated this. Don’t give financial advice.