DEV Community: Christian Pichichero

Why a Scheduler Cannot Trust Its Own Database

Christian Pichichero — Thu, 15 Oct 2026 18:40:43 +0000

If your scheduler submits transactions, its database is not a record of current chain state. It is a local projection assembled from RPC reads, transaction submissions, receipts, logs, and assumptions about what happened between those events.

That projection is useful. Scheduling would be impractical if every decision required rebuilding state from chain history. But the projection is always slightly wrong. The important engineering question is not whether it becomes stale; it is how the system behaves when it does.

There are two failure directions: stale-permissive state and stale-restrictive state. They have different costs and need different controls.

The database is authoritative about intent, not chain facts

A scheduler can authoritatively say, “I created this job,” “I attempted this transaction,” or “I assigned this idempotency key.” Those are facts owned by the application.

It cannot authoritatively say, “This wallet still has enough balance,” “This nonce is unused,” “This contract remains unpaused,” or “That transaction is final.” Those are chain facts. The database can cache observations of them, but an observation has a block context and an age.

Even an RPC read is not an timeless answer. A read against a recent block can be displaced by a reorganization. Different RPC nodes can briefly disagree. A transaction visible in the pending pool may disappear, be replaced, or execute with different surrounding state than the scheduler expected.

Treating cached chain data as ordinary application state hides all of this uncertainty.

Stale-permissive: the database says yes

Stale-permissive state means the local model allows an action that current chain state rejects or makes unsafe.

Common examples include:

A cached balance still includes funds already spent elsewhere.
A nonce has been consumed by another transaction.
An authorization was removed after the last sync.
A contract parameter changed, invalidating the scheduler’s assumptions.
A previous transaction succeeded, but the local worker timed out and scheduled the same intent again.

The obvious cost is a reverted transaction and wasted gas. The less obvious cost is incorrect execution. A transaction can succeed while doing something different from what the scheduler intended because price, liquidity, contract configuration, or account state changed before inclusion.

Preflight simulation helps, but it is not a lock on future state. Other transactions can land between simulation and execution. The right interpretation is “this action was valid against this observed state,” not “this action will remain valid.”

Safety-critical predicates therefore need checks as close to submission as practical. The scheduler should also encode constraints in the transaction itself when the contract interface supports them. A database check can reduce bad attempts; transaction-level constraints can stop execution when state moves beyond accepted bounds.

Stale-restrictive: the database says no

Stale-restrictive state is the mirror case. The database blocks an action that chain state would allow.

This often happens when:

A worker marks an intent as pending and crashes before clearing its lease.
A transaction is replaced, but the database keeps watching the old hash.
A receipt or log is missed because an RPC request failed.
A transaction succeeds while the local record remains in a submitted state.
A temporary chain condition clears, but the scheduler never revisits the job.

This direction usually preserves funds but harms liveness. Jobs remain stuck, valid execution windows pass, and operators have to repair records manually. Over time, conservative patches can turn transient uncertainty into permanent blockage.

A common mistake is to treat “unknown” as “failed” or “still pending.” Unknown should be its own state. It tells the reconciliation process to gather evidence rather than blindly submit again or wait forever.

A simple failure sequence

Consider a scheduler that records an intended transaction and then broadcasts it:

intent: created
transaction: submitted
local state: pending
worker: crashes
chain: transaction succeeds
receipt update: never written

On restart, resubmitting may duplicate the action. Refusing to resubmit may leave the job stuck indefinitely.

The scheduler needs a third path: inspect the account nonce, transaction receipt, relevant logs, and resulting contract state. It can then classify the intent using chain evidence. That process is reconciliation.

Reconciliation is a control loop

Reconciliation should run continuously, not as an incident script. A practical design separates command handling from observation:

Persist an intent before submission, with an idempotency key tied to the logical action.
Record every submission attempt and transaction hash.
Advance state through explicit transitions rather than overwriting a generic status field.
Scan receipts and logs from a durable checkpoint.
Re-read critical contract state for records that remain uncertain.
Expire worker leases independently from transaction status.
Revisit recently confirmed records when the chain can still reorganize.
Rewind derived state when a previously observed block leaves the canonical chain.

Logs are efficient for broad discovery, while direct reads are useful for checking current state. Neither is sufficient alone. A log scanner can miss data because of checkpoint bugs or provider failures. A direct read can show the current value without explaining which local intents produced it.

Reconciliation also needs bounded concurrency and rate controls. An outage can create a large backlog, and an eager recovery worker can overwhelm the same RPC provider it depends on. The recovery path should be designed as normal production traffic, not exceptional traffic with unlimited resources.

Decide where freshness is worth its cost

Reading chain state before every action reduces some stale-permissive failures, but adds latency and consumes RPC budget. It can also create a false sense of certainty because the state can change after the read.

Skipping fresh reads improves throughput, but shifts more responsibility to transaction constraints, idempotency, and later reconciliation. For low-risk observations, cached state may be acceptable. For actions involving balances, permissions, nonces, or irreversible contract calls, fresher evidence is usually worth more.

There is no universal freshness policy. The honest trade-off is latency and RPC usage versus correctness risk. Make that decision per predicate rather than applying one cache duration to the whole scheduler.

Disclosure: I build Tradevo, software that compiles plain-English crypto strategies into deterministic rules, tests and paper-trades them, supports review and marketplace publishing, and executes subscribed rules on Base from wallets users control.

A reliable scheduler does not eliminate stale state. It makes staleness visible, limits what stale assumptions can authorize, and continuously compares its local model with chain evidence. Reconciliation is not cleanup after the system fails. It is part of the system’s normal operation.

How to Find Financial Restatements in SEC Filings

Christian Pichichero — Wed, 14 Oct 2026 18:44:48 +0000

Financial restatements can be useful research signals. They show that a previously reported figure changed after becoming public—sometimes because of an error, sometimes because of an amendment, and sometimes because the company changed how a fact was tagged or presented.

For researchers, the central question is not merely: What does the latest filing say?

It is: What was first reported, when did it become public, and what changed afterward?

Answering that question requires point-in-time data. A current-only financial database may replace an original value with a revision, obscuring how the historical record changed.

This guide explains how to find financial restatements in SEC filings, compare original and revised values, and avoid false positives.

What counts as a financial restatement?

In a broad research workflow, a restatement flag can mean a meaningful change to a previously reported financial fact for the same company, fiscal period, and accounting concept.

That is broader than searching only for filings explicitly labeled as restatements. A changed value may appear in:

An amended filing such as a 10-K/A or 10-Q/A
A later filing that presents comparative prior-period figures
An XBRL fact using the same concept and period but a revised value
A filing that corrects or updates an earlier disclosure

Not every change means fraud, distress, or even an accounting error. Units, decimals, contexts, fiscal periods, taxonomy choices, and presentation changes can all create apparent differences. Treat a restatement flag as a research lead, not a verdict.

The reliable method: preserve original and revised values

To detect revisions, retain filing-time observations rather than storing only the latest value.

For each fact, capture relevant fields such as:

Company identifier and ticker
SEC filing accession or source filing
Filing or acceptance date
Form type
Fiscal period and fiscal year
XBRL concept or tag
Units
Context dimensions
Reported value
Whether the filing is an amendment

Then group comparable observations by company, period, concept, units, and compatible context.

Within each group, sort observations by the date they became public. The earliest valid observation becomes the original value. The most recent comparable observation becomes the latest value.

A simple relative-change test is:

relative_change = abs(latest_value - original_value) / abs(original_value)

Tradevo Data labels a row as restated when the same-tag value changes by more than 0.5%, including amendments. This is its documented classification rule, not a determination that a change is legally or economically material.

The edge case is an original value of zero. Relative change is undefined there, so a detection system needs a separately documented rule rather than an arbitrary percentage.

Why the same-tag requirement matters

Comparing values across different XBRL concepts can produce misleading alerts.

For example, a company may move from a standard taxonomy concept to a custom extension or disclose a related but not identical measure. Even when labels look similar, the accounting meaning may differ.

A conservative detector can begin by comparing values reported under the same tag. This may not capture every economically equivalent revision, but it reduces semantic mismatches and makes each flag easier to audit.

A more advanced pipeline can map extensions to standard concepts, but that requires validation and should preserve the original tags for inspection.

A practical SEC EDGAR workflow

1. Identify the original filing

Start with the relevant 10-K or 10-Q in SEC EDGAR. Record the filing date, accession, fiscal period, units, context, and reported value.

2. Search for amendments

Check for 10-K/A or 10-Q/A filings. Amendments are an obvious place to look, but do not stop there. A later annual or quarterly filing may present a changed comparative prior-period value.

