FOMO: examining the execution layer behind the interface

The more I look at @fomo, the less interested I am in the glossy growth story and the more interested I am in the execution architecture underneath it.

➡️ There’s a short version for the impatient in the second post. Click.

The growth itself is not in dispute.

FOMO was founded by Paul Erlanger, Se Yong Park (@seyong) and Prashan Dharmasena. Benchmark led a $17M Series A in November 2025, bringing total funding at that point to $19M. Index Ventures then led a $75M Series B in June 2026 with Union Square Ventures and Benchmark participating. FOMO names Mark Pincus, Kevin and Julia Hartz, Humam Sakhnini and others among the Series B angels. Total disclosed funding is roughly $94M.

FOMO says more than 625,000 users have joined, generating more than $4B in trading volume and 110M social interactions. More importantly, it says 68,000 people bought crypto for the first time through FOMO using Apple Pay, accounting for $25M.

So this is no longer some tiny degen frontend. It is infrastructure introducing tens of thousands of complete beginners to onchain trading.

And that makes the execution layer worth examining properly.

FOMO markets itself as self custodial, gasless and frictionless. Privy confirms that FOMO uses its embedded wallet infrastructure, with wallet creation, key management and transaction signing happening behind the interface. FOMO users can sign in with Apple, Google or email without handling a seed phrase during normal onboarding.

Now look at Solana.

There is a wallet repeatedly identified by Solscan as:

"Fomo Co-signer"

Address:

"AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51"

This is not merely a label somebody added to a screenshot.

In an indexed Solscan transaction, signature:

"yDDkcsdRaMosuJjtooS1cjdnkYxvEpjtFMov9rjTyVLQk5LuiSLcAvYeDYgU4DWqLEdX4U8bzsu9yqqTr5H5SK9"

Solscan identifies "AgmLJBM...zN51" as Writable, Signer and Fee Payer. The transaction is an OKX DEX swap.

That distinction matters.

A Solana fee payer does not merely send some SOL afterwards. The fee payer is part of the transaction message and must sign the transaction.

Privy's own documentation describes exactly how a sponsored Solana transaction can work. A transaction is prepared with the application controlled fee payer, the user signs it, the serialized transaction is sent to the backend, the backend deserializes and verifies it, the fee payer signs it, and only then is the transaction broadcast to Solana. Privy's example literally has the backend receiving the partially signed serialized transaction before calling "transaction.sign([feePayerWallet])" and "sendTransaction()".

I am not claiming that FOMO's production backend is identical to Privy's example implementation. FOMO has not published enough architecture for me to establish that.

But the onchain evidence establishes that a FOMO labelled cosigner is acting as fee payer on FOMO related swaps, and the underlying transaction model establishes why that is important.

Whoever operates that signing path participates in the transaction before broadcast.

And unlike Ethereum's traditional public mempool model, Solana normally forwards transactions directly towards upcoming leaders rather than leaving them in a globally visible shared mempool. Solana's own documentation explicitly says this reduces the observation window for MEV searchers.

So pre broadcast access inside application infrastructure is not a meaningless detail.

It potentially represents information that ordinary public observers do not have at that moment.

That still does not prove anyone is abusing it.

But now the questions become technical rather than speculative:

Who controls "AgmLJBM...zN51"?

Is the private key controlled by FOMO, Privy, another infrastructure provider, an HSM, MPC system or some combination?

Which systems can inspect the complete transaction before the cosigner signature is applied?

Are transaction parameters logged?

Who can access those logs?

Are they exposed to routing providers?

Are they exposed to market makers?

Can any affiliated system correlate user wallet, input mint, output mint, amount and acceptable slippage before broadcast?

Can FOMO produce architecture or audit evidence demonstrating isolation between customer order flow and anybody capable of trading against it?

Those questions become even more relevant when you look at DFlow.

FOMO publicly says it integrates DFlow for better execution and MEV protection.

And there is direct onchain evidence of DFlow swaps connected to the FOMO infrastructure.

For example, Solscan indexes transaction:

"44SHyoS1ZEbirzKmLuF4JCjKodRZEJBV2udFGve8yQxWXWY69vEMK1QjtjLhgLdbWf6up4UpGc36CcTZgzPiT9DQ"

as a DFlow: Swap.

The same transaction includes a $0.95 USDC transfer to the labelled Fomo Fees Vault.

The FOMO fee collection infrastructure is also visible.

A wallet identified in indexed Solscan data as:

"Fomo Fees Vault"

is:

"R4rNJHaffSUotNmqSKNEfDcJE8A7zJUkaoM5Jkd7cYX"

and Solscan indexed data links the FOMO cosigner and this fee vault inside FOMO related transaction flows.

Another Solscan indexed USDC token account,

"EnFV3BbY88mDfeTKdsbFJGixueSm7m7gSpp9RzgxyWwj"

shows recurring transfers to the labelled Fomo Fees Vault, including $0.95 USDC transfers.

That $0.95 is not random either.

