Alphabetically ordered list of terms used in this repository.

Helios A next-generation blockchain designed for interchain automation, AI-powered smart contracts, and decentralized governance, enabling seamless interactions across multiple ecosystems.

Governance The process by which stakeholders and validators influence network parameters, including asset management, protocol updates, and economic incentives through proposals and voting.

Validator A node that participates in the Helios network by securing the blockchain, validating transactions, and influencing governance decisions based on their stake and reputation.

Staking The process of locking assets in the Helios network to support operations such as transaction validation and governance, while earning rewards in return.

Interchain Proof of Stake and Reputation (I-PoSR) A hybrid consensus mechanism that combines staking across multiple chains with a reputation-based model, enhancing security and decentralization.

Hyperion Modules Modular components that facilitate cross-chain interactions, enabling secure asset transfers and decentralized oracle functionalities within the Helios ecosystem.

Asset Weight The relative importance of an asset in the staking consensus, which can be adjusted through governance proposals to influence staking incentives and rewards.

Proposal A formal suggestion submitted by community members or validators to modify network parameters, add or remove assets, or implement upgrades, which is then voted on by stakeholders.

Community Governance A system that empowers Helios stakeholders to participate in decision-making processes, ensuring that the network evolves according to the collective interests of its users.

Decentralized Applications (dApps) Applications built on the Helios blockchain that leverage its features for various use cases, including finance, gaming, and automation, while ensuring user control and security.

Cross-Chain Transactions Transactions that occur between different blockchain networks, facilitated by Helios interoperability features, allowing seamless asset movement and interaction.

Reputation Score A metric that reflects a validator’s performance and reliability, influencing their voting power and decision-making authority within the governance framework.

Helios Portal An interface within the Helios Portal that provides insights into active and past governance proposals, allowing users to track decisions and participate in the governance process.

Treasury A fund managed by the Helios Foundation that collects slashed assets from misbehaving validators, which can be used for ecosystem incentives or liquidity provision.

Developer Grants Financial support provided to developers and projects building on the Helios blockchain, aimed at fostering innovation and enhancing the ecosystem’s capabilities.

Welcome to the Helios Network HIP Book

Approved

HIPs

HDs

Review

Welcome to the Helios Network HIP Book

Approved

HIPs

HDs

Review

HIP-1: Native On-chain Cron Scheduling (Chronos Module & Precompile)

Description: Introduce a native cron scheduling module (Chronos) with a dedicated EVM precompile, allowing developers to schedule and automate periodic tasks directly on-chain within the Helios blockchain.
Motivation: Decentralized applications often rely on external cron scheduling services, introducing complexity, reliability concerns, and potential security risks. A native cron scheduling system provides a decentralized, secure, and developer-friendly solution.

Abstract

The Chronos module offers native cron job scheduling directly integrated into Helios blockchain through a dedicated EVM precompile, allowing for automated periodic execution of smart contract methods. This simplifies the creation and management of scheduled tasks, significantly enhancing decentralized application development.

Motivation

Blockchain applications require periodic automated execution of smart contract methods. The existing external solutions are neither fully decentralized nor optimal in terms of security and efficiency. A built-in cron scheduling mechanism ensures reliability, decentralization, and seamless integration.

Specification

Key Features

Native Integration: Implemented as an EVM-compatible precompile (0x0000000000000000000000000000000000000830).
Cron Job Management: Includes functionalities for creating, updating, and canceling cron jobs.
Unique Cron Addresses: Each cron job is assigned a unique blockchain address.
Gas Management: Users deposit funds upon cron creation, covering continuous gas consumption (set at 100 gas per block) and executions costs.
Cron Lifecycle Events: Emits blockchain events (CronCreated, CronModified, CronCancelled) for enhanced transparency.
Automatic Cancellation: Cron jobs are canceled automatically when their balance reaches zero or a critical error occurs during execution.
Multiple RPC Endpoints: RPC endpoints to take a look cron(s) (querying).

Technical Implementation

ABI provided for easy integration with popular web3 libraries such as Ethers.js.

Acceptance Criteria

