Execution infrastructure for intent-driven applications.
ExeKPro is a modular execution kernel: applications express an intent, compatible execution modules are simulated and scored against an explicit policy, and the best-compatible module executes — through the end user’s own wallet, not ours.
Hard-coded execution strategies don't age well.
Most applications pick one execution path at build time and live with it. ExeKPro lets that decision happen at execution time instead, against real, comparable data.
- 1Intent, leads to
- 2One predefined strategy, leads to
- 3Execution
- 1Intent
- 2Multiple compatible strategies
- 3Simulation
- 4Policy-based scoring
- 5Selected execution
- Execution strategies evolve — a routing path or protection scheme that's optimal today rarely stays optimal indefinitely.
- Different environments produce different optimal paths — there is rarely one execution strategy that's best everywhere, always.
- Applications shouldn't need to rewrite their core execution logic every time a better strategy becomes available.
- Execution should be modular and observable, not a black box buried in application code.
One execution round, evaluated explicitly.
Every intent goes through the same five steps — no hidden routing, no implicit preference for one module over another.
- 01
Intent
An application expresses what it wants to accomplish — an intent type and its parameters, not a specific execution path.
- 02
Discover
The kernel retrieves every execution module currently registered as compatible with that intent type.
- 03
Simulate
Each compatible module runs a simulation and produces an ExecutionQuote — a standardized, comparable description of what it would do.
- 04
Score
ScorePolicy evaluates every quote against configured execution criteria and produces a ranked, signed score for each candidate.
- 05
Execute
The highest-scoring compatible module executes the intent — signed by the end user's own wallet, not the kernel or its operator.
ExecutionQuote is what every module speaks.
The kernel never needs to understand a module’s internal implementation — routing logic, MEV protection, or a strategy not yet built. Every module exposes the same comparable characteristics through ExecutionQuote, and that’s all ScorePolicy needs to rank them. These four fields are what the current kernel scores on — not a ceiling on what a quote could eventually describe.
- executionCost
- Cost efficiency of this execution path — lower is better.
- executionQuality
- Expected quality / success probability of the execution — higher is better.
- mevRisk
- Exposure to MEV extraction along this path — lower is better.
- latencyScore
- Time-to-finality characteristics of this path — lower is better.
Modules are independent execution strategies.
Each module implements the same interface and competes on the same terms. The kernel doesn't favor one implementation over another — ScorePolicy does, based on what each one actually quotes.
A routing strategy — one compatible module competing for selection under the same scoring policy as any other.
Trades cost and latency for materially lower MEV exposure — registered for the same intent type, evaluated on the same terms.
The architecture allows further compatible modules to compete under the same execution framework. Module registration is currently owner-controlled per deployment — this is not yet an open, permissionless module ecosystem.
One kernel. One customer. One isolated deployment.
Each customer receives a dedicated kernel deployment, not a seat in a shared, multi-tenant one. This isn't a SaaS custody model — nothing is pooled or shared between customers.
- The customer owns the deployment, through ProtocolRoles — not ExeKPro.
- The customer’s applications and tooling point at that specific deployment, and only that one.
- No shared tenant state: one deployment’s registered intents and modules never interact with another’s.
Integrate through the SDK. The kernel stays on-chain.
Every off-chain layer is a typed, composable piece — nothing about integration requires reimplementing kernel logic in application code.
The on-chain execution kernel — engine, registries, scoring policy, modules.
Shared, zero-runtime-dependency types mirroring every on-chain shape.
The typed Ethereum client every off-chain layer is built on.
A typed client bundling every contract — the primary integration surface.
Read-only registry state, gas-free predictions, and execution metrics.
Observes kernel events and derives execution/selection metrics.
The reference protocol console — an interactive view into a live kernel.
Engineering evidence, not marketing claims.
This is a serious engineering prototype approaching testnet validation — exercised against real deployed bytecode and real transactions, not mocked interfaces. It is not a production deployment, and it has no mainnet presence.
“1–100” describes the range of candidate module counts exercised in testing — not a claim that 100 production modules are currently deployed or registered anywhere.
Custody and control stay with the customer and the user.
These aren't aspirational — each one maps to a specific, verifiable property of the current architecture.
Non-custodial
The end user's own wallet signs every execution. ExeKPro provides the execution infrastructure an application uses to evaluate and execute intents — it never holds a private key on anyone's behalf.
Deterministic selection
Module selection follows an explicit, inspectable scoring policy — never a hidden or arbitrary preference for one execution path over another.
Module isolation
A broken or reverting candidate module is skipped, not fatal — it cannot block execution for every other module registered on the same intent type.
Customer isolation
Each customer's kernel is its own deployment, with its own owner and its own registries — no shared tenant state to leak across.
Test-driven security
Adversarial and fuzz testing is how real issues have actually been found in this codebase — three, so far, all fixed before they mattered.
What's implemented, and what's next.
No fixed dates — this distinguishes what's been built and verified from what's planned, nothing more.
- Local deployment fully validated
- Sepolia configuration ready
- Deployment scripts ready
- B2B provisioning implemented
- Sepolia deployment
- Developer testing
- Integration feedback
- Market validation
Build on an execution kernel.
Explore the protocol, inspect the architecture, or deploy your own kernel.