Race Condition

Sei’s optimistic scheduler can use a Geth-derived EVM and fall back to sequential execution after repeated validation attempts. Those implementation choices concern capacity. Its oracle votes, sponsored application interactions and staged withdrawal of Cosmos interfaces also change the activity through which demand is evaluated. A reported transaction count can be accurate while leaving its economic interpretation conditional on the protocol, campaign and population that produced it.

Released source, governance documentation and dated network reports make those relationships inspectable. The reports use different transaction populations, including different treatment of oracle traffic, and describe an application-specific decline following gas sponsorship. Comparing these records identifies what an activity measure can independently confirm about demand. The analysis supplies no new transaction census, measured subsidy effect or causal explanation of valuation.

Parallel execution concerns how a system schedules work whose final effects must respect a valid transaction order. Reusing an EVM implementation concerns the execution semantics within that work. The two choices can coexist. A scheduler can execute independent transactions concurrently, detect conflicts and re-execute affected work using a Geth-derived engine. It need not replace the EVM instruction set to parallelize transaction execution.

The released Sei source makes that composition inspectable. The October review resolves v6.7.2, published on 16 October, to commit 02df238d64de1e0ffd9e941f520c202c02f6b0f6. Its sei-cosmos/tasks/scheduler.go defines maximumIterations = 10 and switches to synchronous processing after repeated validation attempts. The fallback bounds repeated speculative work when dependencies prevent useful concurrency. It is compatible with an optimistic parallel design. It establishes neither the frequency of fallback on the network nor a typical throughput result (Sei Protocol 2026a, lines 284–364).

The EVM keeper calls vm.NewEVM with Sei state, configuration and precompiles. Its module file maps the upstream Go import to github.com/sei-protocol/go-ethereum v1.15.7-sei-20. That is evidence of an integration with a named fork. The call alone establishes neither an unmodified upstream VM nor complete equivalence with Ethereum. The project’s own V2 explanation openly describes importing Geth and adapting its state interface (Sei Protocol 2026b; Sei 2023b).

Compatibility therefore needs a specified surface. Bytecode acceptance, opcode behaviour, gas accounting, RPC methods, state proofs and interoperability can differ. Sei’s documentation names several such differences. A chain can support familiar EVM contracts and tools while requiring application-specific changes at another surface (Sei Documentation n.d.-a).

The storage-write gas parameter illustrates the distinction. The reviewed release defines a default of 20,000 for SeiSstoreSetGasEIP2200, reads a configured value in its keeper and passes it into EVM configuration (Sei Protocol 2026c). A further endpoint check supplies a dated configured value: at native height 238316297, the Cosmos parameter response reports KeySeiSstoreSetGasEIP2200 as 72000, and the native and EVM block hashes agree (Sei Queries 2026).

A read-only state-override call at that height sets an empty slot to one and returns it with a gas allowance of 110,000. The same write exhausts 50,000, while a read-only control succeeds with 50,000. The synthetic code changes no chain state. The calls test the responding node’s simulated execution path alongside its reported parameter; they do not measure paid transaction costs or supply an executed Ethereum comparison. The source default and the observed configuration now describe distinct, identified objects (Sei Queries 2026).

A performance claim needs more than these source observations. Hardware, transaction composition, dependency structure, software version and the measured completion point determine its meaning. Capacity under a reproducible workload and the amount of work users submit are separate measurements. A low observed transaction rate can coexist with unused capacity, and a high count can consist largely of protocol operations.

The history does not support a simple sequence of mutually exclusive investment theses attached to an unchanged implementation. Sei’s April 2023 funding announcement still presents a chain for trading. Its V2 account describes adding an EVM environment, optimistic execution and a redesigned storage interface. A later concentration of gaming activity concerns application composition. These descriptions address different aspects of a system and can overlap (Sei 2023a; 2023b).

Publication dates need their own care. The V2 page is dated November 2023 but explicitly reports a September 2025 update. Its retrospective account must not be presented as an untouched announcement made before deployment. It is useful evidence of the project’s description at retrieval, with its revision visible.