Cron tasks can be created, updated, and canceled effectively.
Each cron task has a unique blockchain address.
Funds deposited during cron creation accurately manage and consume gas (100 gas per block).
Cron jobs automatically cancel upon depletion of funds or errors.
Lifecycle events (CronCreated, CronModified, CronCancelled) accurately emitted.
Comprehensive unit and integration tests covering all key functionalities and edge cases.
Detailed developer documentation provided, including setup instructions, RPC endpoints, API usage, limitations, and best practices.
Successful cron task scheduling, execution, and lifecycle management.
Automatic cancellation behavior clearly defined and verifiable.
Robust documentation provided in Chronos.
Community feedback and peer reviews adequately addressed.

Changelog

2025-04-14: Initiate the HIP-1

HIP-2: Delegation Boost for Enhanced Staking

Feature Overview

A new Delegation Boost mechanism has been introduced in the staking module, allowing delegators to deposit additional tokens (in a specialized “boosted” pool) that increase their rewards proportionally. This addition brings several novel concepts, parameters, and message types to the Cosmos-based network.

Motivation

Standard delegation involves delegators bonding tokens directly to validators, but previously had no way to “boost” or multiply their stake without simply adding more tokens in the same manner. Delegation Boost introduces a secondary stake pool that augments the staking power of a validator and potentially increases the delegator’s reward payout. This fosters deeper collaboration between delegators and validators and opens up new economic incentives in the network.

Objectives

Provide Flexible Staking Options: Enable a dedicated method to “boost” stake in addition to normal delegation, with potential for higher rewards.
Enforce Minimum Boost Requirements: Allow validators to specify a min_delegation as a threshold for boosted delegation.
Enable Enhanced Reward Calculations: Incorporate boosted delegations into reward distribution using a flexible multiplier defined by a network parameter (BoostPercentage).
Streamline Staking Flows: Maintain a clear distinction between regular staked tokens and boosted tokens, with dedicated messages for deposit and withdrawal.

Key Features

Boosted Pool Account
- A new module account (boosted_tokens_pool) holds tokens delegated as a boost.
- Ensures clear tracking and isolation of boosted tokens from regular staked tokens.
Boost Ratio & Rewards Multiplier
- The distribution module calculates a “boost ratio” for a validator by comparing its total boosted stake to its overall staked amount.
- A configurable BoostPercentage parameter governs how much of a multiplier this ratio adds to the rewards.
Validator-Based Settings
- min_delegation: A validator can specify the minimum boost required for delegators.
- delegate_authorization: Determines whether anyone other than the validator can add a boosted delegation.
New Message Types
- DelegateBoost(...): Delegates tokens to the boosted pool, tracked separately from normal staking.
- UnDelegateBoost(...): Withdraws boosted tokens, reducing the delegation’s effective multiplier.
Enhanced Store and Queries
- New keys and indexing in the staking keeper track total boosts for each validator and each (delegator, validator) pair.
- Functions like GetTotalBoostedDelegation and GetValidatorDelegationsBoost enable easier lookups of boosted stakes.
Genesis & Parameter Integration
- The chain’s genesis process now initializes the boosted_tokens_pool and parameters such as BoostPercentage.
- Operators can manage BoostPercentage, min_delegation, and delegate_authorization via governance or direct configuration.

Technical Implementation

Extended Staking Keeper Methods:
- DelegateBoost, UnDelegateBoost, SetDelegationBoost, and GetDelegationBoost orchestrate storing boosted tokens and updating delegated amounts.
- The keeper enforces min_delegation and delegate_authorization when delegations occur.
Modified Reward Distribution Logic:
- Updated distribution code fetches a validator’s boostedTotal tokens, calculates a boostRatio, and multiplies the base rewards by 1 + (BoostPercentage * boostRatio) (capped at a maximum of 1:1 ratio for the boost portion).
New Proto Definitions:
- MsgCreateValidator and MsgEditValidator now include min_delegation and delegate_authorization.
- Messages for delegating/undelegating boosts are defined and handle moving tokens to and from boosted_tokens_pool.
Module Accounts & Balances:
- All boosted tokens are transferred to the boosted_tokens_pool account via the Cosmos SDK’s Bank module.
- On undelegation, tokens are properly returned to delegators.

Acceptance Criteria

Boosted Delegations: Delegators can deposit additional tokens and have them reflected in higher potential rewards.
Minimal Impact on Existing Delegations: Regular staking remains unaffected; boosted delegation is purely additive.
Validator Constraints: Validators can enforce a minimum boost requirement, and can restrict who is allowed to boost.
Reward Calculation Updates: The distribution module correctly calculates rewards with a boostRatio multiplier, respecting the BoostPercentage parameter.
Secure Fund Handling: Tokens are transferred securely to the boosted_tokens_pool and only returned on undelegation.
Documentation & User Guide: Provide detailed instructions for validators and delegators on enabling, delegating, and withdrawing boosts.

