“Pending”, “sent”, “confirmed” and “filled” often appear on the same screen, and it is easy to read them as steps on one ladder. They usually describe two different things. An order has a lifecycle on a trading venue: it is accepted or rejected, may rest in a book, may fill in parts, and may be canceled. A blockchain transaction has its own lifecycle: it is signed, submitted, processed, confirmed, finalized, or it fails or never lands. A record that mixes the two can show a trade that never happened, or miss one that did.
Two state machines, two kinds of evidence
An order state answers a trading question: did the venue match my instruction against another order, at what size and price? A transaction state answers a ledger question: did the network include my signed transaction, did it execute without error, and how settled is that record now?
Sometimes one depends on the other. An on-chain swap can only execute if its transaction executes. Sometimes they are almost unrelated: a deposit transaction moves collateral to a venue, and the orders placed later have their own identifiers and statuses. Either way, a status from one machine is not evidence for the other. A finalized deposit does not prove an order filled, and an order marked filled does not prove a withdrawal has settled.
The order lifecycle on a venue
Venues name their states differently, so read the specific documentation. Hyperliquid’s exchange-endpoint documentation is a useful example. A placed order returns a per-order result inside a list of statuses. Its examples show a resting result carrying an order ID (oid), a filled result carrying a total size, an average price and the oid, and an error result with a message. One example error response still has a top-level status of “ok”, so the request being accepted is not the same as the order succeeding. Read the per-order entry.
The same documentation lets an order carry an optional client order ID (cloid), a 128-bit hex string you choose before submission. Hyperliquid’s order-status query accepts either the oid or the cloid and returns the order with a status and a status timestamp. Listed values include open, filled, canceled, triggered and rejected, plus many specific reasons: canceled for insufficient margin, canceled by self-trade prevention, canceled because of liquidation, or rejected for an invalid tick price or a lack of liquidity for a market order. An order that cannot be found returns an unknown-order response.
A partial fill deserves extra care. A status label can describe the order while its quantity tells a different story: some size may have executed while the rest still rests or was later canceled. Reconcile executed size, price and fee from the venue’s fill records rather than inferring them from one status word. The order-type guide explains why a limit, market or trigger instruction can lead to different outcomes.
The transaction lifecycle on a chain
On Solana, a wallet builds a transaction, the user signs it, and it is sent to the network. Fees are paid in SOL. If the transaction is included, an RPC node can report it at increasing commitment levels: processed, confirmed and finalized, with finalized the strongest. A transaction can also execute with an error, which may still cost a fee, or never be included at all and expire. How Solana transactions work walks through signing, fees and confirmation, and the guide to pending, confirmed and finalized status compares how Bitcoin, Ethereum and Solana use similar words for different things.
The identifier here is a transaction signature on Solana, or a transaction hash on other chains. It identifies a record; it is not proof of payment or of a trade on its own. The explainer on what a transaction hash identifies covers that distinction. To look one up, check a Solana signature on the right cluster and read its status and any error.
Why “sent” or “pending” is not a fill
A wallet that says “sent” usually means a signed transaction left the wallet. It has not yet told you whether the network included it, whether it executed, or what it bought. A swap interface showing “pending” is in the same position: the trade has not happened until the transaction executes successfully, and the received amount is whatever the executed transaction actually delivered within its limits. If a swap appears stuck, the guide to a Jupiter swap that is pending or failed explains what to check before retrying, so a second attempt does not create a duplicate trade.
The reverse confusion also happens. On a venue, a submitted instruction can be accepted at the request level yet rejected at the order level, or rest unfilled for hours. “Submitted” describes your action, not the market’s response.
A fictional reconciliation
Consider a fictional trader who deposits stablecoin collateral to a venue and then places a limit buy. All identifiers and times below are invented.
| Time (UTC) | Event | Machine | Status observed | What it proves |
|---|---|---|---|---|
| 09:00:05 | Deposit signed | Chain | Signature returned | A transaction was created and sent |
| 09:00:20 | Deposit checked | Chain | Finalized, no error | The transfer is recorded on the network |
| 09:02:10 | Venue balance | Venue | Collateral credited | The venue applied its own crediting step |
| 09:05:00 | Limit buy, cloid 0xA1… | Venue | Resting, oid 4411 | The order is live, nothing executed |
| 09:40:00 | Same order | Venue | 0.6 of 1.0 executed | A partial fill, not a full position |
| 10:00:00 | Remainder canceled | Venue | Canceled | Final size is 0.6 at the recorded fills |
Only the venue’s fill records show what was bought. Only the chain record shows the deposit landed. The credit step in between belongs to the venue, which can apply its own rules after the network has finalized a transfer.
What to record in a trading journal
For each order: venue, instrument, side, original size, limit or trigger price, your cloid if you set one, the venue’s oid, submission time, every status with its timestamp, and each fill’s size, price and fee. For each transaction: chain and cluster, signature or hash, the commitment level you observed and when, any error, the fee paid and the resulting balance change. The guide to reading a transaction in an explorer shows which fields carry that evidence and what they cannot prove.
Setting a client order ID before submission is useful because it links your own note to the venue record even if the response is lost. A trading journal template can hold both columns side by side. Simulated records belong in their own column too: SuperQuant’s included examples use synthetic hourly data and modeled fills, it does not place live orders, and it does not verify live execution. The comparison of paper and live trading explains why a modeled fill and a venue fill are different evidence.
Keep learning
The Using Solana academy track builds the transaction side step by step, from signing to explorer checks. For the trading side, pair it with how limit and market orders differ and keep both identifiers in every journal entry. This is educational research context, not investment advice.