3. Match the accounting fact

Compare the same XBRL concept for the same fiscal period, units, and compatible context. Watch for consolidated versus segment facts and continuing operations versus total-company measures.

4. Compare chronologically

Sort matched observations by when they became public. Preserve the first-reported value even if a later filing changes it.

5. Apply a documented rule

Use a documented classification rule, such as Tradevo Data's greater-than-0.5% same-tag rule. Keep the underlying observations so researchers can investigate or override the classification.

6. Review the filing narrative

Read amendment explanations, footnotes, auditor language, accounting-policy disclosures, and internal-control sections. A numeric change identifies where to look; the filing may explain why it happened.

Why current-only databases can hide the signal

Suppose a company first reports an accounting value and later revises it. If a database keeps only the revised figure, a historical backtest may behave as though that figure was known on the original date.

That creates lookahead bias.

A point-in-time record can instead separate:

first_filed: the date the value became public
original_value: the first-reported, point-in-time-safe value
latest_value: the current revision
restated: whether the same-tag change exceeds 0.5%
qa_status: a quality-control field

For an as_of query, Tradevo Data includes rows where first_filed <= as_of, with the selected date included. For a deeper treatment, see https://tradevodata.com/blog/lookahead-bias-fundamental-backtests?utm_content=blog-how-to-find-restatements-in-sec-filings&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate and https://tradevodata.com/blog/point-in-time-fundamentals-data?utm_content=blog-how-to-find-restatements-in-sec-filings&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

Using Tradevo Data to surface revisions

Tradevo Data provides point-in-time US equity fundamentals sourced from public-domain SEC EDGAR data. Its annual dataset contains 632,466 point-in-time rows across 5,168 US companies, covers 16 annual concepts, and labels 37,804 restatements. It also contains 1,089,635 quarterly rows across 5,382 companies and seven quarterly concepts.

The API exposes one fundamentals endpoint:

/v1/fundamentals?ticker&as_of[&concept][&period=annual|quarterly]

Annual is the default period. Server-side as_of filtering uses first_filed <= as_of, including the selected date.

Each row includes first_filed, original_value, latest_value, a restated flag, and qa_status. Researchers can use these fields to screen for changed facts before reviewing the underlying SEC filings.

Tradevo Data covers up to 12 fiscal years. It does not cover non-US or delisted companies and does not provide TTM figures. Quarterly Q4 is reported where tagged or derived and labeled where supported; Q4 EPS and share values are not derived. Parquet format is not included.

Options compared fairly

Option	Strengths	Limitations to evaluate	Best fit
SEC EDGAR	Primary public source with complete filing context and no vendor normalization	Building structured point-in-time data requires ingestion, XBRL normalization, chronology, deduplication, and QA	Researchers who need maximum control and can maintain infrastructure
Tradevo Data	Original and latest values, filing chronology, restatement flags, server-side `as_of`, and bulk access on Pro	US scope; no non-US, delisted, TTM, or Parquet coverage	Budget-conscious researchers who want structured point-in-time fundamentals
Sharadar	Credible established alternative	Check its current coverage, methodology, and point-in-time semantics against your requirements	Teams whose needs match its ecosystem; see their pricing page: https://data.nasdaq.com/databases/SF1
Tiingo	Credible API-oriented market-data provider	Verify current restatement fields, historical semantics, and coverage for your use case	Developers seeking a broader API stack; see their pricing page: https://www.tiingo.com/pricing/overview
QuantConnect	Integrated research and execution environment with supported datasets	Evaluate whether its platform model fits a need for standalone filing data	Researchers building inside its environment; see their pricing page: https://www.quantconnect.com/pricing/

Competitor capabilities and pricing can change. Review each provider's current documentation, methodology, and pricing page rather than comparing labels alone.

When another option wins

Use SEC EDGAR directly when you need complete filing narratives, exhibits, custom tags, or provenance beyond normalized numeric rows.

A broader vendor may win when you require international issuers, delisted-company coverage, additional asset classes, or a larger integrated data catalog. Sharadar or Tiingo may be a better fit when their broader products, coverage, or existing integration matches your workflow. QuantConnect may win when research, data, backtesting, and execution need to live in one environment.

Tradevo Data is positioned as an honest budget tier of research-grade point-in-time fundamentals—not as the only credible or affordable option.

When to build it yourself

Build your own pipeline when restatement detection is core intellectual property, when you need custom materiality rules, or when vendor normalization would conceal details essential to your research.

Be prepared to handle:

SEC submissions and accession histories
Filing dates and acceptance timestamps
XBRL contexts, units, dimensions, and custom extensions
Fiscal-calendar irregularities
Duplicate and conflicting facts
Amendments and later comparative disclosures
Taxonomy migrations
Reproducible quality checks

The advantage is control. The trade-off is continuing maintenance and validation, not just the initial parser.

Verify the method before paying

The public proof pack contains 225 rows for five companies, covering their latest three fiscal years, with full methodology and no signup:

https://github.com/christianpichichero-max/pit-fundamentals

Inspect the chronology, source logic, original values, and revisions before deciding whether the normalization fits your research.

If it does, the card-backed 7-day free trial at https://tradevodata.com/?utm_content=blog-how-to-find-restatements-in-sec-filings&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate covers 10 companies, a rolling 3-year history, and 100 requests per day without bulk. It renews at $29 per month unless canceled. Pro provides complete available history, 5,000 requests per day, and bulk annual or quarterly downloads through /v1/download and /v1/snapshot?as_of. Documentation is at https://tradevodata.com/docs?utm_content=blog-how-to-find-restatements-in-sec-filings&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

Restatement flags are best used as triage: identify changed facts, inspect the filing sequence, read the disclosures, and decide whether the revision is relevant to your research.

Not investment advice.

Fundamentals Data for Finance LLM AI Agents: A Practical Grounding Layer

Christian Pichichero — Sat, 10 Oct 2026 18:44:17 +0000

Finance AI agents have a basic reliability problem: language models can produce plausible answers, including plausible numbers. Plausible is not enough when a user asks what a company reported, when the information became public, or whether the figure was later restated.

One practical approach is a grounding layer built from dated financial facts.

For developers building retrieval-augmented generation systems, filing copilots, screening agents, research assistants, or automated company briefs, point-in-time fundamentals can provide a structured bridge between SEC filings and model-generated explanations. The model can reason over the data, but it should not invent the data.

Tradevo Data provides point-in-time US equity fundamentals sourced from SEC EDGAR. Its annual dataset covers 5,168 US companies, 632,466 point-in-time rows, 16 annual concepts, and up to 12 fiscal years. Its quarterly dataset contains 1,089,635 rows across 5,382 companies and seven quarterly concepts. Coverage varies by filer.

Why ordinary fundamentals can mislead an AI agent

A conventional fundamentals database may emphasize the latest known value. That can be useful for current analysis, but it may be inappropriate for a historical question.

Suppose an agent is asked:

What revenue and net income were publicly available for a company on June 15 of a past year?

If retrieval returns a figure restated months later, the answer contains information that was unavailable on June 15. The number may now be technically correct while still being historically invalid for that date.

That distinction matters for:

Historical research and event reconstruction
Backtests using fundamental signals
Filing-aware RAG systems
Agents answering “as of” questions
Audit trails for generated financial summaries
Comparing first-reported figures with subsequent revisions

This is lookahead bias at the data layer. A longer explanation is available at https://tradevodata.com/blog/lookahead-bias-fundamental-backtests?utm_content=blog-grounding-a-finance-llm-in-as-reported-fundamentals&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

The fields an agent needs for defensible answers

A useful finance grounding record should do more than return a value. It should establish provenance.

Each Tradevo Data row includes:

first_filed: the date the value became public
original_value: the first-reported, point-in-time-safe value
latest_value: the current revision
restated: a flag for a greater-than-0.5% change under the same XBRL tag, including amendments
qa_status: a quality-assurance status

The dataset labels 37,804 restatements.

For an AI agent, those fields support a stronger response pattern:

Retrieve facts available by the requested date.
Use original_value for an as-reported historical answer.
Compare it with latest_value if revisions matter.
Include first_filed and the requested concept in the response.
State uncertainty or coverage gaps instead of filling them with generated numbers.

An XBRL tag is not a complete semantic guarantee: filers can use extensions, presentation varies, and accounting context still matters. But a dated record containing the original value, revised value, restatement flag, and QA status is more auditable than an unsupported number in model output.

Example query for a finance AI agent

Tradevo Data exposes one JSON fundamentals endpoint with server-side point-in-time filtering:

GET https://tradevodata.com/v1/fundamentals?ticker=AAPL&as_of=2020-06-15&concept=Revenue&period=annual&utm_content=blog-grounding-a-finance-llm-in-as-reported-fundamentals&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate

The server applies:

first_filed <= as_of

The date is inclusive. Annual data is the default, while period=quarterly requests quarterly rows.

A basic agent tool contract might look like this:

{
  "tool": "get_fundamentals",
  "arguments": {
    "ticker": "AAPL",
    "as_of": "2020-06-15",
    "concept": "Revenue",
    "period": "annual"
  }
}

The model should then compose an answer from returned records rather than relying on memorized parameters. A system instruction can require it to include the fiscal period, first_filed, original_value, and concept in every numerical citation.

For example:

Use only retrieved values. If no qualifying row exists by the requested
as-of date, say that the dataset returned no supported value. Do not infer
or interpolate a financial figure.

That final rule is important. Retrieval does not prevent hallucination unless the agent is explicitly required to abstain when evidence is missing.

A practical RAG architecture

A filing agent can separate structured facts from unstructured context:

Use point-in-time fundamentals for supported numerical claims.
Use filing text retrieval for management commentary, accounting policies, and risk disclosures.
Store source metadata alongside every chunk or fact.
Require citations in the final answer.
Validate numerical statements against retrieved structured records before returning them.

Structured fundamentals are not a replacement for the filing. They can serve as a compact numerical layer alongside it.

For bulk workflows, the $29-per-month Pro plan includes /v1/download and /v1/snapshot?as_of, each supporting period=annual|quarterly. These endpoints can support a local retrieval store or reproducible historical snapshot. Parquet format is not included.

More background on the data model is available at https://tradevodata.com/blog/point-in-time-fundamentals-data?utm_content=blog-grounding-a-finance-llm-in-as-reported-fundamentals&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

What Tradevo Data covers—and what it does not

The annual dataset contains these 16 concepts:

Revenue
NetIncome
Assets
StockholdersEquity
OperatingCashFlow
EPSDiluted
DilutedShares
GrossProfit
OperatingIncome
PretaxIncome
IncomeTaxExpense
CapitalExpenditures
CashAndCashEquivalents
CurrentAssets
CurrentLiabilities
NetPPE

Quarterly coverage includes seven concepts. Q4 is reported where tagged or derived and labelled where supported. Derived Q4 EPS and share figures are not provided.

The service does not provide TTM calculations, non-US coverage, delisted-company coverage, or Parquet output. It is not presented as a full filing-text corpus, market-data feed, estimates database, or accounting ontology.

These limits matter. An agent should not present absence as zero, assume every filer reports every concept, or silently substitute one accounting concept for another.

Fair comparison for finance-agent developers

Option	Best fit	Potential strengths	Important considerations
Tradevo Data	Developers wanting a budget-tier API and bulk access for core US fundamentals	Server-side `as_of`, original and latest values, filing dates, restatement labels, and QA status	Limited concept set; no delisted, TTM, non-US, or Parquet coverage
Raw SEC EDGAR/XBRL	Teams needing maximum control and direct primary-source processing	Public-domain source material and direct control over interpretation	Requires ingestion, taxonomy mapping, duplicate handling, amendment processing, QA, and point-in-time logic
Sharadar	Researchers evaluating a broader established data product	A credible alternative with its own coverage and data model	Confirm current scope and licensing; see their pricing page: https://data.nasdaq.com/databases/SF1
Tiingo	Developers evaluating fundamentals alongside other financial APIs	A credible provider with a broader product context	Verify point-in-time semantics and coverage; see their pricing page: https://www.tiingo.com/pricing/overview
QuantConnect	Teams building inside an integrated research and execution platform	Data access within a broader algorithmic environment	Platform fit may matter more than a standalone fundamentals API; see their pricing page: https://www.quantconnect.com/pricing/

No provider should be chosen from a feature label alone. Test amendment handling, filing-date semantics, survivorship assumptions, missing values, concept normalization, redistribution rights, and historical coverage against your actual agent workflow.

When another option wins

Another provider can be the better choice when you need a broader security universe, delisted companies, non-US issuers, more accounting concepts, analyst estimates, TTM figures, market data, or a managed research platform. A specialist vendor may also win when your institution needs enterprise support, contractual service levels, or licensing terms beyond a developer-oriented product.

If your workflow already runs inside QuantConnect, its integrated environment may reduce engineering work. If you need a broader commercial dataset, Sharadar or Tiingo may fit better after you verify current coverage and point-in-time behavior.

Tradevo Data is positioned as an honest budget tier of research-grade point-in-time data, not as the only affordable option and not as a universal financial-data layer.

When to build it yourself

Build directly from SEC EDGAR when provenance control is more important than implementation speed, your required concepts fall outside the supported set, or your team has specialized accounting and data-engineering expertise.

Be prepared to handle:

Filing and amendment chronology
XBRL standard tags and company extensions
Units, periods, contexts, and duplicate facts
Fiscal-year differences
Restatements and comparable-tag logic
Quarterly versus year-to-date facts
Q4 derivation rules
Missing and malformed filings
Reprocessing when extraction rules change
Reproducible historical snapshots

EDGAR is public domain, so self-building can be rational. The practical burden is maintaining consistent interpretation and QA over time.

Inspect the evidence before connecting an agent

A public proof pack is available at https://github.com/christianpichichero-max/pit-fundamentals. It contains five companies, their latest three fiscal years, 225 rows, and the full methodology with no signup.

On reliable-filing rows in that five-company proof pack only, measured lookahead averaged 35.2 days and reached a maximum of 48 days. Those measurements describe the proof pack, not the full dataset.

For API evaluation, https://tradevodata.com/?utm_content=blog-grounding-a-finance-llm-in-as-reported-fundamentals&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate offers a card-backed seven-day free trial covering 10 companies, a rolling three-year history, and 100 requests per day without bulk. Unless canceled, it renews at $29 per month. Pro provides complete available history, 5,000 requests per day, and bulk endpoints. Documentation is at https://tradevodata.com/docs?utm_content=blog-grounding-a-finance-llm-in-as-reported-fundamentals&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

Start with the public sample, test the dates and concepts against source filings, and make abstention part of the agent design. The goal is not to make a model sound certain. It is to make supported financial numbers traceable.

Not investment advice.

A Transaction Timeout Is Not a Transaction Failure

Christian Pichichero — Thu, 08 Oct 2026 20:09:56 +0000

You broadcast a transaction, wait for the RPC response, and get a timeout. What happened?

The honest answer is that you do not know. The node may never have received the request. It may have accepted the transaction into its mempool but lost the response. Another node may already have propagated it. The transaction may even be mined while your executor records a network error.

Treating that timeout as a failure and sending a fresh transaction can execute the same business action twice.

Separate the request from the transaction

An RPC request and a blockchain transaction have different lifecycles. A request can fail at the HTTP layer while the transaction continues through the network.

This distinction produces three outcomes, not two:

Succeeded: chain state shows the intended transaction was included.
Failed: chain state shows a terminal failure, such as a reverted transaction.
Uncertain: the executor cannot yet establish either outcome.

uncertain is not a softer spelling of failed. It is a durable state that needs reconciliation.

Persist the intent before broadcasting

The first durable record should describe the business action, not the RPC attempt. Write it before signing or sending anything.

A minimal record might look like this:

intent_id:      rebalance:account-42:2026-09-03T10
account:        0xabc...
chain_id:       8453
operation:      swap token A for token B
status:         created
nonce:          null
signed_tx:      null
tx_hashes:      []

Give intent_id a uniqueness constraint based on the business operation. If two workers receive the same job, they should load the same intent rather than create independent transactions.

Next, reserve a nonce, construct the transaction, sign it, and persist the signed bytes and hash before broadcast. This ordering lets a restarted worker send the exact same payload.

A database entry marked broadcasting does not prove that any node saw the transaction. Likewise, a missing sent log does not prove that no node saw it. Your database records what the executor attempted; the chain records what took effect.

Use nonces deliberately

For an EVM externally owned account, the nonce is the main duplicate-execution boundary. Two transactions from the same account with the same nonce cannot both become canonical.

That does not mean an executor can derive any nonce from an intent ID. Account nonces are sequential. A practical nonce manager must serialize reservations per account and persist them so concurrent workers do not choose the same nonce for unrelated intents.

After a timeout, rebroadcasting the exact signed bytes is the simplest safe retry. The transaction hash stays the same, and nodes that already know it can treat the broadcast as redundant.

Fee replacement is more complicated. A replacement uses the same nonce but changes fee fields, producing a new hash. Persist every candidate hash under the same intent and monitor all of them. Never respond to a timeout by allocating a fresh nonce to the same action.