SIP-3 proposes a substantive change in the supported environment. Its source distinguishes an EVM-only objective from milestones involving pointers, new CosmWasm deployments and remaining legacy interactions. A proposal establishes the intended change. Individual decisions and implementation records establish which parts have taken effect (Su 2025).

The May 2026 announcement describes disabling new CosmWasm uploads and instantiation while preserving existing contracts. The current migration guide separately reports inbound and outbound IBC closure, attributing outbound closure to Proposal 121 on 31 July. It continues to distinguish existing balances and executable contracts from disabled transfer or deployment routes. The reviewed explorer pages display passed proposals for the named restrictions. This paper reports those documented states without independently replaying their governance execution (Sei 2026a; Sei Documentation n.d.-b; Nodes.Guru n.d.; Seistream n.d.).

The repository comparison reinforces the need to name the object being examined. The captured v6.7.2 tree retains an x/oracle source directory; the separately pinned development tree at 3608f909789bc60f9c3becbb8071be4e59ed4e1f has none. Presence of a source directory does not establish that its former service is active. Its absence on a development branch does not establish the software installed by validators. A persistent repository name supplies no measurement of architectural continuity (Sei Protocol 2026a; 2026d).

The distinction has practical consequences for adoption research. A change in permitted deployment, bridging or transaction interfaces changes the opportunities users have to act. Evaluating retention or growth across that transition requires identifying the supported routes and relevant dates. An address-series discontinuity may concern access or classification as well as a change in willingness to use the network.

Sei’s native oracle supplies a concrete reason to distinguish transaction throughput from application demand. Validator price votes are transactions produced to operate the protocol. Their existence can increase a network’s recorded activity independently of purchases, trading decisions or a new application user. A system that removes such a service could reduce its raw transaction count without reducing application demand. This is a conditional consequence of the counting rule, rather than a measured post-upgrade effect.

The distinction appears in the provider reports themselves. Krasnicki’s Q4 2024 report gives 4.2 million average daily transactions and identifies an approximately four-million daily floor from validator oracle votes. Kreiser’s Q4 2025 report separately gives 2.3 million average daily transactions by active addresses after filtering oracle transactions. The earlier total and later filtered count cannot be treated as the same series without reconstruction. The populations differ, so this paper does not calculate a trend from the two reports (Krasnicki 2025; Kreiser 2026).

Protocol composition also affects apparent performance. Counting short administrative transactions and counting more expensive contract calls can yield different transaction rates for similar computational work. A headline TPS figure cannot identify application demand without its transaction population. The scheduler’s capacity and the oracle’s contribution to observed counts answer different questions even when both concern the same chain.

The same discipline applies to addresses. A signing address is an observable identifier, while a person, customer, application operator or economic counterparty is an attribution. One actor can operate many addresses, and one intermediary can represent many users. Sei’s migration materials additionally describe paired native and EVM address representations. A comparison must state whether it counts either namespace, resolves associations or uses application-specific identities. None of those choices is supplied by the phrase active users.

An incentive programme can produce real use and useful learning. Paying a player’s transaction fees can let the player try a game, while liquidity rewards can make an exchange usable. Activity during such a programme measures behaviour under those conditions. It does not, without further comparison, estimate behaviour after the condition changes.

Endogenous metric capture concerns the inference that an output partly produced by an intervention independently confirms self-sustaining demand. Common investors, public funding announcements or an ecosystem grant do not by themselves answer it. A subsidy can support a product that later attracts paying users, and a rewarded interaction can still benefit its participant.

The reports resist a division into cheap activity metrics and inherently independent financial metrics. In Q4 2024, reported active addresses rose sharply, but fee revenue and DEX volume also rose and dollar TVL stayed roughly flat. In Q4 2025, reported dollar TVL fell 63.5%, against a 9.1% decline when denominated in SEI. Valuation and portfolio composition matter, so neither series directly measures net deposits. The later report attributes an Archer Hunter activity decline to earlier gas sponsorship; that is a reported application-specific account, not this paper’s transaction tracing or an ecosystem-wide subsidy estimate (Krasnicki 2025; Kreiser 2026).

