Execution Layer for On-Chain Automation
Permissionless execution network with on-chain condition verification. No trusted keepers. No off-chain dependencies.
Optimistic execution · Executor staking · MEV-resistant ordering
RPC: mainnet.base.org · Real block data · No validators · No token
Protocol Capabilities
Infrastructure for Autonomous Protocols
Execution primitives for protocols that need reliable, verifiable automation
Conditional Execution
Register conditions as on-chain state predicates. Heliora evaluates against storage slots, oracle feeds, or block parameters. Conditions are immutable once registered.
Supports: storage proofs, Chainlink/Pyth oracles, block.number, block.timestamp
Execution Finality
Optimistic finality with 10-block challenge window. Immediate finality available with validity proofs (ZK mode). Executors post bonds proportional to execution value.
Finality: 10 blocks optimistic, instant with ZK proof
Gas Efficiency
Batch multiple executions into single transaction. Calldata compression for L2s. Executors compete on gas price, not just speed — protocols pay market rate.
Avg savings: 40% via batching on L1, 70% on L2
Base-Native
Core execution primitives deployed on Base. No custom chain, no validators, no token. Leverages Base's security and low fees as the primary execution layer.
Primary: Base · Adapters: Ethereum, Arbitrum, Optimism
SDK & Tooling
TypeScript and Solidity SDKs for condition registration and monitoring. Simulation mode for testing execution logic before mainnet deployment.
npm: @heliora/sdk · forge: heliora-contracts
Execution Dashboard
Monitor condition status, execution history, and executor performance. Webhook notifications for execution events. Exportable logs for auditing.
API: REST + WebSocket · Export: JSON, CSV
Protocol Architecture
How Execution Works
Heliora separates condition definition from execution. Protocols specify what should happen; the executor network handles when and how.
Condition Registry
On-chain registry on Base where protocols define execution conditions. Conditions are immutable once registered and reference specific contract states, oracle feeds, or block parameters.
- →Condition hash stored on Base
- →References to state slots / oracle addresses
- →Expiry and execution window parameters
Executor Network
Permissionless set of executors who stake collateral and compete to fulfill conditions. Any address with minimum stake can become an executor. No whitelisting.
- →Minimum stake: 1 ETH (configurable per condition)
- →Executor selection via commit-reveal auction
- →Stake slashable for invalid or delayed execution
Verification Layer
Execution validity is proven on-chain. Verifier contracts check that the condition was true at the claimed block before finalizing execution.
- →Merkle proof of condition state
- →Block header verification
- →Challenge period: 10 blocks (optimistic)
Settlement
After verification, execution is finalized. Executor receives fee from protocol. If challenged and found invalid, stake is slashed and challenger rewarded.
- →Fee paid in ETH or ERC-20
- →Slash: 100% of execution stake
- →Challenger reward: 50% of slashed stake
// 1. Protocol registers condition on Base
registry.register({
condition: "oracle.price(ETH/USD) > 3000",
callback: liquidator.execute(vaultId),
stake_required: 1 ether,
max_gas: 500_000,
expiry: block.number + 7200 // ~24h
});
// 2. Executor commits to execute
executor.commit(conditionId, commitment_hash);
// 3. Condition becomes true at block N
// 4. Executor reveals and executes
executor.reveal(conditionId, nonce); // within reveal_window
executor.execute(conditionId, proof); // merkle proof of condition
// 5. Verification (optimistic)
// - If no challenge in 10 blocks: finalized
// - If challenged: verifier checks proof on-chain
// - Invalid execution: executor slashed, challenger rewarded
// Cross-chain execution (via adapter)
adapter.executeOnChain(chainId, conditionId, proof);Trust Model
Cryptoeconomic Execution Guarantees
Existing automation solutions rely on trusted operators or committee consensus. Heliora uses optimistic execution with fraud proofs — the same security model that secures optimistic rollups.
Technical Differentiator: Heliora is the first execution layer where condition verification happens entirely on-chain. No custom chain. No validators. No token. Execution primitives deployed on Base.
Execution Correctness
Invalid executions are detected and penalized. Verifier contracts check Merkle proofs of condition state.
Liveness
Economic incentives ensure execution. Unfulfilled conditions with sufficient fee attract competing executors.
MEV Resistance
Commit-reveal prevents front-running of execution. Executors commit to condition ID before revealing execution details.
Developer Experience
Built for Protocol Developers
Everything you need to automate on-chain logic
Execution Layer
Infrastructure that handles all execution complexity. Focus on your protocol logic, not execution mechanics.
// Define execution condition
const condition = {
type: "price_threshold",
asset: "ETH/USD",
threshold: 3000,
direction: "above"
};
// Register with Heliora
heliora.register(condition, callback);Condition Monitoring
Monitor on-chain state and trigger executions when conditions match. Real-time event processing.
// Monitor multiple conditions
heliora.monitor([
{ contract: "0x...", event: "Transfer" },
{ oracle: "chainlink", pair: "ETH/USD" },
{ block: { interval: 100 } }
]);Failure Recovery
Automatic retry mechanisms with configurable backoff strategies. Ensure critical operations complete.
// Configure retry strategy
heliora.setRetryPolicy({
maxAttempts: 5,
backoff: "exponential",
initialDelay: 1000,
maxDelay: 30000
});Gas Management
Intelligent gas pricing and batching to minimize costs. Optimize protocol economics.
// Enable gas optimization
heliora.enableGasOptimization({
batchSize: 10,
maxGasPrice: "50 gwei",
priorityFee: "auto"
});Network Metrics
Live Network Status
Real-time data from Base mainnet RPC. Stats from local database.
Jobs created in this instance
Successfully completed jobs
Currently monitoring conditions
Executed / (Executed + Failed)
Ready to Build Autonomous Protocols?
Deploy execution conditions on testnet. Simulate execution flows. Ship to mainnet when ready.
Network Access
Execution Access Tiers
Pay for network access. Execution fees and gas paid separately per condition.
Testnet
Development and integration testing
- Base Sepolia testnet
- 100 condition registrations
- 1,000 executions/day
- 5 min condition check interval
- Community Discord support
Mainnet
RecommendedProduction execution access
- Base mainnet
- Unlimited conditions
- 10,000 executions/day
- 1 block condition check interval
- Priority executor assignment
- Webhook notifications
Enterprise
Dedicated infrastructure tier
- Private executor set option
- Unlimited executions
- Custom condition types
- Sub-block latency (MEV integration)
- On-call engineering support
- Security review of conditions
Fee Structure
Primary execution on Base. No custom chain. No validators. No token.
Access Control & Execution Keys
Network access is controlled via off-chain issued credentials enforced at the execution layer.
// Access Keys Model
- →Execution Keys are issued off-chain upon tier activation
- →Each key is bound to a specific protocol address
- →Keys define rate limits, execution quotas, and network scope
- →Keys are not tokens — no transfer, no on-chain representation
// Execution Enforcement
- →Condition registration rejected without valid Execution Key
- →Rate limit exceeded: execution queued or dropped per tier policy
- →Revoked keys: immediate execution halt, no pending condition processing
- →All enforcement happens at Heliora execution layer, not on-chain
// Tier-specific Key Behavior
// Security Guarantees
- →Rotation: Keys can be rotated without execution downtime
- →Revocation: Instant key invalidation via control plane
- →Isolation: Protocol A cannot invoke conditions of Protocol B
- →Audit Log: All key operations logged for compliance
⚠ Access to execution network is controlled via off-chain issued credentials. No on-chain staking or slashing is active in this phase.
Technical FAQ
Frequently Asked Questions
Executors post stake proportional to execution value. After execution, there's a 10-block challenge window. Anyone can submit a fraud proof showing the condition was not met at the claimed block. Invalid executions result in full stake slashing — 50% to challenger, 50% burned. This is the same security model used by optimistic rollups.
Join the Executor Network
Run an executor node. Stake ETH. Earn execution fees. Permissionless participation.
Stay Updated on Protocol Development
Get updates on new features, network improvements, and execution patterns. Join the developer community.
No spam. Unsubscribe anytime.