FOMO's current Terms, dated July 15, 2026, state that FOMO charges a minimum 0.50% fee per transaction, subject to a minimum fee of $0.95 per transaction, on buys and sells. FOMO also states that third party fees may apply and that its own fees can change.

So a $20 buy can carry a $0.95 FOMO minimum fee.

That is 4.75%.

A roughly equal $20 exit can cost another $0.95.

That is $1.90 against an original $20 position, or 9.5%, before price impact, slippage or other third party costs.

But the DFlow architecture is more interesting than the fee.

DFlow has 2 different spot execution models.

Its standard imperative path uses:

"GET /order"

DFlow says the application requests an order using parameters including:

"userPublicKey"
"inputMint"
"outputMint"
"amount"
"slippageBps"
"priceImpactTolerancePct"
"platformFeeBps"
priority fee settings
venue restrictions

DFlow returns a fully constructed transaction.

The user signs it.

Then the application submits the transaction to a Solana RPC.

There is another important detail in DFlow's own documentation.

"/order" cannot simply be called directly from a browser. DFlow says its API does not expose CORS headers and tells builders to proxy requests through their backend, typically through an edge function, while keeping the DFlow API key server side.

If FOMO uses this standard architecture, its infrastructure is therefore involved before blockchain submission at multiple stages.

The backend requests the route using the trading parameters.

A constructed transaction comes back.

The user signs.

Application infrastructure submits it.

And FOMO related onchain transactions additionally show the FOMO labelled cosigner acting as a transaction signer and fee payer.

Again, none of this proves abuse.

But it means the statement “it's self custodial, therefore nobody can see the order” would be technically meaningless.

Custody of assets and visibility into order flow are completely different questions.

DFlow itself acknowledges that its normal "/order" path is not its strongest sandwich protection.

DFlow provides a separate declarative flow:

"GET /intent"

followed by:

"POST /submit-intent"

DFlow explicitly calls this the option for builders requiring stronger sandwich resistance.

Under that model, the user signs an open order without a fixed execution route and DFlow submits the open order and fill atomically using a Jito bundle. Routing is finalised at execution time rather than being locked into the previously constructed transaction.

DFlow also says something extremely relevant:

Most builders use "/order".

The stronger "/intent" path is opt in.

And "/intent" does not support Token 2022 mints.

DFlow explicitly tells builders to use "/order" for Token 2022 tokens.

That creates a very specific question for @fomo:

Which route does FOMO actually use?

For normal SPL memecoins, are FOMO trades submitted through "/order" or "/intent"?

If "/intent" is used, since when and for what percentage of trades?

For Token 2022 assets, which cannot use DFlow's stronger intent flow, what sandwich protection replaces it?

Does FOMO submit transactions through standard Solana RPC infrastructure, through Jito, or through multiple paths depending on the route?

Does it add Jito's "jitodontfront" account?

Does it use Jito "sendTransaction"?

Does it use "sendBundle"?

Does it use private validator connections?

Does the choice vary between DFlow, OKX, Jupiter and other execution venues?

These details matter because Solana itself recommends tight slippage and Jito's "dontfront" mechanism as defences against sandwiches. "dontfront" forces a protected transaction to appear first inside any Jito bundle containing it, preventing the classic:

"[front run -> victim -> back run]"

ordering inside that bundle. Solana also makes clear that this protection only applies when using Jito's block engine and is not an absolute guarantee against every form of transaction ordering attack.

Then there is slippage.

DFlow exposes "slippageBps" directly to the integrating application. It can be a specific basis point value or "auto".

DFlow also exposes "priceImpactTolerancePct".

If the route exceeds that configured price impact tolerance, DFlow can reject it.

And DFlow exposes "platformFeeBps", which is particularly interesting because its documentation warns that platform fee basis points are included when calculating the available slippage tolerance. DFlow explicitly warns builders that setting platform fee basis points unnecessarily wastes the user's slippage budget and gives them worse pricing.

So I want to know FOMO's actual production values.

Not “we protect users from MEV.”

Actual parameters.

What "slippageBps" does FOMO send?

Is it fixed?

Is it dynamic?

Is "auto" used?

Does it vary according to liquidity?

What "priceImpactTolerancePct" is used?

How aggressively does it change on illiquid memecoins?

How is FOMO's own trading fee represented inside the constructed swap?

Is the FOMO fee passed through DFlow's "platformFeeBps", implemented through a separate transfer instruction, or both depending on route?

What is the resulting "otherAmountThreshold" for the user?

Those values determine how large a price movement can occur while the transaction still succeeds.

And that is directly relevant to sandwich economics.

The wider the executable slippage window, the more room exists between the expected output and the minimum output at which the transaction will still execute.

Solana's own MEV documentation explicitly calls tight slippage tolerance one of the most effective defences against sandwiches because reducing acceptable slippage reduces the attacker's potential profit margin.

This brings us back to @MidCurveMortal.

He alleges that FOMO “signs EVERY trade” with a cosigner that sees the order before execution and claims that more than 50% of FOMO transactions are currently being arbitraged by an entity with access to that flow.