Documentation

Developer References: Covers all new messages (DelegateBoost, UnDelegateBoost), relevant keeper methods, and store keys.
Validator Setup: Explains configuring min_delegation and delegate_authorization.
Reward Mechanics: Describes the boost ratio calculation, capped multiplier, and the distribution flow for boosted rewards.
Governance: Outlines how parameters like BoostPercentage may be updated through governance proposals.

By integrating Delegation Boost, Helios enhances the overall staking experience, introducing novel opportunities for delegators and validators alike to optimize their on-chain economic strategies while maintaining network security and stability.

HIP-3: Smart Contract Creator Incentives

Feature Overview

Introduce a protocol-level incentive mechanism that rewards smart contract creators with a configurable share of transaction fees when their contracts are executed during block processing. The system defaults to allocating 10% of the transaction fee to the creator, with governance-enabled control to modify or disable the distribution logic without affecting historical metadata or creator attribution.

Motivation

The success of Helios depends on the active participation of smart contract developers. Under the current fee structure, developers do not receive any share of the fees generated when their contracts are used — despite driving value and activity on the network. This HIP proposes a protocol-native way to compensate creators for their contributions in proportion to actual on-chain usage.

Such a system aligns economic incentives, promotes long-term developer commitment, and encourages the deployment of more robust and innovative smart contracts directly on Helios.

Objectives

Implement an automated, usage-based revenue-sharing mechanism for smart contract creators.
Allow governance to manage:
- The incentive percentage (default 10%).
- The on/off state of the feature.
Ensure toggling the system off does not erase on-chain tracking of creator metadata or usage history.
Promote sustainability and self-incentivized developer participation.

Key Features

Dynamic Fee Sharing: A fixed share of transaction fees is routed to the original deployer (creator) of a smart contract if it is invoked during execution.
Governance Parameter Control:
- enable_revenue (bool): Enables or disables fee routing.
- developer_shares (math.LegacyDec, e.g., 0.100000000000 = 10%): Defines fee share percentage in basis points.
Secure Attribution: Uses the original msg.sender during contract deployment to identify the creator.
Non-Destructive Disabling: When turned off, no further revenue is routed, but historical data and attribution remain intact for future potential reactivation.
Upgradeable Architecture: Easily extensible for future enhancements like usage-based weighting or team-level revenue sharing.

Technical Implementation

Execution Tracing: The block processing engine traces all contracts invoked in a transaction’s execution path.
Creator Lookup: The system maps each contract’s address to the original deployer address stored at deployment time.
Fee Redirection: Before burning or redistribution, 10% of the transaction fee is routed to the contract creator.
Governance Configuration:
- Incentive parameters are stored and updated through the parameter module.
- Governance proposals can update the parameters or disable the feature entirely.
Module Integration: Likely implemented as part of the fee handling logic or a new standalone incentives module.

Acceptance Criteria

Smart contract creators receive 10% of transaction fees by default when their contracts are executed.
Governance can modify the reward percentage (in basis points).
Governance can enable or disable the incentive logic.
Attribution mechanism reliably identifies creators of contracts deployed via CREATE and CREATE2.
Revenue routing occurs only when a contract is actively used in a transaction.
System emits types.EventTypeDistributeDevRevenue events with attributes including sender address, contract address, withdrawer address, and fee amount for transparency.
When disabled, metadata about contract creators is retained.
Thorough unit and integration testing validate the entire flow.
Full documentation describing incentive logic, governance control, edge cases, and integration best practices.

Documentation

Detailed developer documentation will be published under

Smart Contract Creator Incentives

and will include:
- Governance configuration guide.
- Developer expectations and earnings logic.
- Creator tracking methodology and known limitations.

HIP-4: External Data Call Support via Hyperions

Feature Overview

This HIP introduces the capability for smart contracts on the Helios blockchain to initiate and receive data from external blockchains, such as Ethereum, using the Hyperion module and relayer infrastructure. The new system enables secure, verifiable, and programmable cross-chain calls with callback support, forming the foundation for decentralized oracle operations and cross-chain composability.

Motivation

