nestonexStart a project Plain definitions of the terms that come up when we explain what we have built, written by the people who built it. Every entry links to the project it came from.
Terms from execution engines, signal automation and market data.
How many price levels of an exchange's order book you receive. Level 1 is the best bid and ask only. L2 gives aggregated depth beyond it, and L20 means the top twenty levels each side. Deeper books let you estimate what a trade of a given size would actually cost.
Why it mattersDepth is what turns a quoted price into an expected fill. Trading off the top of book alone means every size assumption is a guess.
Checking that numbered updates from an exchange feed arrive without holes. Receiving update 41 then 43 means the local order book has missed a change and is now silently wrong. Detecting the gap and resyncing from a snapshot prevents acting on a book that no longer matches the venue.
Why it mattersThe trade is real even when the opportunity is not. This is how a latency-sensitive system loses money without ever throwing an error.
When an order executes for less than its full quantity. In a two-leg strategy where both sides are meant to execute together, a partial fill on one leg leaves an unintended directional position rather than the balanced trade that was intended.
Why it mattersThis is the scenario that turns a small edge into a large loss, and it needs an explicit recovery path: re-price to complete the pair, or unwind what filled.
An automatic halt triggered when a monitored metric crosses a threshold. Typical triggers are cumulative loss, latency and error rate, each able to stop trading independently of the others and without human intervention.
Why it mattersBugs in trading systems rarely surface as exceptions. They surface as unusual numbers, so a loss-based breaker catches a whole category of faults nobody anticipated.
The difference between the price you expected and the price you got. It comes from the market moving between decision and execution, and from your own order consuming available depth. On thin liquidity, a large order moves the price against itself.
Why it mattersA backtest that fills at the posted price is fiction. Modelling slippage is what separates a simulated return from a plausible one.
Adjusting an order to account for the gap between a broker's bid and ask. A signal quoting one entry price will fill differently at each broker, so a copier that ignores the spread places trades at prices the original never intended.
Why it mattersTwo accounts following one signal at different brokers should still end up with comparable trades. Spread compensation is how that stays true.
Reproducing another trader's positions on your own account, sized to your balance and risk settings. Mirror trading duplicates a position as-is; copy trading translates it proportionally, so a leader with a large account does not push a disproportionate position onto a small one.
Why it mattersThe sizing step is the entire difference between a usable product and a way to liquidate your followers.
Derivative contracts that track an asset's price with no expiry date, held open indefinitely and kept near spot by periodic funding payments between long and short holders. They are traded with leverage, so positions carry margin requirements a spot trade does not.
Why it mattersExecution has to understand margin rather than treating every fill as spot, which is a different code path, not a setting.
A trading signal specifying several entry prices rather than one, intended to be filled as separate orders that average into a position. Handling it means deciding how to split size across the entries and what to do when only some of them fill.
Why it mattersTreating a multi-entry signal as one order at the first price is the most common way an automated copier diverges from the signal it is following.
A stop-loss that moves with the price in your favour and stays put when it moves against you, locking in gains without capping them. The distance is set as a fixed amount or a percentage from the best price reached since entry.
Why it mattersTrailing behaviour belongs to the account, not the signal. Two followers of the same call can reasonably want different trailing rules.
Replaying a strategy against historical data to estimate how it would have performed. Useful only when the simulation includes the costs a real position would have paid, particularly slippage, fees and the order in which information actually became available.
Why it mattersMost backtests flatter the strategy because they quietly assume perfect fills and perfect hindsight about which trades to take.
Using decimal arithmetic rather than binary floating point for prices, sizes and balances. Floating point cannot represent most decimal fractions exactly, so small representation errors accumulate across operations until a computed value is no longer the value.
Why it mattersIn ordinary software that is a rounding curiosity. In a system computing spreads and position sizes it is money, which is why the price path should contain no float at all.
Terms from multi-chain wallet backends, swaps and on-chain settlement.
A design where the service never holds the user's private keys. It cannot move funds, cannot freeze an account, and has nothing to lose in a breach. Responsibility for the key sits with the user, which makes export and recovery paths part of the product rather than an afterthought.
Why it mattersThe real test is whether a user can export their key and leave. A service that cannot let them do that is custodial regardless of what it claims.
A wallet created and managed for the user inside an application rather than through a separate browser extension, without the service taking custody of the key. It removes the seed-phrase step that loses most new users while keeping the wallet genuinely theirs.
Why it mattersIt is the main way a consumer crypto product can be non-custodial without asking someone to understand key management before their first transaction.
A wallet where the user describes an outcome and the system works out the transaction, rather than the user assembling it themselves. The intent is an explicit typed object, validated against a schema before anything is signed, which is what makes it safe to generate from natural language.
Why it mattersThe typed intent is the whole safety mechanism. Without it you are letting free text reach a signer.
Quoting several decentralised exchanges or routers for the same swap and executing through whichever offers the best outcome. Aggregators may also split one trade across multiple venues when that returns more than any single route would.
Why it mattersNo aggregator wins every pair. Integrating only one quietly gives up value on every trade it happens to be worse at.
The swap path that leaves the user with the most after all costs, rather than the one advertising the best headline rate. A quote ignoring gas and aggregator fees can lose to a nominally worse rate, especially on smaller trades where fixed costs dominate.
Why it mattersComparing headline rates is the most common way a wallet appears to optimise routing while actually handing users a worse result.
A token approval standard that lets a user sign a message granting a time-limited, amount-limited spending permission instead of sending a separate on-chain approval transaction for every token and every spender.
Why it mattersIt removes a whole class of friction and a whole class of risk: no gas for approvals, and no unlimited allowances left sitting on contracts forever.
Authorising a contract to spend tokens by signing a message rather than submitting a transaction, so the user pays no gas for the permission itself. The approval is carried and submitted as part of the action that needs it.
Why it mattersPaying a fee to grant permission to pay another fee is the kind of step that loses users between intention and completion.
The fungible token standards on Ethereum, BNB Chain, TRON and Solana respectively. ERC20 and BEP20 are closely related; TRC20 follows the same shape on a different execution model; SPL works quite differently, using token accounts rather than balance mappings on the token contract.
Why it mattersThey look interchangeable and are not. Each needs its own transfer adapter, and native SOL behaves differently again from the SPL tokens beside it.
A wallet whose keys are held online so it can sign transactions automatically, used where a system needs to pay out without a human present. The trade-off is that anything able to reach the signer can spend, which makes every signing moment an exposure window.
Why it mattersBatching payouts and gating release behind approval both exist to reduce how often the hot wallet is actually in use.
Keeping transaction sequence numbers in order per account and per chain. Ethereum-style chains require strictly increasing nonces, so two transactions submitted concurrently with the same nonce mean one is dropped and everything behind it stalls.
Why it mattersIt is the on-chain version of a race condition, and it shows up the moment a backend serves more than one action per account at a time.
A mechanism for moving value between blockchains that cannot talk to each other directly, usually by locking or burning on the source chain and releasing or minting an equivalent on the destination. Settlement is asynchronous and can take minutes.
Why it mattersThe delay is the hard part. A bridge in flight is value that exists in neither place, and the system has to represent that state honestly.
Buying a fixed amount on a fixed schedule regardless of price, so the average entry smooths out over time rather than depending on a single decision. In a wallet it runs as a recurring scheduled job against the user's balance.
Why it mattersBecause it is scheduled rather than user-initiated, it competes with manual actions for the same balance, which is why it belongs behind the same sequencing as everything else.
Reading blockchain events and building them into a queryable database, because chains are optimised for consensus rather than for questions like which wallets bought a token in a given hour. An indexer follows new blocks and backfills history.
Why it mattersChain events arrive more than once, through reorgs and retries, so an indexer that is not idempotent will double-count sooner or later.
Acting on knowledge of a pending transaction or announcement before it becomes public, typically by buying a token just before a call is published and selling into the demand it creates. On-chain it is measurable, because transaction timing is recorded.
Why it mattersWallet timing against publication time turns a suspicion into evidence, which is the only way a performance leaderboard means anything.
Terms from retrieval systems, agents and production language-model features.
Answering with a language model over documents you supply rather than only what it memorised. Relevant passages are retrieved from your corpus and placed in the prompt, so the answer is grounded in source material that can be cited and checked.
Why it mattersRetrieval quality decides the answer. Most RAG systems fail at chunking and ranking, not at generation.
Splitting documents into passages small enough to retrieve precisely and large enough to carry meaning. Splitting on word boundaries rather than fixed character counts avoids cutting words in half, and overlapping adjacent chunks keeps a fact that straddles a boundary retrievable.
Why it mattersA fact split across two chunks with no overlap is retrievable from neither. It is the least glamorous parameter in RAG and one of the most consequential.
Numeric vectors representing text so that similar meanings sit close together in the space. Comparing two vectors then approximates comparing two meanings, which is what makes semantic search possible without matching exact words.
Why it mattersWorth keeping a keyword baseline alongside them. If embeddings are not beating TF-IDF on your corpus, that is important to find out early.
Scaling every vector to unit length. Cosine similarity divides the dot product of two vectors by the product of their magnitudes, so once both magnitudes are 1 that division does nothing and similarity reduces to a plain dot product.
Why it mattersNormalising once at write time removes work from every query afterwards, and it is most of the reason a dedicated vector database is optional at modest scale.
Where embeddings live and are searched by similarity. It can be a dedicated database, or for smaller corpora simply an in-process array searched with one matrix operation. Metadata such as source and offset is kept alongside each vector.
Why it mattersA dedicated vector database earns its place when the corpus outgrows memory or needs concurrent writers, not by default.
A keyword ranking method that scores a term by how often it appears in a document against how rare it is across the whole corpus. It has no semantic understanding, but it is fast, transparent and requires no model.
Why it mattersIts value now is as a control. It tells you whether your embeddings are actually earning their cost on your particular corpus.
Requiring a model to answer in a fixed machine-readable shape validated against a schema, rather than in free text you then parse. Output that fails validation is rejected or retried rather than interpreted optimistically.
Why it mattersIt converts a model from something you have to read into something you can check, which is the precondition for letting its output reach anything consequential.
Sending each step of a pipeline to the cheapest model that can handle it, reserving the strongest model for the work that genuinely needs it, and tracking spend per step against a budget.
Why it mattersMost steps in a pipeline are mechanical. Paying premium rates for all of them is what makes AI features uneconomic and gets them switched off.
Constraints on what a model-backed feature is permitted to do or say, enforced in the system rather than requested in the prompt. Typical forms are refusing categories of output, capping spend per user, and restricting the actions a model can trigger.
Why it mattersA guardrail written only into a prompt is a preference. A guardrail enforced in code is a guarantee.
Instructions smuggled into content a model reads, designed to override what it was told to do. Because a model cannot reliably distinguish its instructions from the data it processes, any text reaching it should be treated as potentially adversarial.
Why it mattersThe defence is architectural, not linguistic. If the model can only propose, and a validator decides, an injection produces a rejected request instead of an action.
Giving a model a fixed set of functions with validated arguments rather than letting it produce free-form actions. The model selects a tool and supplies parameters; the system validates them and decides whether to run it.
Why it mattersIt means there is no privileged path for the model. A tool call runs the same checks as the equivalent action taken by a human in the interface.
A fixed collection of inputs with known-good outputs, used to measure whether a change to a model-backed feature made it better or worse. Without one, quality is a matter of opinion and regressions are invisible until a user finds them.
Why it mattersThis is the step most teams skip and the one that decides whether an AI feature survives its first year.
A design where a person reviews or approves model output before it takes effect. Not a lack of confidence in the model, but an acknowledgement that the cost of a rare bad output can far exceed the cost of a review step.
Why it mattersThe general form is that the model proposes and something else decides. That something else can be a person or a validator, but it should not be the model.
Assessing more than one kind of input together, such as grading a video answer on its transcript and on frames sampled across the recording. Each modality carries information the other loses.
Why it mattersDelivery and presence do not survive transcription, so a text-only assessment of a presentation is measuring half of it.
Letting a caller interrupt a voice agent mid-sentence and having it stop immediately. It requires tracking call state so the system knows what is currently playing and can cut it as soon as inbound speech is detected.
Why it mattersPeople interrupt constantly without noticing. An agent that talks over an interruption stops feeling like a conversation and starts feeling like a recording.
Terms from multi-tenant platforms, reliability patterns and API design.
Writing an event into the same database transaction as the change that caused it, then publishing it from there with a separate process. Either the change and the event both happen or neither does, which removes the window where one exists without the other.
Why it mattersWriting to a database and then publishing an event is two operations that can disagree. On a platform that moves money, a dropped event is a missing invoice.
A property where performing an operation more than once has the same effect as performing it once. Achieved by recognising a repeat, usually through a key or by checking whether the resulting state already exists, and settling to the same outcome.
Why it mattersRetries, replays and blockchain reorgs all deliver the same message twice. A handler that assumes exactly-once delivery will double-credit something eventually.
A buffer between producing work and doing it, so slow or failure-prone operations run outside the request that triggered them. Failed jobs can be retried without the user seeing an error or waiting for the outcome.
Why it mattersDoing provisioning or payouts inside a request makes the user wait and turns a transient failure into a visible one.
When the result depends on the order of concurrent operations. The classic case is two requests reading the same balance before either writes, so both believe the funds are available and the system spends money it does not have.
Why it mattersIt appears under load and disappears when you look for it, which is why the fix has to be structural rather than a retry.
Processing one account's operations strictly one at a time inside a transaction, while different accounts still run in parallel. It removes races within an account without serialising the whole system.
Why it mattersScope the lock as narrowly as correctness actually demands. A global lock is equally correct and caps the entire platform at one worker.
One deployment serving many customers whose data must stay separate. The separation is either logical, with a tenant column in shared tables, or physical, with a database per tenant. The first is cheaper to run, the second harder to breach.
Why it mattersA shared database with a tenant column is one forgotten WHERE clause away from a cross-tenant leak. Whether that risk is acceptable depends on what the data is worth.
Standing up a fully branded instance of a platform for a new operator without manual setup, including its database, its domain and its branding, so onboarding is a request rather than a project.
Why it mattersIt is what separates a business-in-a-box from a reseller account. The operator's own customers should never encounter the platform underneath.
Granting permissions to roles rather than to individuals, so what someone can do follows from what they are. In a marketplace a buyer, a vendor and an administrator read the same records through different permitted slices.
Why it mattersEnforce it at the API, not in the interface. A hidden button is not a permission.
Attaching a cryptographic signature to each API request, computed from the request contents and a shared secret. The server recomputes it and rejects anything that does not match, proving both who sent the request and that it was not altered in transit.
Why it mattersIt proves origin and integrity. It does not prove freshness, which is why signing alone is not enough on an endpoint worth attacking.
Preventing a captured request from being sent again later. Each request carries a one-time value with a short validity window, stored so a repeat is recognised and rejected even though its signature is perfectly valid.
Why it mattersSigning proves a request was genuine. Replay protection proves it was meant now, which is the difference on any endpoint that changes state.
Capping how many requests a caller can make in a window, usually per user and per IP address. It protects against abuse, runaway clients and cost exposure on endpoints whose work is expensive to perform.
Why it mattersOn anything billed per call, including AI features, a cap per user per day is what makes the worst case predictable rather than unbounded.
A machine-readable description of an API's endpoints, parameters and responses. It generates clients and documentation, and gives separate teams one agreed contract to build against rather than a shared assumption.
Why it mattersWith several clients on one API, the spec is what stops each drifting toward its own idea of how the backend behaves.
Modelling something that changes over time as a fixed set of states with explicit permitted transitions between them. An order moves from placed to accepted to delivered, and any transition not defined is simply impossible rather than merely unexpected.
Why it mattersWhen several parties update the same record concurrently, a state machine makes an entire class of invalid state not exist instead of being rare.
An HTTP request one system sends to another when something happens, instead of the second system repeatedly asking. The sender posts a payload to a URL you registered; your endpoint verifies the signature, records the event, and responds quickly so the sender does not retry.
Why it mattersEvery webhook arrives at least once and sometimes more, out of order, from a sender that will give up if you are slow. Treat the handler as a queue intake, not as business logic.
Enforcing which rows a query may see inside the database itself, using policies tied to the current user or tenant, rather than relying on every application query to add the right filter. A missed filter returns nothing instead of returning someone else's data.
Why it mattersApplication-level tenant filtering works until one query forgets. RLS turns a leak into an empty result, which is the failure you want.
Replacing a system gradually by routing traffic for one capability at a time to new code, while the old system keeps serving everything else. The new implementation grows around the old one until nothing is left routed to it, and it is switched off.
Why it mattersIt is how a rebuild ships value in month one instead of month nine, and how you keep the option to stop. Big-bang replacements remove both.
Terms from multi-vendor platforms, split settlement and onboarding.
Dividing a single customer payment between the platform and one or more vendors at the moment it is taken, rather than collecting everything centrally and transferring shares out later.
Why it mattersSplitting at the payment layer avoids holding everyone's money in one pot, which is both an accounting burden and a regulatory question most platforms would rather not answer.
A payment account created for a vendor or contractor within a platform's payment provider, owned by them but administered through the platform. It is what allows funds to reach them directly rather than passing through the platform's own balance.
Why it mattersIt moves the compliance burden to the provider, which is usually the correct place for it.
A check that a recipient is permitted to receive funds before a transfer is attempted, typically confirming that onboarding and identity verification are complete and the account is in good standing.
Why it mattersWithout it the failure surfaces at payout, after the work is done and the person is expecting money. With it the failure surfaces during onboarding, where it can still be fixed.
Verifying the identity of a user or vendor, usually through identity documents and business registration checks, before allowing them to transact or receive payouts. It can be manual, automated, or a mix with review for exceptions.
Why it mattersIt is normally the bottleneck between signing up and being able to trade. Automating the document check is often the single biggest lever on vendor activation.
A platform serving three distinct groups whose needs differ but whose transactions are the same, such as diners, restaurants and riders. Each side has its own onboarding, its own permissions and its own view of a shared record.
Why it mattersForcing all three through one signup flow makes it wrong for everyone. Separate front doors over a shared API is usually the right shape.
How a platform takes its share: a percentage of transaction value, a fixed fee, a subscription, or a combination. It determines whether platform revenue scales with vendor success or with vendor count.
Why it mattersCommission on transaction value ties the platform's incentives to its operators actually earning, which is why the payout path has to be correct.
A single record of every credit and debit against a balance, so what someone is owed has one authoritative answer. Earnings from unrelated subsystems all post to it rather than accumulating in separate places.
Why it mattersReconciling a payout across three separate balances becomes guesswork the moment any of them disagree, and one of them eventually will.
Terms from design systems, internationalisation and front-end delivery.
Building an interface so it mirrors for right-to-left languages such as Arabic, Hebrew and Urdu. The whole reading order reverses: navigation, alignment, directional icons and back buttons all flip, while numbers and forward-moving progress indicators generally do not.
Why it mattersDirection is a layout concern, not a translation concern. Translated text inside a left-to-right layout reads as broken to a native speaker.
Internationalisation is building software so it can adapt to any language, region and format. Localisation is the adaptation itself: the translations, the currency, the date formats. The first is engineering, the second is content.
Why it mattersRetrofitting internationalisation is expensive because it touches every component. Adding a localisation to software already internationalised is comparatively cheap.
A shared set of components, tokens and rules that an interface is assembled from, so the same decisions are not remade per screen. It covers spacing, type, colour, states and behaviour, not just how things look.
Why it mattersIts real value shows when something global changes, such as adding a second language direction or a new theme, and the change happens in one place.
Generating pages as HTML at build time rather than rendering them in the browser on each visit. The server sends complete markup, so content is present before any JavaScript runs.
Why it mattersPages meant to be found through search should not depend on client-side rendering to produce their content. Application routes behind a login can.
Verifying a user with a single-use code sent to a phone number or email, either instead of a password or alongside one. It proves the person controls that contact channel at the moment of signup.
Why it mattersFor travel and delivery products the phone number is not an account detail, it is how someone gets reached when a booking changes.
Defining validation rules once and running them on both the client and the server, rather than writing two copies. The client copy gives immediate feedback; the server copy is the actual enforcement.
Why it mattersTwo separately written copies drift, and the failure mode is a form that passes in the browser and is rejected after payment.
Showing the result of an action immediately, before the server has confirmed it, then reconciling when the response arrives. The interface assumes success, and has to be able to roll back visibly and honestly when the assumption turns out to be wrong.
Why it mattersIt is the right default for a like button and the wrong one for a transaction. Anything involving money should show pending as pending.
Google's three measured page-experience metrics: Largest Contentful Paint, how long the main content takes to appear; Interaction to Next Paint, how quickly the page responds to input; and Cumulative Layout Shift, how much content moves while loading. Field data comes from real visits, not a lab run.
Why it mattersLab scores flatter a site. Only field data reflects the devices and networks your audience actually has, and it is the field data that counts.
A web application that runs inside Telegram with the user's identity already established, launched from a bot or a link. There is no store review and nothing to install, and the app can use Telegram's own theme, payment and sharing surfaces.
Why it mattersThe distribution advantage is real and the platform ceiling is too. It suits screens and checkouts; it does not replace an app that needs background work or device access.