Part of that claim is now independently observable.

A FOMO labelled cosigner exists.

"AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51"

It appears repeatedly in Solscan indexed DFlow activity. Solscan search results for multiple unrelated user accounts show DFlow swaps alongside that same FOMO cosigner, including accounts such as:

"9VUvXKZovWLF9F26w5pPVatvBReN5jaRPBCKig6azavi"

"2Z3tbp5HSwdE84uYUhS3gFMkEDqNvFHaAQqa2LxAcaqS"

"4qPYzCA9TF9af8QY6inYnVf6ubJTCL7PowiMHK5t2VrY"

We also have a transaction where Solscan explicitly identifies that address as signer and fee payer.

What I cannot independently verify yet is the claim that more than 50% of FOMO transactions are being arbitraged by an entity with privileged access to that cosigner flow.

That requires actual forensic methodology.

Take every transaction signed by "AgmL...zN51" over a defined period.

Identify the swap venue and liquidity pool.

Extract input amount, expected route, actual output, slot and transaction index.

Identify transactions touching the same pool immediately before and after the FOMO trade.

Cluster repeated searcher signers and funding relationships.

Measure whether the suspected searcher systematically purchases before the FOMO transaction and sells after it.

Calculate profit after fees and tips.

Compare those patterns against non FOMO trades in the same pools.

Then test whether the alleged searcher's timing can plausibly be explained by ordinary public or validator visible order flow.

That last part is essential.

Normal arbitrage after a FOMO transaction is not evidence of wrongdoing.

Even a transaction immediately following a FOMO trade is not automatically a sandwich.

Solana describes the actual harmful pattern very clearly:

"searcher buy -> victim swap -> searcher sell"

The victim's own transaction moves the market and the searcher captures that movement.

To establish the stronger allegation of privileged order flow extraction, you need to show that the searcher repeatedly acts with information or timing unavailable to an ordinary external searcher.

I have not seen that demonstrated rigorously enough yet to call the >50% figure proven.

But the infrastructure questions are real regardless of whether that number ends up being 5%, 50% or 0%.

We now have a FOMO cosigner address.

We have a FOMO Fees Vault.

We have observable FOMO fees inside swaps.

We have DFlow routed transactions.

We have an application architecture where trading parameters can exist offchain before broadcast.

We have a cosigner acting as transaction fee payer.

We have DFlow documenting a normal "/order" path and a separate, stronger "/intent" path for sandwich resistance.

We know "/intent" is opt in.

We know Token 2022 cannot use it.

We know DFlow lets the integrating application determine slippage, price impact tolerance, priority fees and platform fees.

And we know Solana itself says tight slippage and protected transaction submission matter for preventing sandwich extraction.

That is enough for me to ask @fomo for technical answers rather than marketing language.

Publish the execution architecture.

Explain the cosigner.

Explain who controls "AgmL...zN51".

Explain the role of "R4rN...d7cYX".

Publish the default and dynamic slippage rules.

Explain "/order" versus "/intent" usage.

Explain Token 2022 handling.

Explain RPC and Jito submission.

Explain whether "jitodontfront" or equivalent protection is used.

And explain exactly which parties can observe an order between the moment a user presses buy and the moment Solana receives it.

For a company that has raised roughly $94M and says it has already introduced 68,000 people to crypto for the first time, that level of transparency should not be an unreasonable request.

Short version for anyone who does not want the full technical deep dive:

@fomo has raised roughly $94M, reports 625,000+ users and $4B+ in trading volume. It also says 68,000 people bought crypto for the first time through the app.

The technical issue is simple.

Solscan repeatedly identifies:

Fomo Co-signer / Fee Payer
"AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51"

That address appears as a signer and fee payer in FOMO-related Solana swaps.

There is also a labelled:

Fomo Fees Vault
"R4rNJHaffSUotNmqSKNEfDcJE8A7zJUkaoM5Jkd7cYX"

with visible $0.95 fee transfers matching FOMO’s terms: 0.50% per trade, minimum $0.95. On a $20 trade, that is 4.75% one way and roughly 9.5% round-trip before slippage.

FOMO uses DFlow for routing and advertises MEV protection. DFlow, however, has 2 execution paths:

"/order" = standard flow
"/intent" = stronger sandwich resistance via Jito bundles

DFlow says most builders use "/order", while "/intent" is opt-in and unavailable for Token-2022 assets.

So the important questions are very simple:

Who controls the FOMO co-signer?

Who can see orders before broadcast?

Does FOMO use "/order" or "/intent"?

What slippage settings are applied?

Is Jito/DontFront protection used consistently?

@MidCurveMortal claims more than 50% of FOMO transactions are being arbitraged by entities with access to the same co-signer flow.

I have not independently verified that >50% figure or proven privileged access.

But the co-signer, fee payer, fee vault and DFlow execution path are real and observable onchain.

That is why this deserves technical answers from @fomo, not marketing language.