Helios aims to position itself as a highly interoperable blockchain platform. Enabling smart contracts to fetch and verify data from other blockchains significantly expands their utility and paves the way for cross-chain DeFi, external oracle integrations, and decentralized automation.

This proposal introduces a full lifecycle of external data requests, including:

A precompile interface callable from smart contracts
Transaction creation and management through the Hyperion module
Execution, validation, and attestation through orchestrators
Callback and refund mechanisms

Objectives

Allow smart contracts to request external blockchain calls with callback execution
Provide secure and auditable data fetching infrastructure with validator attestation
Support gas fees and refunds to incentivize fair relay and execution
Make the system configurable through governance for gas pricing and resource limits

Key Features

Precompile: `requestData`

A Solidity-accessible function defined at a fixed precompile address (e.g., 0x000...0900) exposes the requestData function:

function requestData(
    uint64 chainId,
    address contractAddress,
    bytes calldata abiCall,
    string calldata callbackSelector,
    uint256 maxGasPrice,
    uint256 gasLimit
) external payable returns (uint256 taskId);

This call:

Validates parameters and user balance
Reserves execution fee via SendCoinsFromAccountToModule
Schedules a Chronos job for callback
Constructs and stores an OutgoingExternalDataTx in the Hyperion module

External Call Lifecycle

Request Submitted: The smart contract calls requestData.
Cron Job Scheduled: Chronos schedules a callback to the contract.
Relayer Fetches: A registered Hyperion relayer fetches the external call data.
Validator Attestation: Validators vote on the result.
Threshold Reached: Upon reaching quorum, data is finalized and callback triggered.
Callback Execution: The smart contract’s callBack(bytes data, bytes err) function is invoked.
Reward Distribution: Orchestrators are rewarded from the initial fee.
Refund: Expired or invalid transactions are refunded.

Governance Parameters

MinCallExternalDataGas: Minimum required gas limit for a valid external data call
HyperionFeePercentage: Portion of fee to reward orchestrators
MaxCallbackDelay: Max block delay before automatic refund

Technical Implementation

New Module Code: external_data.go manages transaction creation, storage, refund, reward, and deletion.
EndBlock Hook: executeAllExternalDataTxs() is called to check for quorum and execute validated calls.
Relayer Integration: Added logic in Hyperion Program to fetch results and submit claims.
Chronos Integration: Callback logic with storage of result and error in CronCallBackData.
Contract Verification: Ensures ABI callback exists before transaction is accepted.

Acceptance Criteria

Smart contracts can successfully initiate and receive data from external blockchains via the precompile.
A quorum of validators finalizes the call after attesting to the result.
The requested callback is executed in Chronos only after validation.
Callback errors and results are correctly routed and stored.
Relayers are able to fetch and submit data in a timely and secure manner.
The system auto-refunds expired or invalid calls.

Example

A smart contract requests ETH/USD price data from Ethereum and updates its state:

function fetchETHPrice() external {
    address source = 0x...;
    bytes memory encodedData = abi.encodeWithSignature("last_price(uint256)", 0);
    string memory callback = "callBack";
    uint256 maxGasPrice = 10 gwei;
    uint256 gasLimit = 20_000_000 wei;

    uint256 taskId = HyperionRequestor.requestData(
        11155111, // Ethereum Sepolia
        source,
        encodedData,
        callback,
        maxGasPrice,
        gasLimit
    );
}

function callBack(bytes memory data, bytes memory err) public {
    require(err.length == 0);
    uint256 price = abi.decode(data, (uint256));
    updatePrice(price);
}

Documentation

Full documentation will be published under docs/ and include:

Precompile interface and ABI specs
Supported chain configurations
Chronos and Hyperion params
Relayer setup guide
Security model for quorum-based validation
Fee calculations and governance toggles

Governance Proposal

Title: Enable External Data Call Infrastructure Summary: Enable support for cross-chain external data calls with Hyperion module, relayer, and callback support. Initial Parameters:

MinCallExternalDataGas: 2,000,000
HyperionFeePercentage: 50%
MaxCallbackDelay: 100 blocks

Status

Draft

Authors

Helios Core Dev Team

HIP-4 lays the foundation for oracle operations and programmable cross-chain logic. By establishing a reliable, auditable, and contract-accessible interface for external data calls, Helios expands the scope of smart contracts to include real-world and interchain data in a decentralized manner.

Welcome to the Helios Network HIP Book

Approved