If the original transaction has already been mined, a replacement may be rejected because the nonce is too low. That error is a reason to inspect chain state, not to create another transaction.

Smart-contract accounts can provide a stronger application-level boundary by storing an operation ID and rejecting duplicate execution. That handles cases an account nonce cannot express, but it adds contract complexity and execution cost. Sequential EOA nonces are simpler, though they can become a throughput bottleneck.

Reconcile with chain state

A reconciliation worker should examine evidence in roughly this order:

Check receipts for every transaction hash attached to the intent.
Check whether the sending account's nonce has been consumed.
Inspect the destination contract's state or events for the intended operation.
Wait for the confirmation depth required by the application before marking the intent final.

A single RPC node saying “not found” is weak evidence. Mempools differ, nodes can lag, and old pending transactions may disappear from local views. Querying another provider can improve visibility, but it still does not turn absence into proof.

If the account nonce has advanced, determine which transaction consumed it. Your intended transaction may have been included, replaced, or displaced by another process using the same account.

Reorganizations also matter. included and finalized should be separate states. An included transaction can temporarily disappear and need further reconciliation.

The ugly middle state

Suppose the broadcast timed out, no receipt is visible, the transaction is absent from the RPC node, and the account nonce has not moved. The transaction might still be propagating, or every node might have dropped it.

There is no honest terminal answer yet.

Keep the intent uncertain, rebroadcast the same signed payload, and schedule another reconciliation pass. Time alone should not silently convert uncertainty into failure. If the application eventually stops retrying, preserve the unresolved status for operator inspection.

A “cancel” transaction is also only a competing transaction with the same nonce. It can win the race, or the original can be mined first. Model the outcome from chain evidence rather than from the fact that a cancellation request was sent.

Disclosure: I build Tradevo, which compiles plain-English crypto strategies into deterministic rules, runs historical tests and paper trading, lets creators submit strategies for human review and publish approved strategies to a marketplace, and lets subscribers run published rules from wallets they control.

A useful executor invariant

The core invariant is simple:

One business intent may have several broadcast attempts and transaction hashes, but it must not silently become several independent nonce-bearing actions.

That requires coordination across the database, signer, nonce manager, broadcaster, and reconciliation worker. Idempotency is not a retry flag attached to an RPC call. It is a state machine built around the possibility that the network acted while your process learned nothing.

Point-in-Time Data for Academic Finance Research: A Reproducibility Guide

Christian Pichichero — Wed, 07 Oct 2026 20:02:49 +0000

In empirical finance, a backtest should use only information available on the simulated decision date. If it uses financial statements based on fiscal period-end dates, current database values, or later restatements, the model may incorporate facts that had not yet been published.

That is lookahead bias. It can affect estimated predictability, reported coefficients, and reproducibility.

Point-in-time, or PIT, fundamentals record when each value became public and allow researchers to reconstruct the information set available as of a historical date. For accounting-based asset-pricing signals, PIT treatment can be an important part of research design.

Why ordinary fundamentals may not be enough

Suppose a company has a fiscal year ending December 31. Its annual revenue does not necessarily become public on December 31. The filing may arrive weeks later, and an amendment or restatement may subsequently change the value.

A conventional panel might contain:

the fiscal period end;
the latest known value;
a standardized concept;
the company identifier.

That panel may be useful for descriptive tasks, but it does not necessarily answer the historical question: What value could a researcher have observed on the portfolio formation date?

A PIT row needs an availability date or timestamp. Tradevo Data exposes first_filed, defined as the date the value became public. Its API applies first_filed <= as_of, including same-day filings. Each row also contains:

original_value: the first-reported, PIT-safe value;
latest_value: the current revision;
restated: a flag for changes above 0.5% on the same tag, including amendments;
qa_status: a data-quality field.

The distinction between original and latest values matters. Replacing the original observation with a later revision can introduce future information even if the fiscal period itself is correctly lagged.

For a deeper treatment, see https://tradevodata.com/blog/lookahead-bias-fundamental-backtests?utm_content=blog-point-in-time-data-for-academic-finance-research&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

PIT design belongs in the methods section

A reproducible paper should state more than “fundamentals were lagged.” A fixed lag is a convention, not proof that the information was public.

A stronger methodology documents:

Availability rule: Which filing date or timestamp determines eligibility?
Boundary rule: Are filings published on the formation date included?
Revision policy: Does the study use first-reported or latest values?
Fiscal-period policy: How are annual observations aligned across firms?
Concept mapping: Which source tags map to each standardized variable?
Missingness policy: Are missing values dropped, imputed, or interpreted economically?
Universe policy: Does the source include delisted companies and non-US issuers?
Snapshot procedure: Can another researcher reconstruct the same extract later?

Tradevo Data's server-side endpoint is:

/v1/fundamentals?ticker&as_of[&concept][&period=annual|quarterly]

Annual is the default. Bulk access is available through /v1/download and /v1/snapshot?as_of, each accepting period=annual|quarterly. The snapshot route makes the historical cutoff explicit. Parquet format is not included.

What Tradevo Data covers—and what it does not

Tradevo Data provides point-in-time US equity fundamentals derived from public-domain SEC EDGAR filings. Its annual dataset contains 632,466 point-in-time rows across 5,168 US companies, with 16 annual concepts and up to 12 fiscal years. Its quarterly dataset contains 1,089,635 rows across 5,382 companies and seven quarterly concepts. Across the data, 37,804 restatements are labeled.

The annual concepts are Revenue, NetIncome, Assets, StockholdersEquity, OperatingCashFlow, EPSDiluted, DilutedShares, GrossProfit, OperatingIncome, PretaxIncome, IncomeTaxExpense, CapitalExpenditures, CashAndCashEquivalents, CurrentAssets, CurrentLiabilities, and NetPPE.

Quarterly data is also available with seven concepts. Q4 is reported where tagged or derived and labeled where supported. Derived Q4 EPS and shares are excluded.

The limitations are material:

US companies only;
no non-US coverage;
no delisted-company coverage;
no TTM fields;
a focused concept set rather than the breadth of a large institutional platform;
no included Parquet format.

These constraints should appear in a paper's data section. In particular, the absence of delisted companies may create survivorship concerns depending on sample construction and the research question.

Tradevo Data versus WRDS and Compustat

WRDS is an institutional research platform through which universities and other organizations may access datasets such as Compustat, subject to their subscriptions and licenses. It may be the stronger choice when a study requires broader historical coverage, standardized identifiers across databases, delisted securities, international accounting data, or established institutional workflows.

Tradevo Data is a narrower, budget-tier PIT source for researchers who need US filing fundamentals without requiring university-gated access.

Criterion	Tradevo Data	WRDS/Compustat
Access model	Public API and bulk files; card-backed trial	Commonly accessed through subscribing institutions
Source orientation	Public-domain SEC EDGAR filings	Commercial research databases
PIT mechanism	`first_filed`, original and latest values, and server-side `as_of`	Capabilities depend on the subscribed dataset and fields
Coverage	US companies; focused annual and quarterly concepts	Potentially broader options, depending on institutional subscriptions
Delisted companies	Not covered	May be the better route when delisted coverage is required; verify the specific product
International research	Not covered	May be better suited when subscribed products cover the required markets
Reproducibility aids	Public methodology, no-signup sample, and dated snapshots	Institutional workflows subject to licensing and local access
Price	$29/month after the trial unless canceled	See their pricing or institutional-access page: https://wrds-www.wharton.upenn.edu/

This is not an argument that one source universally replaces the other. The appropriate source depends on the identification strategy, required universe, licensing constraints, and replication plan. Sharadar, Tiingo, and QuantConnect are also credible alternatives; compare their current documentation, coverage, PIT methodology, and pricing pages directly.

Public proof before signup

Tradevo Data publishes a no-signup proof pack at:

https://github.com/christianpichichero-max/pit-fundamentals

It contains 225 rows for five companies over their latest three fiscal years, plus the full methodology. Researchers can inspect the schema, test availability logic, and evaluate whether the concept mapping is suitable before entering payment details.

On reliable-filing rows in that five-company proof pack only, measured lookahead averaged 35.2 days and reached a maximum of 48 days. These figures are not evidence about the full dataset. They demonstrate within the sample how filing availability can differ from fiscal period-end dating.

More background on the data model is available at https://tradevodata.com/blog/point-in-time-fundamentals-data?utm_content=blog-point-in-time-data-for-academic-finance-research&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

A practical research workflow

A defensible workflow can be simple:

Pre-register or document the formation-date rule.
Query or snapshot the data with the required as_of date.
Use original_value for the historical information set unless the research question explicitly concerns revised accounts.
Retain first_filed, restated, and qa_status in intermediate files.
Archive query parameters, code, and extraction dates.
Report coverage exclusions, especially delisted and non-US companies.
Run sensitivity checks using alternative availability rules where justified.
Make a small, license-compliant replication extract available when possible.

The card-backed seven-day free trial covers 10 companies, a rolling three-year history, and 100 requests per day, without bulk access. It renews at $29/month unless canceled. Pro provides the complete available history, 5,000 requests per day, and bulk access through /v1/download and /v1/snapshot?as_of. Documentation is at https://tradevodata.com/docs?utm_content=blog-point-in-time-data-for-academic-finance-research&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate, and the trial is available at https://tradevodata.com/?utm_content=blog-point-in-time-data-for-academic-finance-research&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate.

When WRDS or another institutional source wins

Use WRDS, Compustat, or another appropriate institutional dataset when the paper requires:

delisted-company coverage to address survivorship bias;
non-US or cross-country samples;
history beyond Tradevo Data's available horizon;
accounting fields outside Tradevo Data's focused concept set;
linked returns, analyst estimates, ownership, executive, or security-master data;
identifiers and conventions already standard in a target literature;
a licensed source mandated by coauthors, reviewers, or the institution.

Researchers should inspect the exact subscribed product, documentation, PIT fields, and licensing terms rather than assume every dataset exposed through a platform has identical historical properties. For current access and cost information, see each provider's pricing page.

When to build it yourself

Building directly from SEC EDGAR can be the better choice when the extraction pipeline is itself a research contribution, when unusual XBRL tags are central to the hypothesis, or when complete control over transformation rules matters more than implementation time.

A credible build may need to handle filing chronology, amendments, duplicate facts, taxonomy changes, units, dimensions, fiscal calendars, concept mapping, accession-level provenance, and historical snapshots. It may also require tests for revisions and malformed filings.

The advantage is transparency and customization. The disadvantage is the required data-engineering work. One approach is to validate a managed dataset against raw filings for a stratified sample and publish the audit code.

The standard is reconstructability

Using a familiar database does not by itself make academic finance reproducible. The core question is whether another researcher can reconstruct the information set available on each simulated date and understand the transformations applied.

Tradevo Data offers a focused option for annual and quarterly US filing fundamentals, with explicit availability dates, original and revised values, restatement labels, snapshots, and a public methodology. It is not a substitute for broad institutional databases in every research design. It is an inspectable budget-tier option when its coverage matches the paper.

Start by auditing the free sample at https://github.com/christianpichichero-max/pit-fundamentals. If the schema and methodology fit the study, the card-backed seven-day free trial is available at https://tradevodata.com/?utm_content=blog-point-in-time-data-for-academic-finance-research&utm_source=devto&utm_medium=syndication&utm_campaign=syndicate and renews at $29/month unless canceled.

Not investment advice.

Sponsoring Gas Without Holding User Funds: Paymasters and the Trust Model

Christian Pichichero — Thu, 01 Oct 2026 19:50:45 +0000

The awkward edge case in a consumer wallet flow is the first transaction: the user has the asset your application needs, but none of the chain’s native token. Asking them to visit an exchange or bridge before they can use the app is technically honest and often terrible UX.

Account abstraction offers another option. A paymaster can cover the network fee while the user’s assets remain in their own smart account. That removes one prerequisite, but it also introduces a sponsor with policy control, infrastructure costs, and several ways to be abused.

The basic ERC-4337 flow

In ERC-4337, a wallet submits a UserOperation rather than sending a conventional transaction directly. Conceptually, the flow looks like this:

wallet builds and signs UserOperation
        |
        v
sponsor checks operation against its policy
        |
        v
sponsor adds signed paymaster data
        |
        v
bundler simulates and submits the operation
        |
        v
EntryPoint validates wallet and paymaster
        |
        v
call executes; fee is charged to paymaster deposit

The paymaster keeps native tokens deposited with the EntryPoint contract. Its validation logic decides whether it accepts responsibility for a particular operation. The EntryPoint then charges the actual execution cost to that deposit, subject to the operation’s gas fields and protocol rules.

Most consumer applications use a verifying paymaster. An off-chain service inspects the operation and signs sponsorship data if the request satisfies its policy. The on-chain paymaster verifies that signature during validation.

This split matters. The on-chain component checks that the sponsor approved the exact operation, while the off-chain service handles changing concerns such as rate limits, account status, application plans, and allowed contract methods.

What the sponsor can do

A sponsor can decide which operations it is willing to fund. Its policy might inspect:

The destination contract and function selector.
The chain and EntryPoint version.
Maximum gas and fee fields.
Calldata size.
Wallet, user, device, or subscription quotas.
Whether the operation was produced through an expected application flow.
Estimated cost under current network conditions.

The sponsor can also stop issuing approvals, lower limits, or make sponsorship conditional on its backend being available. That is a real dependency. A wallet may remain usable, but the sponsored path can disappear.

The sponsor also learns about an operation before inclusion. Even though the eventual transaction is public, advance visibility and request metadata can matter. Applications should avoid pretending that sponsorship is a privacy mechanism.

What the sponsor cannot do

Paying gas is not the same as authorizing the wallet’s call.

The smart account still validates the user’s signature or whatever authorization scheme the account implements. A paymaster cannot modify the signed destination, calldata, or value without invalidating that authorization. It also cannot spend wallet assets merely because it paid the network fee.

This distinction becomes blurred when one company operates several components. An application might run the sponsor, bundler access, and a delegated wallet signer. Those roles should be analyzed separately:

The paymaster decides whether to pay.
The bundler decides whether to submit a valid operation.
The wallet’s authorization logic decides which calls may execute.

A restricted paymaster policy does not make a broad wallet key safe. Likewise, a narrow wallet authorization does not prevent somebody from wasting an overly permissive sponsorship budget.

Open sponsorship is a griefing surface

A policy that effectively says “pay for any operation from our app” is easy to consume at scale. An attacker does not need to steal the sponsor’s deposit. They only need to create operations that qualify and cost money.

Simple per-wallet limits are weak if wallets are cheap to create. IP limits can block legitimate shared networks and are easy to distribute around. Requiring an application login raises the cost of abuse but moves the problem into account creation and session security.

Failed calls also deserve attention. An operation can pass validation and then revert during execution, consuming gas anyway. Simulation catches many failures, but state can change between simulation and inclusion. Deliberately expensive valid calls may still satisfy a policy that checks only destinations and selectors.

A practical policy therefore combines several controls:

Allow specific contracts and methods rather than arbitrary calls.
Cap gas fields and calldata size.
Check call arguments when their meaning is stable and unambiguous.
Set budgets across wallets, users, and time windows.
Reject stale sponsorship signatures.
Monitor cost per successful operation and cost per failed operation.
Add a global circuit breaker for unexpected spending.

None of these controls is free. More inspection creates more backend coupling and more ways to reject legitimate traffic after a contract upgrade.

Sponsorship is an operating decision

The contract is only part of the system. Someone must keep the paymaster deposit funded, monitor native-token exposure, handle fee spikes, and decide what happens when a daily budget is exhausted.

You also need an outage mode. Can users pay their own gas if the sponsor is unavailable? Does the interface explain that option before asking them to sign? Can another bundler submit the same operation, or have you coupled sponsorship to one provider’s API?

Cost attribution matters too. “Gasless” usually means somebody else receives the bill. A product team needs to know which user action created each charge, whether retries duplicate work, and how much abuse the support team is willing to tolerate. Sponsorship may be cheap during normal traffic but difficult to bound during a fee spike or automated attack.

Alternatives have valid trade-offs. Letting users pay is simpler and makes costs explicit. A faucet is straightforward but attracts automated abuse. Reimbursing users after execution still requires them to hold native tokens first. Application-specific relayers can work well when contracts already support meta-transactions, though they introduce their own trust and compatibility constraints.

Disclosure: I build Tradevo, which lets people build, test, paper-trade, publish, subscribe to, and automatically run crypto strategies from wallets they control; its free tier sponsors gas.

A paymaster improves onboarding by separating transaction authorization from fee payment. It does not remove trust; it moves part of the trust model into sponsorship policy and operations. Treat that policy like a security boundary, and treat its budget like production infrastructure rather than a promotional checkbox.

The Uncertain State Between Sending and Mining

Christian Pichichero — Thu, 24 Sep 2026 18:41:15 +0000

An automated executor can make a valid decision and still have no safe action to take.

