ExeKPro
Execution Kernel ProtocolModular Blockchain Execution Infrastructure
SolidityFoundryTypeScriptviemNode.jsNext.jswagmiFastify
ExeKPro is an execution-selection protocol for Web3 intents. Instead of binding an intent to a single execution strategy, the kernel evaluates independently deployed execution modules and selects the highest-scoring valid candidate under a shared scoring policy.
Execution Model
Every execution is one evaluation round: independently deployed modules compete for a single intent, and the highest-scoring valid candidate executes it. The current protocol selects exactly one winning module per execution.
INTENT→ELIGIBLE MODULES→SIMULATION→SCORE POLICY→HIGHEST-SCORING MODULE→EXECUTION
Architecture
On-Chain Kernel
- IntentRegistry
- Defines and validates registered execution intents.
- ModuleRegistry
- Controls which execution modules are eligible for selection.
- ExecutionEngine
- Evaluates eligible modules under the active scoring policy and executes the selected candidate.
- ScorePolicy
- Provides the deterministic scoring mechanism used to compare candidates.
- ProtocolRoles
- Defines protocol ownership and administrative boundaries.
Execution Modules
- RouterModule
- An independently deployed routing strategy competing for selection.
- MevProtectionModule
- An independently deployed MEV-protection strategy competing for selection under the same policy.
Off-Chain Infrastructure
- SDK
- A TypeScript client built on viem, providing the primary integration surface for intents and execution.
- Execution Node
- Processes intents off-chain and prepares execution for submission through the SDK.
- Indexer
- Observes kernel events and derives execution and selection metrics.
- API
- A read-only Fastify service exposing registry state, predictions, and execution metrics.
Protocol Console
- Console
- A Next.js application, built on wagmi and viem, providing the interactive protocol interface and wallet-driven execution.
System Boundaries
- Ownership
- Each kernel deployment has explicit protocol ownership through ProtocolRoles.
- Deployment Isolation
- Each deployment maintains its own protocol state and ownership boundary. The current architecture uses isolated kernel deployments because IntentRegistry does not provide tenant namespacing.
- Execution
- Execution is non-custodial. The console submits transactions through the connected user's own wallet. There is no hosted custody layer.
- Separation of Concerns
- Intent registration, module registration, execution policy, execution, indexing, and presentation are separated into distinct system boundaries.
Validation
- 43/43 contract tests passing
- Adversarial and fuzz validation
- 3 implementation issues identified and resolved through adversarial testing
- Real browser E2E against the local protocol environment
- CI validation on every PR
Current State
ExeKPro is end-to-end validated against a local Anvil environment, with the protocol console publicly available at exekpro.com. A public testnet or mainnet deployment is not currently available.
Scope
- Deterministic module selection
- One winning execution module per intent
- Registered execution modules
- Policy-driven scoring
- Isolated protocol deployments
- Non-custodial wallet execution
- Indexing and observability
- SDK, API, and console integration
Out of Scope
- Multi-module execution graph chaining
- Permissionless module registration
- Governance timelocks
- Persistent indexer storage
- Hosted transaction submission or custody