HIPs

HDs

Review

HD-1: Chronos Module & Precompile

Feature Overview

Implement a native cron scheduling module (Chronos) along with a dedicated EVM precompile, enabling developers to schedule and automate periodic tasks directly on-chain.

Motivation

Blockchain-based applications often require periodic execution of smart contract methods. Currently, developers depend on off-chain solutions, introducing complexity and reliability concerns. A native, blockchain-integrated cron service simplifies automation and enhances the robustness and efficiency of decentralized applications.

Objectives

Provide an intuitive, efficient, and secure way to schedule periodic smart contract interactions.
Reduce the reliance on external cron services or centralized schedulers.
Enhance developer experience through seamless integration with smart contracts.

Key Features

Native Integration: Directly integrated into Helios blockchain as a precompile.
Easy Scheduling: Simple API to schedule function calls with specified frequency, expiration, gas limits, and maximum gas price.
Reliability: Guaranteed execution or clear state indication of failed executions.
Security: Execution isolated within blockchain’s native security context.
Unique Cron Addresses: Each cron job has a unique blockchain address.
Gas Management: Upon cron creation, funds are deposited to cover gas consumption (100 gas per block to keep the cron active).
RPC Endpoints: Multiple RPC endpoints must be created to support cron interactions and management.
Cron Cancellation Conditions: Crons are automatically canceled when their balance reaches zero or an execution failure occurs. Remaining funds (if any) at cancellation are returned to the owner, and an event is emitted indicating cancellation.

Technical Implementation

Dedicated EVM-compatible precompile address: 0x0000000000000000000000000000000000000830.
ABI included for straightforward integration with front-end libraries such as Ethers.js and Web3.
Comprehensive unit and integration testing included.

Acceptance Criteria

Ability to schedule and reliably execute cron tasks.
Ability to update and cancel existing cron tasks.
Cron tasks have unique blockchain addresses.
Funds deposited at cron creation are properly managed and consumed at the rate of 100 gas per block.
Cron tasks are automatically canceled and cleaned up when balance reaches zero or upon execution failure.
Events (CronCreated, CronModified, CronCancelled) emitted accurately reflecting cron job lifecycle.
Respect of gas limits and consumption rules as defined.
Clear and complete developer documentation.

Documentation

Detailed developer documentation available under Chronos.

HD-2: Delegation Boost for Enhanced Staking

Feature Overview

Motivation

Objectives

Provide Flexible Staking Options: Enable a dedicated method to “boost” stake in addition to normal delegation, with potential for higher rewards.
Enforce Minimum Boost Requirements: Allow validators to specify a min_delegation as a threshold for boosted delegation.
Enable Enhanced Reward Calculations: Incorporate boosted delegations into reward distribution using a flexible multiplier defined by a network parameter (BoostPercentage).
Streamline Staking Flows: Maintain a clear distinction between regular staked tokens and boosted tokens, with dedicated messages for deposit and withdrawal.

Key Features

Boosted Pool Account
- A new module account (boosted_tokens_pool) holds tokens delegated as a boost.
- Ensures clear tracking and isolation of boosted tokens from regular staked tokens.
Boost Ratio & Rewards Multiplier
- The distribution module calculates a “boost ratio” for a validator by comparing its total boosted stake to its overall staked amount.
- A configurable BoostPercentage parameter governs how much of a multiplier this ratio adds to the rewards.
Validator-Based Settings
- min_delegation: A validator can specify the minimum boost required for delegators.
- delegate_authorization: Determines whether anyone other than the validator can add a boosted delegation.
New Message Types
- DelegateBoost(...): Delegates tokens to the boosted pool, tracked separately from normal staking.
- UnDelegateBoost(...): Withdraws boosted tokens, reducing the delegation’s effective multiplier.
Enhanced Store and Queries
- New keys and indexing in the staking keeper track total boosts for each validator and each (delegator, validator) pair.
- Functions like GetTotalBoostedDelegation and GetValidatorDelegationsBoost enable easier lookups of boosted stakes.
Genesis & Parameter Integration
- The chain’s genesis process now initializes the boosted_tokens_pool and parameters such as BoostPercentage.
- Operators can manage BoostPercentage, min_delegation, and delegate_authorization via governance or direct configuration.

Technical Implementation