The awkward interval is between deciding to submit a transaction and learning whether the chain included it. During that interval, permissions can disappear, processes can crash, RPC requests can time out, and retries can create a second execution.

Treating all of this as a generic pending status hides the information needed for safe recovery. A useful executor distinguishes at least three states:

DECIDED_UNSENT -> SENT_UNMINED -> CONFIRMED | REVERTED
       |               |
       v               v
   ABANDONED        UNCERTAIN

UNCERTAIN is not another spelling of pending. It means the executor lacks enough evidence to act automatically.

Decided but unsent

In this state, the executor has chosen an action and recorded that decision, but nothing has left the machine.

This is the easy case operationally because abandoning the action has no chain effect. If the relevant permission disappears before submission, the executor can mark the decision abandoned and stop.

Before making any external call, persist enough information to explain and reproduce the decision:

An immutable intent ID
The account and chain
The exact proposed action
The policy or configuration version used
The decision timestamp
The observed input data or a reference to it
The permission state observed during evaluation
A terminal reason if the intent is abandoned

Do not overwrite an abandoned intent with a newer decision. Create another intent. An append-only history makes it possible to distinguish “we chose not to send” from “we lost track of the send.”

The executor may re-check whether submission is still allowed, but that check does not create an atomic boundary across a database, signer, RPC provider, and chain. If the permission check succeeds and then the process crashes, recovery still needs to know whether a request left the machine.

That requires a write-ahead submission record.

Persist before the network call

Once a transaction has been constructed and signed, its raw bytes and transaction hash should be persisted before broadcasting when the signing setup permits that. The hash is derived locally, so the executor does not need an RPC response to identify the transaction.

A submission record might contain:

{
  "intent_id": "intent-123",
  "attempt": 1,
  "status": "submission_prepared",
  "chain_id": 8453,
  "nonce": 42,
  "transaction_hash": "0x...",
  "signed_payload": "0x..."
}

If an external signing or relay service does not expose the signed payload, persist an idempotency key and provider request ID before the call. This is weaker because recovery now depends on the provider’s idempotency and lookup semantics. That limitation should be explicit in the design rather than hidden behind a retry loop.

The key rule is simple: the durable record must advance before the next irreversible external interaction.

Sent but unmined

A transaction is sent but unmined when the executor has evidence of submission but no inclusion receipt.

The executor may observe. It may query multiple RPC providers, inspect the account nonce, rebroadcast the identical signed payload, or ask a relay service about the original request ID. It must not casually construct a fresh transaction.

Rebroadcasting identical signed bytes is generally different from creating another transaction. The identical payload has the same hash and nonce. A newly built payload may have a new nonce, different fee fields, or altered call data, making a second execution possible.

This distinction becomes especially important with application-level relayers. Retrying an HTTP request without an idempotency key may cause the relayer to create another transaction even if the first request merely timed out on the client side.

A timeout says that the caller did not receive an answer. It does not say that the callee did nothing.

While the transaction remains observable by hash, the executor can keep the state as SENT_UNMINED. It should record each observation without rewriting the original submission facts.

Uncertain must be a first-class status

Some failures cannot be settled automatically:

The process crashed during a remote signing or relay call.
The provider accepted a request but supplied no durable identifier.
The account nonce advanced, but the executor cannot identify which transaction used it.
Different providers disagree about whether a transaction exists.
A replacement transaction may have been created outside the executor.

Marking these cases failed is unsafe because a retry may duplicate the action. Marking them successful is dishonest because inclusion has not been established.

UNCERTAIN should therefore be terminal for automatic execution. The system may continue collecting evidence, but it must not silently move the record back into the normal retry path. A user or operator can review the evidence and make a new, explicit decision.

The executor also should not invent a compensating transaction. An opposite action is not an undo operation. Prices may have changed, fees have already been spent, and the relevant permission may no longer exist. Compensation is a separate intent requiring separate authorization.

This is less convenient than automatic recovery. It is also more accurate. Distributed systems sometimes lose the evidence needed to distinguish “did not happen” from “happened, but the acknowledgement was lost.” A status model should preserve that fact instead of guessing.

Disclosure: I build Tradevo, software where users describe, test, paper-trade, publish, subscribe to, and automatically run crypto strategies from wallets they control.

The honest executor is not the one that always keeps moving. It is the one that knows when movement would be an unsupported assumption.

What Regime Splits Actually Tell You (and Where the Math Runs Out)

Christian Pichichero — Thu, 17 Sep 2026 18:34:45 +0000

Regime splitting is one of the first "advanced" moves people make once they've built a backtest they trust. You have a couple hundred closed trades, an equity curve that looks fine in aggregate, and a nagging question: does this actually work in all markets, or did it just get lucky during a two-year trend? So you split the history — trending vs choppy, high volatility vs low, before some macro event vs after — and look at the four (or eight) resulting curves.

This is a genuinely good instinct. It's also one of the easiest ways to produce false confidence, for a reason that has nothing to do with your strategy and everything to do with arithmetic.

The sample size problem, concretely

Say you have 200 closed trades. You define a regime filter with two states — trending or choppy — using something like ADX or a moving-average slope threshold. If the market cooperated and split roughly evenly, you now have two buckets of 100. Split again by volatility (high/low), and you have four buckets of ~50. Add a third cut — say, before/after a rate-hike cycle — and you're down to sub-25 per bucket, sometimes much less, because market regimes don't obligingly divide your history into equal quarters. A trending, high-vol regime might have supplied 60 trades and a choppy, low-vol one might have supplied 8.

Fifty trades is not enough to say much about a strategy's edge, and eight is not enough to say anything. Here's the shape of the problem using a rough binomial confidence interval on win rate:

n = 200, observed win rate = 55%  -> 95% CI ≈ [48%, 62%]
n = 50,  observed win rate = 55%  -> 95% CI ≈ [41%, 69%]
n = 15,  observed win rate = 55%  -> 95% CI ≈ [30%, 78%]

At n=200 you can at least argue the edge is probably real if the interval stays above 50%. At n=50 the interval already swallows a coin flip. At n=15 — a completely normal size for a "regime bucket" carved out of a modest history — the interval tells you almost nothing. You can't distinguish a strategy with a genuine 55% edge in that regime from a fair coin that happened to run hot for a couple weeks.

This is the trap: the split itself feels like rigor. You went looking for a weakness, you found a bucket where performance looked worse, and you either panic and discard a strategy based on 12 trades, or rationalize the bad bucket away ("that regime is rare, doesn't matter") using the same small sample that should make you distrust the conclusion in either direction. Both moves are overconfident. The honest answer for a 12-trade bucket is usually "I don't know," which is an unsatisfying thing to put in a report, so people tend not to write it.

Where regime splits still earn their keep

None of this means regime analysis is worthless. It's good for a narrower job than people use it for: sanity-checking that performance isn't concentrated in a single, unrepeatable environment — discovering, say, that 80% of your profit came from March 2020. That's a real, useful finding even from a small bucket, because you're not estimating a rate, you're checking for concentration. "Most of the P&L came from one regime" is a safer claim than "the strategy has a 61% win rate in choppy markets," because the first is close to arithmetic on the data you already have, and the second is an inference about data you don't.

It also helps a lot to define the regime boundaries before looking at performance, not after. If you tune the ADX threshold until the choppy bucket looks bad (or good), you've turned a diagnostic into a curve-fit, and the regime split now carries the same overfitting risk as the strategy it was supposed to check.

What the alternatives do differently

Walk-forward testing sidesteps part of this by re-optimizing on a rolling window and testing out-of-sample on the next chunk, which at least keeps you honest about lookahead. It doesn't fix small-sample problems inside any single fold, though, and it's sensitive to window-length choices that are themselves a quiet form of overfitting. Purged k-fold cross-validation, borrowed from the ML side of quant research, handles leakage between adjacent samples better than a naive split — at the cost of being more work to implement correctly, and it still assumes your trades are close to independent, which they often aren't. Monte Carlo resampling of trade order or returns answers a different question again: whether your equity curve's shape depended on the sequence trades happened to occur in, rather than whether a regime subset has a real edge. It's worth running alongside a regime split, not instead of one.

None of these make the sample-size problem disappear. They're different lenses on the same underlying scarcity: you only have as many independent trades as you have, and slicing them doesn't create more evidence — it redistributes the evidence you already had into smaller, noisier piles.

Disclosure: I build Tradevo Verify, which runs this kind of stress-testing — including path-dependency and regime checks — against a closed-trade export and reports how much weight the evidence can actually carry, rather than tuning a bucket until it looks convincing.

A practical rule of thumb