Fees can be paid from a sponsored wallet. Liquidity can remain because rewards exceed its opportunity cost. Trading volume can be influenced by rebates. These possibilities make payer, beneficiary, funding source and retention relevant across financial and non-financial measures. They do not prove that the observed activity was manufactured, coordinated or economically worthless.

An independent analytics provider can accurately count programme-produced activity. Independence of the measurement process is different from independence of the measured demand from the programme. Conversely, a report commissioned by an interested party can contain useful, inspectable data. Publication relationships and economic attribution require separate examination. This paper does not establish that Sei funded the reviewed reports or controlled their conclusions.

A stronger study would begin with a named claim about adoption. A gaming programme might aim to retain players, while a liquidity programme might aim to establish an executable market. Those objectives require different outcome measures. Neither needs a universal revenue or TVL threshold chosen after inspecting the results.

For a named programme, the analysis would reconstruct the eligible population, announced rewards, actual disbursements, sponsored gas and relevant contract interactions. Fee payer and transaction beneficiary should remain distinct. Address attribution needs explicit uncertainty, and protocol maintenance traffic should be reported separately. A versioned series would record interface, oracle and application-classification changes rather than silently treating the network as a fixed population.

Retention after a reward ends is informative, but a decline alone identifies no causal effect. Product changes, market conditions, security incidents and access restrictions can change at the same time. A transparent retrospective comparison, a useful natural experiment or a prospective design could help separate those explanations. Matching a particular method to the question is preferable to requiring one experimental form for every historical case.

The capacity side requires its own observations: reproducible workload generation, hardware and software identity, dependency patterns, retries, fallback frequency and completion latency. Such a test could establish when the parallel design creates a benefit. It would not establish that users value the benefit enough to sustain an application, and a demand study would not independently validate the scheduler’s performance.

Evidence supporting durable subsidized acquisition would weaken a claim that activity depended entirely on continuing rewards. Funding paths that cannot be tied to the measured population would weaken a proposed attribution. These are tests of particular explanations. A later repair, protocol migration or new application should instead create a dated comparison, with the earlier observation retained in its original scope.

Sei’s technical composition and changing interfaces matter to how its growth is evaluated. Parallel scheduling around a Geth-derived engine is a coherent implementation choice. Oracle votes and application interactions contribute different kinds of activity. Incentives can create conditions for use whose persistence remains an empirical question.

An adoption study must identify which transactions the network permits and which activities its measure includes, then trace the funding and retention of the relevant participants. Technical change can alter what is countable, while funding can alter why activity occurs. Sei’s source and reports identify where those checks belong; they leave the durability and causes of demand to be measured.

This is a documentary and source-code analysis. The October review pins released and development revisions separately and checks selected source bytes against their Git tree blobs. The review also includes a height-pinned parameter query, matching native/EVM headers and three state-override calls. These read-only simulations use synthetic code and empty storage at a supplied address. They submit no production transaction and identify no validator-wide binary inventory. The study performs no local scheduler build, workload benchmark, chain transaction census, treasury-flow reconstruction or causal valuation study.

The Messari figures are attributed observations from the primary pages, read through the web reader. Their transaction populations and periods are stated in the text. Direct requests returned HTTP 429 rather than article bodies, so the numerical series is not independently reproduced here. The retained analyst note records the page readings; inaccessible funding pages supply no factual support.

The technical interpretation preserves the distinction between an execution engine and its scheduler: a Geth-derived EVM can run within an optimistic parallel architecture, and a synchronous fallback can be a deliberate response to contention. The economic interpretation separately asks which measured activity depends on protocol requirements or funded incentives. Neither conclusion establishes manufactured adoption or a cause of market repricing.