The trigger
AMMCreate is the one registered parser. Everything downstream, the audit, the enrichment and the verdict, hangs off that single event rather than sampling the whole stream.
TrenchXRP .. launch intelligence
Know about a token launch while it is still happening
Pharos watches the XRP Ledger for the moment a token becomes tradeable, audits the issuer before it says a word, and traces the wallet that funded the deployer. It posts a verdict, not a firehose.
One signal, not every transaction. The parser registry carries exactly one trigger, because the canonical launch moment on modern XRPL is a single event.The audit runs before the alert. Issuer state is probed and risk findings ride on the card, so the first thing you read is whether it is safe.
Section 01 .. detection
The launch moment is one transaction, and Pharos watches for it
A token on the XRP Ledger does not announce itself. It becomes real when somebody creates the pool that makes it tradeable, and that is an AMMCreate. Pharos treats that as the canonical launch and builds everything else around it.
What is deliberately ignored
OfferCreate has a parser and it is switched off. It fires on every trade against a fresh IOU, including one-XRP auto-routed swaps, so it produced alerts for mid-life tokens rather than launches. Precision was worth more than coverage.
Earlier, when it is turned on
Two optional pre-launch signals run ahead of the pool: a known launchpad hot wallet sending an activation payment, and an issuer blackholing itself, which is the step a serious issuer takes shortly before creating the pool.
Why one trigger beats many. A launch detector that fires on everything is a filter you have to build yourself. Pure orderbook launches with no AMM are rare and are excluded on purpose, and the exclusion is written down in the code next to the switch, so it can be reversed with a liquidity floor if that edge case ever matters.
Section 02 .. the alert
What lands in the channel
Every launch alert is one card with a verdict in the title. These are the fields it carries.
Token and platform origin
The currency and issuer, and which launchpad or platform the deployment came from when it can be attributed.
Initial liquidity
The size of the pool at creation, which is the single most useful number in the first minute.
Security audit and risk findings
Issuer state is probed and the findings ride on the card. The audit is part of the alert, not a separate lookup you do afterwards.
Market data, with its source named
Price and market figures carry the provider they came from, so you can tell a first-party ledger read from a third-party quote.
Quick links
Straight through to the explorer and the chart, because the first thing anyone does is go look.
Revivals, as their own signal
A dormant token waking up is not a launch and does not pretend to be one. It gets its own card with how long it was quiet before it moved.
Section 03 .. who is behind it
Follow the money backwards
A deployer address on its own tells you nothing. The wallet that funded it, and the wallet that funded that one, is where the pattern lives.
Funding attribution
Pharos records who funded a deployer and keeps that deployer history, so a repeat actor is recognised on their next launch rather than researched from scratch.
The funding chain
Argus walks the chain of funding wallets backwards and stores it, so a launch can be placed in a graph instead of read as an isolated event.
Depth as a signal
How many hops a deployer sits from its source, and whether that path is shared with other launches, is evaluated rather than eyeballed.
Access
Pharos runs continuously and delivers into Discord. It is operated infrastructure rather than a self-serve signup, so access is arranged directly. Come and ask.