If a regime bucket has fewer than roughly 30 trades, treat any rate computed from it — win rate, average R, Sharpe — as a data point, not a conclusion, and report the count next to the number every time. And if you catch yourself narrowing a regime definition after seeing what the split produced, stop. You've left testing and entered storytelling, and the two look identical in a report until the next 50 trades arrive and disagree with you.

Return Concentration: How to Tell If Your Backtest Has Ten Trades or One

Christian Pichichero — Thu, 10 Sep 2026 17:53:42 +0000

You've got a trade log. Two hundred closed trades, a decent win rate, a Sharpe ratio that looks respectable. Before you trust any of it, ask one question: how many of those trades actually matter?

This is the return concentration problem, and it's one of the easier things to check in a backtest and one of the most commonly skipped. The idea is simple. Take your closed trades, sort them by profit, and ask what happens to the equity curve if you remove the best few. If removing five trades out of two hundred turns a profitable strategy into a flat or losing one, your two-hundred-trade backtest is actually a five-trade backtest wearing a costume.

The test itself

You don't need anything sophisticated to run this. Sort trades descending by PnL, then walk down the list removing the top 1, top 3, top 5, top 10, and recompute total return each time.

trades_sorted = sorted(trades, key=lambda t: t.pnl, reverse=True)
total = sum(t.pnl for t in trades)

for n in [1, 3, 5, 10]:
 remaining = trades_sorted[n:]
 new_total = sum(t.pnl for t in remaining)
 print(n, new_total, new_total / total)

If new_total goes negative or near-zero after dropping the top 5, you're looking at a strategy where almost all the reported edge lives in a handful of trades. That's not automatically damning — more on that below — but it changes what question you should be asking next.

A useful companion number: what fraction of total profit comes from the top 10% of winning trades? For a strategy trading a mean-reverting, high-frequency pattern, healthy concentration might mean the top 10% of trades account for 20-30% of profit — the rest of the distribution is doing real work. For a trend-following system that holds through long drawdowns waiting for a few large moves, it's normal for the top 10% of trades to account for 60-80% of profit. Both can be fine. The number alone doesn't tell you which case you're in.

The trap: assuming concentration means broken

Here's where people get it wrong in both directions. The naive read is "concentrated returns are fragile, spread returns are robust." That's not true. Trend-following, breakout, and long-volatility strategies are supposed to look concentrated — they're structurally a long series of small losses funding a few large wins. If you ran the drop-top-N test on a well-known trend system's historical trade list, you'd likely find the same lottery-ticket-looking distribution, because that's the mechanism, not a flaw in it.