Extended Staking Keeper Methods:
- DelegateBoost, UnDelegateBoost, SetDelegationBoost, and GetDelegationBoost orchestrate storing boosted tokens and updating delegated amounts.
- The keeper enforces min_delegation and delegate_authorization when delegations occur.
Modified Reward Distribution Logic:
- Updated distribution code fetches a validator’s boostedTotal tokens, calculates a boostRatio, and multiplies the base rewards by 1 + (BoostPercentage * boostRatio) (capped at a maximum of 1:1 ratio for the boost portion).
New Proto Definitions:
- MsgCreateValidator and MsgEditValidator now include min_delegation and delegate_authorization.
- Messages for delegating/undelegating boosts are defined and handle moving tokens to and from boosted_tokens_pool.
Module Accounts & Balances:
- All boosted tokens are transferred to the boosted_tokens_pool account via the Cosmos SDK’s Bank module.
- On undelegation, tokens are properly returned to delegators.

Acceptance Criteria

Boosted Delegations: Delegators can deposit additional tokens and have them reflected in higher potential rewards.
Minimal Impact on Existing Delegations: Regular staking remains unaffected; boosted delegation is purely additive.
Validator Constraints: Validators can enforce a minimum boost requirement, and can restrict who is allowed to boost.
Reward Calculation Updates: The distribution module correctly calculates rewards with a boostRatio multiplier, respecting the BoostPercentage parameter.
Secure Fund Handling: Tokens are transferred securely to the boosted_tokens_pool and only returned on undelegation.
Documentation & User Guide: Provide detailed instructions for validators and delegators on enabling, delegating, and withdrawing boosts.

Documentation

Developer References: Covers all new messages (DelegateBoost, UnDelegateBoost), relevant keeper methods, and store keys.
Validator Setup: Explains configuring min_delegation and delegate_authorization.
Reward Mechanics: Describes the boost ratio calculation, capped multiplier, and the distribution flow for boosted rewards.
Governance: Outlines how parameters like BoostPercentage may be updated through governance proposals.

HD-3: Smart Contract Creator Incentives

Feature Overview

Introduce a configurable fee-sharing mechanism that allocates a portion of transaction fees to smart contract creators whose contracts are actively used during block execution. By default, creators receive 10% of transaction fees, but this percentage can be adjusted via governance. The system can also be toggled on or off through governance without affecting the underlying metadata about contract usage.

Motivation

Smart contract developers are at the heart of innovation in decentralized ecosystems. Despite this, current gas fee structures (such as EIP-1559) offer no direct compensation to creators for the usage of their contracts. This discourages long-term protocol development and innovation.

The proposed incentive model creates a built-in, protocol-level mechanism to reward creators based on actual usage of their deployed contracts, fostering developer engagement, ecosystem health, and network utility.

Objectives

Provide a native, transparent way to reward smart contract creators for active on-chain usage.
Align developer incentives with protocol growth.
Reduce reliance on external funding, grants, or off-chain monetization.
Allow governance to manage:
- The incentive percentage.
- The enable/disable state of the distribution logic.
Ensure toggling the feature off preserves all historical creator and usage data for potential re-enablement.

Key Features

Usage-Based Rewards: Smart contracts involved in transaction execution result in a reward share to their original deployers.
Governance-Controlled Percentage: Default set to 10%, modifiable by governance through parameter updates.
Governance Toggle: Feature can be enabled or disabled at the protocol level without deleting creator records.
Non-Destructive Disablement: Turning off the incentive mechanism stops revenue distribution but retains all contract metadata.

Technical Implementation

Identification of smart contracts executed per transaction (via internal EVM call tracing).
Attribution of executed contracts to their original msg.sender at deployment (CREATE, CREATE2).
Post-processing logic to redirect a configurable portion of transaction fees to the creator address.
Parameter module integration for:
- enable_revenue (bool)
- developer_shares (in decimal basis points, e.g. 0.100000000000 for 10%)
Logic hook integrated at the fee accounting level (post-EVM execution, pre-burn).
Contracts with unknown or nonstandard deployment origins are excluded from attribution.

Acceptance Criteria

Contract creators receive 10% of fees by default for executed contracts.
Percentage is adjustable via governance.
Incentive feature can be toggled on/off via governance.
Creator attribution works reliably for standard contract deployments.
Non-destructive toggling preserves creator metadata.
No impact on contracts not used during transaction execution.
Events emitted when incentive payments are made (types.EventTypeDistributeDevRevenue ).
Unit tests covering key flows: execution tracking, attribution, payout, governance updates.
Integration tests simulating real-world transactions and fee splitting.
Complete developer documentation on deployment patterns, fee accounting, and governance control.

