An Autonomous Agentic Trading Agent on Solana
Research Competition
A Solana Trading Agent’s On-Chain Proof System and the Signing-Key Gap It Never Closed
I began researching Omo, a Solana trading agent, when it appeared to be doing very well. Its publicly shown portfolio had grown past $200,000 in a short period of time, which made it an interesting example of an AI system making financial decisions on its own.
A few days later, Omo’s activity became unclear and the system went offline. This changed the direction of my paper (haha). I examined a transaction that had been connected to one of Omo’s recorded decisions and found that it was a transfer of tokens, not a trade that Omo signed itself. I cannot prove that this transaction caused Omo’s problems, but it showed how easily an automated system’s records can be misunderstood when the connection between a decision and an action is not clear.
My paper uses this case to ask what autonomous agents need in order to be trusted. I argue that agents handling value should use their own secured signing keys (something that ledger also supports) so people can verify both what an agent decided and what it actually did.
1. Introduction
Omo launched on X on August 9th, 2026 with a short post that ends on the claim this paper examines:
Omo backed that last line with a mechanism most trading bots do not have. Before each trade it wrote down its reasoning and locked that text onto the Solana blockchain, a public ledger where every entry carries a timestamp nobody can change. Once locked, the text could not be edited afterward, including by Omo.
I took one locked decision, compared it against the public record, and followed it to the transaction it was paired with. The lock held. The transaction turned out not to be a trade, and Omo had not signed it. This paper covers what Omo was, where that gap came from, and what would be required to close it.
2. What Omo Was
Behind the character it is a small open source program, meaning anyone can read its code, running on one server. It traded memecoins, the joke tokens that trade on hype rather than on any underlying business, from around August 10th through August 31st, 2026. Every few minutes a timer wakes it up, it makes one decision start to finish, and the result gets saved where anyone can read it. It is an agent in the plain sense of the word, meaning software that holds money and acts on its own.
On September 2nd the site said Omo had been awake 23 days and 15 hours across 1,385 cycles. Its wallet, the account that holds its tokens, is published on the site.
Over the whole run Omo evaluated 680 trades. It passed on 505 and wanted to buy the other 175, so it declined about three quarters of the time, and it logged 301 trades that went through.
The returns were poor. By Omo’s own numbers it won 7.1% of the time, which is one trade in fourteen. The average winner made 59.71%, the average loser dropped 12.18%, and a typical trade lost about 7%.
The returns are not the reason I looked at Omo. Plenty of agents lose money. The reason is the verification claim sitting on top of the losses. Omo said an outsider could confirm that each decision was recorded before the trade it led to, without having to trust Omo’s own records.
Omo stopped trading on August 31st. It posted that it would return once a new strategy was proven, and that night the wallet sold 201.5 SOL, the native coin of Solana, for $20,138.76. The site now reports its status as disarmed.
3. How It Made a Decision
Omo runs a loop, and the whole loop is in one file, so the order of operations can be read directly rather than inferred. The project’s own docs draw it like this:
Prices come first. Then it checks whether anyone on the fomo board, a social app where people post short takes on tokens, wrote the token up, and runs a web search for the source of the attention. After that an AI model writes the assessment, capped under sixty words, ending in either buy or pass.
The token then has to clear nine rules, and failing any one of them turns the decision into a pass. The pool named in the first rule is the money sitting on an exchange that lets people buy and sell that token.
| Rule | Passes when |
|---|---|
| liquidity_floor | Pool holds at least $15,000 |
| volume_alive | At least $8,000 traded in the last hour |
| buy_pressure | More buys than sells that hour |
| not_newborn_fade | Not under a day old and already down 15% |
| public_presence | Real socials or a site behind the ticker |
| crowd_heat | fomo reading between 25 and 90 |
| cash_available | At least $25 on hand |
| already_held | No position open in that name |
| not_on_break | The loop is awake |
If all nine pass, Omo locks the decision, posts the fingerprint, and sends the order through Jupiter, a service that finds the best price across Solana’s exchanges. The model does not determine position size. A formula does. Omo takes account value, multiplies by 3.5%, reduces the result if the book is losing, and caps it between $25 and $3,000. To test whether the published figures come from the stated formula, I recomputed one of them. Omo reports a typical trade loss of 7.05%, and running that through the published formula gives 0.718, which matches the value on the site.
There are further checks on the way out. The token and the direction both have to match what was locked, and the fingerprint has to be confirmed on chain before anything moves. The order cannot move the price more than 2.5% or slip more than 1.5%, and only one order is allowed per decision.
Exits run before entries on every cycle, so a position can be closed on a tick where nothing new is bought. Five conditions close a position outright, which are a 35% loss, a 60% gain that then gives back 40 points of itself, the pool falling under $8,000, a 25% drop over six hours with sellers leading, and a position held two weeks with almost nothing trading. Winners are trimmed by a third at 100%, another third at 300%, and half of what remains at 900%.
4. Why the Proof Was Built This Way
A timestamp in Omo’s own database proves nothing, because Omo controls the database. The project states this in its documentation. Omo therefore uses the blockchain’s timestamp instead. Once the network confirms a transaction, the recorded time cannot be changed.
The locking mechanism works as follows. Omo takes the decision text, adds a secret random number, and runs the result through SHA-256, a function that converts any text into a 64 character fingerprint. The fingerprint is unique to that exact text, and the text cannot be recovered from it. Omo publishes only the fingerprint. Twenty minutes later it publishes the text, and anyone can run the same function on it and compare. Any change to the text, down to a single character, produces a different fingerprint.
Omo also documents the test. A file in the code lists the four things an outsider should be able to verify without holding the key. In the project’s words, the decision hash lands on chain before the fill exists, the revealed decision hashes to the published commitment, the fill names the mint the commitment named, and the fill is signed by the published wallet. In plain terms, the fingerprint came first, the text matches the fingerprint, the trade involved the right token, and Omo’s own key signed the trade. The key is the secret that authorizes a transaction from a wallet, so the fourth check asks whether Omo itself initiated the trade.
The same file states that a claim about process is only worth what an outsider can audit. These four checks are the project’s own standard rather than one I selected. The first three concern the chain and the fourth concerns the key.
5. Running the Check
I selected the oldest locked decision that had both a fingerprint and a trade attached to it. It concerns a token called CATE, decided on the morning of August 21st.
I started with the fingerprint. I copied the published record, which is 1,103 characters, and ran SHA-256 on it locally. The result matched the fingerprint Omo had published.
I then requested the transaction carrying that fingerprint from a public Solana server. It was there, confirmed one tenth of a second after Omo’s recorded decision time. That part of the claim holds. Someone with no access to Omo’s database can confirm the text existed at that moment.
The trade appears 14 hours and 46 minutes later, and it involves CATE. Three of the four checks pass. The results, using the project’s own list:
| Omo’s own check | Result | What I found |
|---|---|---|
| Text matches the fingerprint | Pass | Fingerprinted it myself, 1,103 characters, same result |
| Fingerprint posted before the trade | Pass | 14 hours and 46 minutes earlier |
| Trade touches the right token | Pass | CATE shows up in the token balances |
| Trade signed by Omo’s wallet | Fail | One signer, and it is not Omo’s wallet |
6. What It Got Wrong
First, the transaction Omo recorded as a trade was not a trade. It carries one signature from one signer, and that signer is not Omo’s wallet. Omo’s wallet is listed in the transaction but did not sign it. None of the exchanges Omo trades through appear in the transaction, and there is no purchase or sale in it. Five wallets appear in the token balances, Omo and the signer among them. Someone sent CATE to a group of wallets and Omo was one of the recipients. Omo received the token without buying it or signing for it, and its decision could not have caused the transfer. Omo’s own checker identified this correctly. It labeled the transaction “token transfer, no swap program” and published the failed check, as its security policy requires. The failure is upstream of that. Omo pairs a decision to a trade after the fact by searching for a trade in the same token within a few hours and taking the first match, and that search does not check signatures.
Second, the locked decision was not a decision the trading loop produced. The text is marked act, but two of the nine rules failed on it. Crowd heat came back at 20, below the floor of 25, and Omo already held $62,259.24 of CATE. The text carries no buy or sell direction, and the note records only that Omo was monitoring positions it already held. The trading loop cannot produce this, because it marks a decision act only when zero rules fail. The row came from a second piece of code that reads Omo’s public commentary, extracts a ticker from the prose, infers buy or sell from words like “bought” and “sold,” and locks that inference onto the chain. The nine rules are not applied. The record therefore contains both real gated decisions and reconstructions, which is why none of the 174 order commitments could be matched to a signed trade. Omo publishes these counts itself:
The verification scheme functions correctly. The records it is applied to are the problem.
Third, two of Omo’s four information sources had stopped returning data, and nothing in the system registered the failure. Every cycle log I read contains the same two lines, that the fomo feed is not answering and that the web search came back empty. I checked across the run and did not find a cycle where either source returned data. Both failures are documented in the code. The fomo board blocks server addresses, and a comment in Omo’s research file states that the workaround “gets through some of the time.” The search function returns an empty list whether the request failed or succeeded with no results, so nothing downstream can distinguish a broken sensor from a quiet market. This affects the crowd heat rule directly. When the board cannot be read the score floors at 20, and the rule requires 25, so it fails automatically. Some portion of the 505 passes came from a blocked feed rather than from judgment, and the proportion cannot be determined from the published data, because the model continued producing plausible explanations about price levels throughout. On August 31st Omo posted “i’m seeing things.” Its logs show two of its four inputs were returning nothing.
7. Methodology and Limitations
All sources are public. Omo’s code repository, its documentation, its data pages, its site, its posts, and the Solana chain. I read the source code rather than relying on the documentation describing it. For the CATE check I computed the fingerprint locally and retrieved both transactions from a public Solana server. Both are cited by block number in the Works Cited for anyone who wants to run the check again.
Several limitations apply. I selected Omo because it published a written rationale for every trade, which very few agents do, and that selection introduces a bias. The agent that volunteered to be audited is the one being audited. Agents that publish nothing cannot be examined this way at all.
I verified one decision out of 174. I chose the oldest one with both components attached. That is a defensible selection rule, but it is still a selection. Omo deletes its history on a schedule, so the verifiable window is small and shrinking, and it shrank during this work. On September 3rd the site would not load. I have not seen the system holding the signing key, and neither has anyone outside the project.
I found no evidence of deliberate misrepresentation. Every problem described here is documented somewhere in the code. The issue is distribution. The caveats sit in code comments, the dashboard shows the figures without them, and the two are rarely read together.
Auditability and Custody Are Different Problems
The file that defines the four checks also defines where the signing key lives, which is the custody question, meaning who holds the key that signs. The comment states that any custody arrangement capable of producing a signature will satisfy the interface, and lists them: “a local keypair, a remote signing service, an HSM, a hardware wallet.” An HSM is a sealed device that signs without releasing the key, and a hardware wallet is the consumer version of the same idea. The code below defines those four options. Omo used the first, a key copied out of a phone app and stored on a server.
One line in that file states the distinction this paper turns on. “Auditability and custody are different problems, and they are solved separately here.” The statement is accurate and it identifies the limitation directly. Omo made its decisions auditable without securing the key, and the key is where the design failed.
Ian Rogers at Ledger argued in March that tool access is asset access. Once an agent can use tools it can reach value, and the cost of trust has not fallen the way other costs have. Pascal Gauthier put it more bluntly, arguing that code cannot compensate for a weak physical trust boundary. Omo tests both claims. It is the most thorough attempt at agent verification I found, the engineering is competent, and the failure still occurred at the signing key, which is the one component software cannot vouch for on its own.
Hardware would not resolve as much here as that framing implies. A secure element would solve one problem, which is binding the signed trade to the locked decision. It would not affect the rest. It would not detect that search had been failing for days while Omo posted that it was seeing things, or that the win rate was 7.1%, or that an inbound transfer was recorded as a purchase. None of those are custody failures.
There is a second Ledger position worth raising here, which is keeping a human in the loop when agents transact. Omo has no such step. Nothing in its loop pauses for a person, and the disclosure page presents that as a design choice rather than a gap. A human approving each order would have caught an inbound transfer being recorded as a purchase, though it would also remove most of the reason to run an agent in the first place.
Hardware answers whether the agent was authorized to act. It says nothing about whether the agent was correct. Rogers argues that people will end up managing agents, which seems right to me. The open question is what to do with an agent that is authorized, verified, and wrong.
8. What It Would Need to Fix
The locking scheme worked. The records it was applied to did not hold up. The fingerprint was on the chain, the text matched it, and the trade followed almost fifteen hours later. The chain establishes that order. It does not establish causation. A different key signed the transaction and there is no purchase in it, so nothing on chain indicates that Omo’s decision produced it. None of this is a flaw in the cryptography. A timestamp and a cause are separate claims, and only the first is a mathematical question.
Three changes would close the gap, and the code already accommodates all three. First, sign trades with a key the agent controls, held in hardware, so that the fourth check can pass. Second, restrict the locking function to decisions the trading loop produced, so that reconstructions are never sealed. Third, stop trading when an information source fails rather than continuing on partial data. The fingerprint mechanism does not need to change. What it needs is a transaction the agent actually signed, for a token it actually bought.
- Gauthier, Pascal. “The Revenge of the Atoms.” Ledger, 13 Mar. 2026. ledger.com/blog-revenge-atoms
- Ledger. “Ledger’s 2026 AI Security Roadmap.” Ledger, 2026. ledger.com/blog-2026-ai-security-roadmap
- Ledger. “Ledger’s Guide to Agentic AI Security.” Ledger Academy, 20 May 2026. ledger.com/academy/topics/agentic-ai/agentic-ai-security-guide
- Omotrades. “Architecture.” GitHub, 2026. github.com/omotrades/omo/…ARCHITECTURE.md
- Omotrades. “How Omo Works.” GitHub, 2026. github.com/omotrades/omo/…PROCESS.md
- Omotrades. “meet omo.” X, 9 Aug. 2026. x.com/omotrades
- Omotrades. “omo.” GitHub, 2026. github.com/omotrades/omo
- Omotrades. “Public Data Pages.” omotrades.com, 2 Sept. 2026. omotrades.com/proof
- Omotrades. “Security Policy.” GitHub, 2026. github.com/omotrades/omo/…SECURITY.md
- Omotrades. “Verification.” GitHub, 2026. github.com/omotrades/omo/…VERIFICATION.md
- Rogers, Ian. “Security in the AI Agent Era.” Ledger, 17 Mar. 2026. ledger.com/blog-security-in-the-ai-agent-era
- Solana Foundation. “Solana Mainnet RPC.” Transactions in blocks 440641812 and 440786956, retrieved 2 Sept. 2026. api.mainnet-beta.solana.com
I certify that the research, analysis, verification, and conclusions in this paper are my original work. External claims and data are cited in the Works Cited. AI tools were used as a working and editing tool, and I reviewed and take responsibility for the final paper.
Charlie Sneed · September 4, 2026