The actual question isn't "is it concentrated," it's "is the concentration structural or accidental." Structural concentration comes from a repeatable trigger: your strategy has a rule that lets winners run and cuts losers early, and the big trades share a common cause — a volatility regime, a trend-continuation pattern, a specific setup that recurs. Accidental concentration is a few trades that happened to catch a one-off event (a short squeeze, a flash crash reversal, an earnings gap you didn't intend to hold through) that has no mechanism tying it to the rest of your trades. Same table of numbers, very different implications.

A few ways to tell them apart without much tooling:

Cluster the top trades by date and instrument. If your five biggest winners all fired in the same three-week window, or all on the same underlying, that's a concentration-in-time problem — you got one regime right, not an edge.
Check the exit reason. If the big winners exited on the same rule as the rest of your trades (say, a trailing stop or a signal reversal), that's structural. If they exited because you happened to close the account before a reversal, or the backtest's fill logic let you ride a gap that wouldn't be tradeable live, that's a data artifact.
Look at whether the same setup that produced the big winners also produced most of your losers. A strategy where the big-win trades and the many-small-loss trades share the identical entry logic is doing something coherent. If the big winners are a different distribution of setups than everything else, you may be looking at noise that got included in the same backtest by coincidence.

None of this is definitive from a spreadsheet alone. A trade log doesn't tell you about slippage on the entries that mattered, whether the position size on the big winners was realistic to fill, or whether the same setup will recur going forward — that requires separate checks on execution and forward behavior, not just the PnL column.

Disclosure: I build Tradevo Verify, which runs this kind of concentration check (along with execution, path-dependency, and regime tests) against a closed-trade CSV and produces a versioned record of the result — it doesn't tell you whether the strategy is good, and a concentrated result often comes back flagged as fragile evidence rather than a pass.

Either way, before you trust a backtest's headline number, spend the ten minutes sorting the trade list and dropping the top few. It won't tell you if your edge is real. It will tell you how many trades you're actually betting the conclusion on.

Allowlists Are Not Spending Caps: Two Different Security Properties, Often Confused

Christian Pichichero — Thu, 03 Sep 2026 18:05:38 +0000

If you've ever configured a delegated signer, a session key, or a bot's wallet permissions, you've probably reached for two knobs: an allowlist of assets it's allowed to touch, and a cap on how much value it can move. It's tempting to treat these as two settings on the same dial — both feel like "limits." They're not. They prevent different failure modes, and conflating them is how permission systems end up weaker than their configuration screen suggests.

What a spending cap actually prevents

A spending cap bounds magnitude. If a delegated key can move at most 500 USDC per day, then no matter what it does with that authority — swap, stake, send to an arbitrary address — the maximum damage from a compromised or misbehaving key is 500 USDC. It says nothing about what the money touches. A cap enforced correctly stops a runaway loop or a fully compromised signer from draining a wallet in one shot. It does not stop that signer from moving the capped amount into something worthless.

What an allowlist actually prevents

An allowlist bounds scope. If a signer can only interact with three named token contracts, then even with no spending cap at all, it categorically cannot send funds to an arbitrary address or interact with an unknown contract. This is a different property: it's not about how much moves, it's about which counterparties are even reachable.

The two compose well in theory — cap the blast radius, and separately narrow the attack surface — but each has failure modes the other doesn't cover, and "we have both" is not the same claim as "we're safe."

Failure mode 1: the allowlisted token isn't the code you allowlisted

An allowlist entry is usually just an address. But an address is not fixed behavior. If the token contract sits behind a proxy — which a large fraction of tokens do, for legitimate upgrade reasons — the logic executed when your signer calls transfer or approve can change after you added the address to your list. You audited version 1. The proxy now points at version 2. Your allowlist still matches, because the allowlist only ever checked the address, and the address never moved. This isn't a hypothetical: it's the entire reason "audit the contract, then allowlist the address" is a weaker guarantee than people assume — the audit has a timestamp, the allowlist doesn't.

Failure mode 2: the router that accepts arbitrary calldata

A lot of "swap-only" permission schemes are enforced by pointing the signer at a router contract instead of individual token contracts, on the theory that a router only does swaps. But look at what the router's function signature actually accepts. Plenty of router and aggregator interfaces expose something shaped like:

function execute(address target, bytes calldata data) external;

That's not a swap function. That's a generic call forwarder that happens to usually be used for swaps. If your policy allowlists the router's address and stops there, you've allowlisted "anything the router is willing to forward," which — depending on the router's own internal checks — can include calls into arbitrary target contracts with arbitrary calldata. The allowlist has to be checked against the target and selector inside the calldata, not just the outermost contract address, or it isn't restricting anything meaningful.

Failure mode 3: "it can only swap" is a claim about a function signature you haven't read

This is the general version of failure mode 2. "Swap-only" is not a security property until you know exactly what parameters the swap function takes. A swap function that hard-codes the output token and the pool is a narrow, auditable action. A swap function that takes a path: address[] or a router: address parameter chosen by the caller is, functionally, "call arbitrary code with a legitimate-looking wrapper around it." The English sentence "it can only swap" is doing no work — the actual boundary is whatever the function's parameter types and the policy engine's validation of those parameters allow. Read the signature, not the label.

A practical checklist

When someone tells you an authorization is scoped, four questions separate a real boundary from a documentation claim:

Allowlisted at what granularity — contract address, function selector, or full calldata shape?
Capped on what — per-transaction, cumulative, or notional value at execution time (which can be gamed by slippage)?
Enforced where — checked by a policy engine before signing, checked by the contract itself on-chain, or just described in a UI with no enforcement at all?
What happens when a check fails — does the transaction revert, or does the check silently pass because the policy engine and the contract disagree about what "the same asset" means?

None of this makes allowlists useless. It makes them one layer, with a specific and narrow claim, that has to be paired with selector-level restriction and cap enforcement at the layer that actually executes the call — and it means the honest description of any "restricted signer" is a list of exactly what's checked and where, not the word "scoped" on its own.

Disclosure: I build Tradevo, which runs delegated strategy execution through a scoped session signer with a token allowlist, per-subscription allocation cap, and slippage limits — enforced by the signing provider's policy and by our own executor, not by the chain, which is exactly why I spent this piece on where enforcement actually lives instead of what the label says.

The Fill Model Is Where Backtests Quietly Cheat

Christian Pichichero — Thu, 03 Sep 2026 12:54:19 +0000

Every backtest has to answer a boring question: when the strategy says "buy," what price does it actually get? Most backtesting frameworks answer this question badly by default, and the badness is almost always in the strategy's favor.

Here are the four assumptions that do the most damage, roughly in order of how often they show up.

Mid-price fills

If your backtest fills orders at the midpoint of the bid-ask spread, you are assuming you trade for free. You don't. A market order pays at least half the spread to cross it; a marketable limit order pays something close to that too, once you're honest about how often it actually gets hit versus sitting unfilled while the market moves away. Mid-price fills are the single most common way a backtest manufactures edge that doesn't exist, because the effect compounds with trade frequency — a strategy that trades often looks great on mid-price fills and mediocre-to-negative once it pays the spread on every round trip.

Zero slippage

Slippage is the gap between the price your signal fired at and the price your order actually executed at, and it's not just a queuing artifact — it's partly information. If your strategy is buying because something changed, other participants are reacting to the same thing, and the price you wanted is often gone by the time your order reaches the book. A backtest with zero slippage is quietly assuming the market waits for you.

Unlimited size at the touch

Backtests routinely assume you can execute your full position size at the best bid or ask, no matter how large the order is relative to the visible size there. In practice, a large order walks the book, and the average fill price is worse than the touch price by an amount that depends on how thin the book is. This one is invisible until you try to size up, which is exactly when a strategy that looked fine in testing starts bleeding.

Commissions omitted or averaged

Commissions and fees are usually small per trade and therefore easy to skip or fold into a rough average. But a strategy with thin per-trade edge and high turnover can have its entire expectancy eaten by costs that were treated as a rounding error.

A worked example

Take a mean-reversion strategy trading a $30 stock with a 2-cent spread: average win 18¢, average loss 14¢, win rate 55%.

expectancy (per share, before costs)
= 0.55 × 18¢ − 0.45 × 14¢
= 9.9¢ − 6.3¢
= 3.6¢

That 3.6¢ looks like a real edge. But if the backtest filled at the mid, it never paid the spread it would pay in live trading. A more honest fill — buying near the ask, selling near the bid — costs roughly the full spread on the round trip, here about 2¢. Subtract that:

3.6¢ − 2¢ = 1.6¢

The edge didn't disappear, but it lost more than half its value to an assumption that never showed up as a line item anywhere in the report. Add a per-share commission and a little realistic slippage on top, and it's easy to see how a strategy with a "good" backtest turns out to be trading the spread, not an actual signal.

What you can actually check from a trade list

If all you have is a CSV of closed trades — entry, exit, size, timestamps — there's a limit to how much of this you can diagnose. You can check sensitivity: rerun expectancy with a range of assumed slippage and spread costs and see how much of the edge survives. You can check whether wins are concentrated in trades with unusually favorable prices relative to the surrounding bars, which is a proxy for lookahead or mid-price fills. You can check whether performance depends on a handful of trades — if removing the best 5% of trades erases the edge, that's worth knowing regardless of the fill model.

What you generally can't check from a trade list alone is anything that requires order book state: actual queue position, actual available size at the touch at the moment of the signal, actual latency between signal and order arrival. Those require tick-level or order-book data and a simulator that models the exchange mechanics, not just entry and exit prices. If someone tells you they can fully validate execution realism from a CSV of closed trades, they're skipping something — the honest version of this check is partial, and it should say so.

The practical test

The cheap version of all this: take your reported average win and average loss, subtract a full spread crossing on both entry and exit, and see if the strategy still has positive expectancy. If it doesn't survive that adjustment, the edge was largely the spread it never paid, and no amount of additional testing further downstream is going to rescue it. If it does survive, you've at least confirmed the edge isn't purely a fill-model artifact — which is a different question from whether it will hold up in other ways, but it's the first one worth asking.

Disclosure: I build Tradevo Verify, which takes a closed-trade export and runs it through this kind of stress-testing, among other checks, and produces a versioned evidence record rather than a verdict on whether the strategy is good.

What 'Revocable' Actually Means at the Contract Level

Christian Pichichero — Tue, 01 Sep 2026 11:05:03 +0000

If you've ever called approve() on an ERC-20 token and then moved on with your life, you've already brushed up against the thing this post is about: an approval is not a setting inside some app, it's a row in a smart contract's storage, and every system built on top of it is only as honest as its last read of that row.

Most token approvals work the same way. A user signs a transaction granting a spender contract permission to move up to some amount of a token from their wallet. The ERC-20 standard stores this as allowance[owner][spender]. Any contract that wants to move the user's tokens checks that number before doing so, and the check happens inside the same transaction that tries to move funds — so the contract-level enforcement is real. The token contract itself will not let a transfer through if the allowance is insufficient.

Revocation is just another write to that same slot, usually setting it to zero. It's a normal transaction. It has to be signed, broadcast, and mined like any other. That's the part people gloss over: revoking is not a UI toggle, it's a transaction with all the same properties as the transaction that created the approval in the first place — it sits in a mempool, it can be delayed by network congestion, and it isn't final until it's in a confirmed block.

Where the gap shows up

Say you're building a service that executes on a user's behalf using a stored approval — a trading bot, a subscription payment puller, anything with an off-chain component that decides when to spend and an on-chain component that actually moves the funds. The natural design is to keep a local record: "user X has approved up to Y, active." That record is convenient. It's also just an opinion your own server holds about the world, and it can be wrong in both directions.

It can be wrong stale-permissive: the user revokes, your service hasn't seen it yet, and if the on-chain check before spending is missing or weak, you build and sign a transaction anyway. Depending on how you structured the check, this either fails harmlessly at the token contract (wasted gas, a failed tx, an alert) or, if you did something sloppier — like checking your database instead of the chain — you send a transaction that the chain itself will still reject, because the allowance really is zero now. The token contract is the backstop here, which is good, but you don't want your system's normal path to depend on that backstop catching your own mistake.

It can also be wrong stale-restrictive: your database says revoked, but the revoke transaction is still sitting unconfirmed, and the user expects it to be in effect immediately because that's what the button said. This one is more of a UX problem than a safety problem, but it's the same root cause — a record and the chain disagreeing about what's true right now.

Why the check has to happen at the moment of execution

The fix sounds almost too obvious to write down: before doing anything that spends a user's tokens, read the allowance from the chain, right then, not from whatever your database cached the last time you looked.

function attemptExecution(user, requiredAmount) {
 onChainAllowance = readAllowance(user); // the ground truth, right now
 if (onChainAllowance < requiredAmount) {
 skipAndLog(user, "allowance insufficient at execution time");
 } else {
 sendExecutionTx(user, requiredAmount);
 }
}

This has real costs. Every execution now needs an RPC round-trip before it can act, which adds latency and adds load on whatever node provider you're using. If you're executing for many users on a schedule, that's a lot of extra reads for what is, most of the time, a value that hasn't changed since the last check. There's also a subtler question buried in "read from the chain": read at what block? RPC providers don't all agree on the very latest block during a reorg, and a read that lands on a block that later gets replaced is its own small version of the same trust problem, one layer down. Treating the freshest confirmed state as authoritative, and re-checking rather than caching, is the mechanism — it doesn't make the read instantaneous or immune to provider disagreement, it just means you're asking the right question at the right time instead of trusting an answer that might be minutes or days old.

What breaks mid-cycle

The uncomfortable case is a multi-step action — say a swap that routes through two pools, or a strategy that does three on-chain calls in sequence to complete one logical action. If a user revokes between step one and step two, step one already happened. You can't undo it. The system has to be built so a partial completion is a safe, loggable state rather than an unrecoverable one — which mostly means designing each step so it's fine to stop after it, not chaining steps that only make sense together and hoping revocation never lands in the middle. That's a design constraint, not something the revoke mechanism itself solves for you.

None of this makes revocation less real. The user genuinely can remove the authorization, and once that transaction confirms, the contract genuinely will not let the spender move their tokens anymore — that part is enforced by the token contract itself, not by anyone's goodwill. What it means is narrower and more mechanical than "revocable" sounds: it's a state change on a specific chain, subject to that chain's confirmation times, and any executor sitting on top of it is only trustworthy if it treats its own records as a guess and the chain as the check.

Disclosure: I build Tradevo, which runs automated strategies on Base from wallets whose keys the user holds. More at app.tradevo.co. The trade-offs above are ones I have had to think through rather than ones I am claiming to have solved.