Documentation

Full developer documentation to be published under

Smart Contract Creator Incentives

with examples, API behavior, governance guide, and integration best practices.

HD-4: External Data Call Support via Hyperions

Feature Overview

Motivation

This proposal introduces a full lifecycle of external data requests, including:

A precompile interface callable from smart contracts
Transaction creation and management through the Hyperion module
Execution, validation, and attestation through orchestrators
Callback and refund mechanisms

Objectives

Allow smart contracts to request external blockchain calls with callback execution
Provide secure and auditable data fetching infrastructure with validator attestation
Support gas fees and refunds to incentivize fair relay and execution
Make the system configurable through governance for gas pricing and resource limits

Key Features

Precompile: `requestData`

A Solidity-accessible function defined at a fixed precompile address (e.g., 0x000...0900) exposes the requestData function:

function requestData(
    uint64 chainId,
    address contractAddress,
    bytes calldata abiCall,
    string calldata callbackSelector,
    uint256 maxGasPrice,
    uint256 gasLimit
) external payable returns (uint256 taskId);

This call:

Validates parameters and user balance
Reserves execution fee via SendCoinsFromAccountToModule
Schedules a Chronos job for callback
Constructs and stores an OutgoingExternalDataTx in the Hyperion module

External Call Lifecycle

Request Submitted: The smart contract calls requestData.
Cron Job Scheduled: Chronos schedules a callback to the contract.
Relayer Fetches: A registered Hyperion relayer fetches the external call data.
Validator Attestation: Validators vote on the result.
Threshold Reached: Upon reaching quorum, data is finalized and callback triggered.
Callback Execution: The smart contract’s callBack(bytes data, bytes err) function is invoked.
Reward Distribution: Orchestrators are rewarded from the initial fee.
Refund: Expired or invalid transactions are refunded.

Governance Parameters

MinCallExternalDataGas: Minimum required gas limit for a valid external data call
HyperionFeePercentage: Portion of fee to reward orchestrators
MaxCallbackDelay: Max block delay before automatic refund

Technical Implementation

New Module Code: external_data.go manages transaction creation, storage, refund, reward, and deletion.
EndBlock Hook: executeAllExternalDataTxs() is called to check for quorum and execute validated calls.
Relayer Integration: Added logic in Hyperion Program to fetch results and submit claims.
Chronos Integration: Callback logic with storage of result and error in CronCallBackData.
Contract Verification: Ensures ABI callback exists before transaction is accepted.

Acceptance Criteria

Smart contracts can successfully initiate and receive data from external blockchains via the precompile.
A quorum of validators finalizes the call after attesting to the result.
The requested callback is executed in Chronos only after validation.
Callback errors and results are correctly routed and stored.
Relayers are able to fetch and submit data in a timely and secure manner.
The system auto-refunds expired or invalid calls.

Example

A smart contract requests ETH/USD price data from Ethereum and updates its state:

function fetchETHPrice() external {
    address source = 0x...;
    bytes memory encodedData = abi.encodeWithSignature("last_price(uint256)", 0);
    string memory callback = "callBack";
    uint256 maxGasPrice = 10 gwei;
    uint256 gasLimit = 20_000_000 wei;

    uint256 taskId = HyperionRequestor.requestData(
        11155111, // Ethereum Sepolia
        source,
        encodedData,
        callback,
        maxGasPrice,
        gasLimit
    );
}

function callBack(bytes memory data, bytes memory err) public {
    require(err.length == 0);
    uint256 price = abi.decode(data, (uint256));
    updatePrice(price);
}

Documentation

Full documentation will be published under docs/ and include:

Precompile interface and ABI specs
Supported chain configurations
Chronos and Hyperion params
Relayer setup guide
Security model for quorum-based validation
Fee calculations and governance toggles

Governance Proposal

Title: Enable External Data Call Infrastructure Summary: Enable support for cross-chain external data calls with Hyperion module, relayer, and callback support. Initial Parameters:

MinCallExternalDataGas: 2,000,000
HyperionFeePercentage: 50%
MaxCallbackDelay: 100 blocks

Status

Draft

Authors

Helios Core Dev Team

Welcome to the Helios Network HIP Book