Prediction-market arbitrage
Live · traded
Every trade is a confirmed transaction on the public blockchain. Buying in this lane is supervised by the execution authority.
Traction & technology
What runs, what is built, and what we refuse to claim.
Nevarn is the back office for trading bots and agents. Its traction is presented the way its books are kept: exact, checkable, and stated before anyone has to ask. The strongest evidence in the product is the part that requires no trust in us.
The split with Decionis
Decionis decides. Nevarn operates — and proves it.
For teams running trading bots or AI agents with on-chain money, Nevarn is the back office that runs strategies under outside rulings from Decionis, signs only inside a bounded mandate, and keeps one double-entry book reconciled against the public chain. Unlike wallet vendors, custodians, bot platforms or crypto accounting tools, Nevarn joins the ruling, the signature and the book in one system.
| Decionis | Nevarn | |
|---|---|---|
| Question it answers | Was this action allowed? | Did exactly that happen, on every ledger the money touched, and where is the money now? |
| Owns | Mandate format, policies, rulings, proof of decision | Strategy runtime, venue adapters, delegated signing, multi-ledger books, proof of execution |
| Sells to | Any industry with high-stakes actions | Teams running trading bots and AI agents with on-chain money |
| Relationship | Supplier | A paying Decionis customer and its live reference deployment |
Nevarn does not compete with Decionis on policy or proofs: the mandate format, the policies, the rulings and the proof of decision are Decionis’s. Decionis decides; Nevarn runs the strategy, signs inside the mandate and keeps the books.
The record, counted from the chain.
Every trade is a transaction on the public blockchain, so the count does not rest on our database — which is exactly why this is the number we publish. Anyone can check them on the public blockchain, or on the wallet's Polymarket profile, without Nevarn's cooperation.
119
On-chain trades
87 buys and 32 sells since March 2026; the most recent on 18 Jul 2026, counted 1 Nov 2026.
29
Distinct markets
Traded at one venue over the period.
9
Positions held
All on markets that have resolved and await redemption; none on a live market.
4
Strategy lanes
One traded live; three built, running, and yet to trade.
The trading wallet is public: check every trade on Polygonscan, its Polymarket profile or its Dune dashboard. Trade-level economics and reconciliation history are shared with qualified parties through the data room. The public figure is deliberately the conservative one. Figures as of 1 Nov 2026.
Strategy lanes
One lane trading. Three holding their fire.
On-chain arbitrage, including flash loans
Deployed · yet to trade
The engine quotes continuously against real prices from two major venues; every candidate so far has been rejected as insufficiently profitable. The executing contract is deployed and verifiable on Ethereum, completes borrow–trade–repay in a single transaction, refuses to finish unless the trade covers its own borrowing cost, and carries an owner-only pause. It has never been used — the engine declining to trade unprofitably, not a failure to build it.
Contracts & currencies
Built · simulated
A complete strategy and venue integration running against a simulated account, with no live credentials configured. Its execution gate is built and tested, currently switched off.
Position tracking & cash-out
Built · minimal exposure
Watches for positions worth settling and maintains a running plan, so disposals are deliberate rather than improvised.
The execution authority
A strategy must ask before it acts.
Before a live order is placed, Nevarn assembles a description of the trade — market, direction, size, the price it is seeing and how stale that price is, collateral, open positions — and submits it to Decionis, an independent execution authority, for a ruling. Four answers can come back: proceed, refuse, refer to a person, or hold. Only proceed releases the trade.
- Unreachable means refused. An outage stops trading rather than quietly removing the guardrail. That is how the live configuration is set.
- An approval binds one exact trade. When an approved instruction reaches the venue it is independently re-checked against the approval it carries. Change any parameter and it no longer matches.
- The authority never sees raw identifiers. Wallet addresses, account references, balances, and timestamps are replaced with consistent stand-ins before the description leaves us — enough to judge the trade, and no more.
Where the gate is armed today
Prediction-market arbitrage — buying
EnforcingPrediction-market cash-out — deliberate selling
Same authority & configurationContracts and currencies, incl. position exits
Built & tested · switched offTreasury movements between venues
Built & tested · switched offUCP machine checkout — discovery & x402 settlement
Built & tested · feature-gatedSupplier payments
Built & tested · switched offMerchant sweeps to the wallet
Built & tested · switched offOn-chain arbitrage, including flash loans
Not yet gatedAutomatic redemption of resolved positions
Shadow · awaiting policy releaseSettlement of cleared proceeds
Shadow · awaiting policy releaseTreasury routing between venues, chains and wallets
Shadow · awaiting policy releaseVenue adapters — Nevarn's own lanes
Shadow · awaiting policy releaseWithdrawals — payout partners and runtime sends
Shadow · awaiting policy releaseBeing precise about this matters more than being impressive about it: buying and deliberate cash-out in the prediction-market lane are supervised; the automatic redemption, settlement, and arbitrage paths are not yet. The gate has genuinely run against the live decision service and genuinely stopped real orders — proven as a mechanism, not yet at volume. Referred trades in this lane land in a working review queue; extending the gate to the automatic paths, and the queue to every lane, is the first thing new capital funds.
Authority envelope · live
Authority
Inside your limits
Decision
Approval or refusal
Record
Balanced in the books
Custody & permissions
The money and the machinery are separate.
Two accounts, not one
A customer's wallet holds their money; a separate working balance is what Nevarn may act on. Whatever stays in the wallet is out of our reach no matter what happens to the company. The amount moved across is the amount at risk — and the customer chooses it.
We never hold a customer's key
Where Nevarn signs on a customer's behalf, it does so with a limited permission their own account has been told to accept — held encrypted. Only the customer installs a permission, and only the customer can remove it; once revoked, their account refuses our signature regardless of what our records say.
Every permission is bounded four ways
The specific places it may act, the specific actions it may take, a ceiling per transaction with a rolling daily limit, and an expiry of at most ninety days. A permission cannot be created without an allowlist, and a missing limit denies rather than permits.
Stopping is immediate and destructive
One action halts all signing on an account, effective on the next request — not a support ticket. Revocation deletes the material that could produce a signature, rather than marking a row inactive.
Books & observability
Records that cannot be made to not add up.
Two halves or nothing
Every movement of money is written as two matching entries, and the system physically rejects any record whose halves do not cancel. Amounts are held exactly; a repeated notification is counted once.
Balances are recomputed, not stored
No balance is a number someone typed. Each is derived from the underlying records every time it is shown, so the figure and its evidence cannot drift apart.
Disagreement is displayed
What our records say is shown beside what the account actually holds on the blockchain, with the difference. We never quietly correct ourselves to make the two agree — that would destroy the only evidence that something happened.
Refusals are first-class records
Every request our automation makes is written down with its outcome and, where refused, the reason. A run of refusals surfaces as a warning rather than as silence.
Operating as a platform
Built to carry more than one customer.
The multi-customer platform — isolation, permissions, scheduling, and books — is built and verified on every release. In use by its first customer tenant since September 2026.
Tenant isolation, enforced twice
A request for another customer's holdings, records, or permissions is answered as though the account does not exist — by the application, and again by the database, where row-level security fences every table keyed to a customer. Every release re-checks both: an end-to-end run signs in as a second customer and confirms refusal across every surface, a test fails the build if a customer table is left unfenced, and the production release stops unless the API's database connection is bound by the fence.
Nothing spends money by accident
Any job that can move real funds must be both switched on and separately confirmed for live operation. Both start closed; refusing to act is the default everywhere.
Three hostnames, one hard boundary
The public site, the tenant console, and operator tooling are separated by host routing that fails closed. The public domain serves no signed-in surface and no operational API at all.
A gated production cutover
Production moved to its current infrastructure on 29 September 2026 as a sequence of deliberate, individually receipted steps — refusing to copy into a non-empty destination, fingerprinting every record before and after, re-encrypting key material and verifying it against signer addresses recorded on the blockchain, never deleting the original.
Security posture
Attacked by us, before anyone else.
In August 2026 we ran an adversarial security review across every application, the contracts, and the delivery pipeline — scoped to custody, risk controls, and the attack surface an internet-facing money system actually presents. Its findings shipped as fixes, not as a report.
- Authenticated operator surfaces with server-side session revocation
- Host routing that fails closed on unrecognised or forged hosts
- Strict content security policy — script hashes on the static public pages, a per-request nonce on the signed-in hosts — and hardened response headers
- Rate limiting on authentication endpoints and audited auth events
- Least-privilege CI with pinned actions and secret scanning on every change
- Spend policies that decode calldata — recipient and amount, not just a signature
The stack
Execution
Python agent services for strategy, accounting, and workflow state
Control plane
Next.js treasury and operator console behind host-isolated surfaces
On-chain
Execution contract deployed and source-verifiable on Ethereum
Rails
Bitcoin, Ethereum, and Polygon under treasury routing today
Plain answers
The questions that decide trust.
Does Nevarn hold customers' private keys?
No. A customer's wallet stays theirs; Nevarn acts only on a separate working balance, under a limited permission the customer's own account has been told to accept. The permission is scoped to named venues and actions, capped per transaction and per day, and expires within ninety days. Revoking it destroys the material that could produce a signature.
How does a customer stop Nevarn?
One action halts all signing on the account, effective on the next request — not a support ticket. Separately, only the customer can remove a permission, and once revoked their account refuses Nevarn's signature regardless of what Nevarn's records say.
What happens if Nevarn's decision service goes down?
Trades are refused. Every live buy order in the gated lane needs an explicit proceed ruling from Decionis, a separate execution authority; if that authority cannot be reached, the order is not placed. An outage stops trading rather than removing the guardrail.
Can Nevarn's trading record be verified independently?
Yes. Since March 2026 the trading wallet has made 119 trades (87 buys, 32 sells) across 29 markets, each a confirmed transaction on the public blockchain; the most recent was on 18 July 2026 (counted 1 Nov 2026). It still holds nine positions, all on markets that have resolved and await redemption; none is on a live market. Anyone can check them on the public blockchain, or on the wallet's Polymarket profile, without Nevarn's cooperation. That trade count, not an internal volume figure, is the number Nevarn publishes.
Is Nevarn regulated?
Not yet, and it says so plainly. Nevarn is built with the properties supervised environments expect — bounded mandates, pre-trade rulings, fail-closed defaults, recorded refusals, double-entry books — but it holds no regulatory licence today.
Stated in advance
What we do not claim.
Written here so nobody has to discover it in diligence.
- No trading history for the on-chain arbitrage lane. The contract is deployed and has never found an opportunity clearing its floor.
- No mining, staking, or validator revenue. Rehearsal figures once produced by declared inputs have been cleared, the component now refuses them, and the category is not part of this business.
- No claim that referred trades reach a human in every lane. The live lane's referrals land in a working review queue — releases, rejections, an audit trail; escalations from the contracts lane are recorded but do not yet reach a reviewer.
- No volume quoted from our own position records. The trade count on the public chain is the figure we use.
If this is the kind of precision you want in an early-stage digital-asset company, the investor brief goes deeper.
Investor & partner portal