# Introduction to Kinetiq Kinetiq is a liquid staking protocol built natively on Hyperliquid, enabling users to stake the native token of the Hyperliquid blockchain (HYPE) and receive Kinetiq Staked HYPE (kHYPE) in return. kHYPE enables staking participation while retaining full liquidity and capital efficiency — earning staking rewards while staying active across DeFi. Behind the scenes, all staked HYPE is automatically delegated to the top-performing Hyperliquid validators, selected by [StakeHub](/docs/stakehub)— Kinetiq’s autonomous validator scoring and delegation system. This means: - Your HYPE contributes to network security and decentralization - You earn rewards passively, without manual validator selection - Your kHYPE balance accrues value automatically — no claiming or rebasing needed - kHYPE is usable across the Hyperliquid ecosystem, giving you the best of both worlds: native staking yield and DeFi utility ## Why Kinetiq matters to Hyperliquid ### Strengthening network security Every HYPE staked through Kinetiq directly contributes to Hyperliquid’s security and decentralization: - Stronger economic security for the entire network - Better resistance to attacks and manipulation - More robust consensus and faster finality ### Solving liquid staking complexity Traditional staking requires: - Researching and choosing validators manually - Monitoring performance continuously - Managing rewards and rebalancing - Accepting locked tokens with no DeFi utility Kinetiq eliminates all these pain points while maximizing your returns. ### Accelerating DeFi growth kHYPE enables immediate DeFi participation: - Use as collateral for lending/borrowing - Provide liquidity in AMM pools - Participate in yield strategies - Trade positions while maintaining staking exposure ## How Kinetiq works 1. You [stake HYPE](/stake-hype) for kHYPE. 2. Kinetiq selects top-performing validators, continuously monitors performances, and rebalances. 3. Your kHYPE grows in value as validator rewards flow to all kHYPE holders causing the exchange rate to improve over time. No claiming or manual actions needed as rewards compound automatically. 4. Use kHYPE anywhere. Some examples: trade on DEXs, use as collateral for loans, provide liquidity for extra yield, keep earning staking rewards throughout, trade yield of kHYPE. 5. Withdraw at any time by queuing a withdrawal request and waiting for the security delay period. ## Kinetiq’s key innovations ### Autonomous validator management Automated validator selection and management system: - Algorithmic selection: Evaluates validator performance metrics - Continuous monitoring: Tracks and optimizes validator activity - Automatic rebalancing: Adjusts delegations without user input - Risk diversification: Delegation across multiple validators ### Native L1 integration Tight integration with Hyperliquid’s infrastructure: - Direct validator communication - Batch operations for efficiency - State synchronization - Leverages Hyperliquid’s base security ### Security architecture Kinetiq is built with a multi-layered approach to protocol safety: - Emergency response system - Role-based access controls & multi-sig - 4 independent security audits - Secure upgrade frameworks ## Navigate your Kinetiq journey Choose your path: New to liquid staking? - [Liquid staking primer](/docs/liquid-staking-primer) - [Getting started with kHYPE](/docs/getting-started-with-khype) Want to earn more? - [Earn](/docs/earn) - [StakeHub](/docs/stakehub) Curious about technicals? - [Contracts & audits](/docs/contracts-and-audits) Have questions? - [FAQ](/docs/faq) --- # Liquid staking primer Why liquid staking your HYPE with Kinetiq unlocks maximum yield and flexibility ## The importance of staking Staking is the core of Delegated Proof of Stake (DPoS) ecosystems like Hyperliquid. 1. **Security.** Staking enhances the security of the network by requiring participants (validators) to lock up a certain amount of tokens. This stake serves as a financial incentive for validators to act honestly, as malicious behavior could lead to the loss of their staked funds. 2. **Decentralization.** By allowing more participants to validate transactions, staking promotes decentralization. Unlike Proof of Work (PoW) systems that rely on expensive, energy-intensive hardware, PoS enables individuals with varying amounts of tokens to participate, widening access and reducing central control. 3. **Aligned incentives.** Staking aligns the interests of validators with the success of the network. As stakeholders, they are incentivized to maintain the network’s health, stability, and relevance, as their rewards and potentially the value of their holdings depend on the network’s success. ## What is liquid staking? ### The traditional staking problem Standard staking requires: - Locking tokens for long durations - Manually selecting and monitoring validators - Giving up liquidity and DeFi access - Navigating complex delegation mechanics The result? Many users skip staking and miss out on yield and contributing to network security. ### Liquid staking solution Liquid staking protocols like Kinetiq solve these issues by: - Giving you immediate liquidity via tradeable tokens (kHYPE) - Automating validator selection and rebalancing - Enabling full DeFi utility while earning rewards - Simplifying the staking experience end-to-end ## How liquid staking works ### The liquid staking process With Kinetiq, you can stake HYPE and receive kHYPE — a token that represents your staked position while staying liquid and usable across Hyperliquid DeFi. ### Summary of steps 1. You [stake HYPE](/stake-hype) for kHYPE. 2. Kinetiq selects top-performing validators, continuously monitors performances, and rebalances. 3. Your kHYPE grows in value as validator rewards flow to all kHYPE holders causing the exchange rate to improve over time. No claiming or manual actions needed as rewards compound automatically. 4. Use kHYPE anywhere. Some examples: trade on DEXs, use as collateral for loans, provide liquidity for extra yield, keep earning staking rewards throughout, trade yield of kHYPE. 5. Withdraw at any time by queuing a withdrawal request and waiting for the security delay period. ## Kinetiq (liquid staking) vs. alternatives ### Direct staking vs. Kinetiq (liquid staking) | Feature | Direct staking | Liquid staking with Kinetiq | | --- | --- | --- | | Liquidity | ❌ Locked | ✅ Fully liquid with kHYPE | | Validator management | ❌ Manual | ✅ Automated via StakeHub | | DeFi utility | ❌ None | ✅ Collateral, LP, trading | | Complexity | ❌ Requires research | ✅ One-click experience | | Rewards | ✅ Native | ✅ Native + DeFi | ### Centralized staking vs. Kinetiq (liquid staking) | Feature | Centralized services | Kinetiq (liquid staking) | | --- | --- | --- | | Custody | ❌ Platform controls funds | ✅ User-controlled | | Transparency | ❌ Limited | ✅ Fully on-chain | | Withdrawal policy | ❌ Platform-controlled | ✅ Protocol-defined | | DeFi integration | ❌ Rare or restricted | ✅ Full composability | | Risk | ❌ Regulatory & custodial | ✅ Smart contract managed | ## Who benefits most from liquid staking? ### New users - Onboard easily without complex delegation - Maintain full access to your capital ### DeFi users - Use kHYPE in lending, LPs, margin positions - Dual yield potential ### Institutions - Scalable liquid staking positions - Transparent validator performance - Self-custody friendly ### Active traders - Trade or hedge staking exposure - Arbitrage between kHYPE and HYPE ## Considerations & risks ### Smart contract risk - Code risk is minimized through audits, but never zero ### Validator risk - Validators can underperform or be slashed - StakeHub’s algorithm reduces this via diversification ### Liquidity risk - Market depth can vary for kHYPE - Price deviations may occur during volatility ### Protocol risk - Governance changes may affect functionality - Regulatory landscape still evolving ### Best practices - Start small to learn the flow - Monitor rewards and token price - Read [our audits](/docs/contracts-and-audits), check validator stats on [StakeHub](/docs/stakehub) *This section is a primer on liquid staking in general and its implementation via Kinetiq. For full protocol documentation, please continue through the docs.* --- # Kinetiq Staked HYPE (kHYPE) How to stake, unstake, and trade kHYPE. ## How to stake HYPE for kHYPE 1. Open the [Kinetiq stake page](/stake-hype) 2. Connect your wallet 3. Enter staking amount 4. Click `Stake` button 5. Confirm transaction 6. Receive kHYPE Once complete, you accrue rewards automatically and your kHYPE will be ready to use across HyperEVM DeFi. There is a 10% fee on staking rewards, of which 70% is used to purchase KNTQ on the open market and 30% is sent to the Kinetiq treasury for operations. ### Transferring HYPE to HyperEVM If your HYPE is on HyperCore: 1. Visit the Hyperliquid dApp → “Portfolio” tab 2. Locate your HYPE balance 3. Click “Transfer to EVM” under the “Transfer” column 4. Wait for confirmation (usually seconds) Once on HyperEVM, you can stake via Kinetiq. ### Cross-chain swaps from Ethereum or Base to kHYPE on HyperEVM Have ETH or USDC on Ethereum or Base? You can swap *directly* to kHYPE on HyperEVM with added functionality—powered by Enso. 1. Connect your wallet on Ethereum or Base to the Kinetiq dApp 2. Enter the amount of ETH or USDC you’d like to swap 3. Confirm the transaction and wait for completion Once complete, you accrue rewards automatically and your kHYPE will be ready to use across HyperEVM DeFi. ## How to unstake kHYPE for HYPE Unstaking kHYPE returns the original HYPE after a delay period — same process as native Hyperliquid unstaking. 1. **Queue unstake.** Choose amount of kHYPE to convert back to HYPE, submit withdrawal request, and receive withdrawal ID 2. **Wait for the delay period.** ~8–9 days total: includes 1-day delegation lockup + 7-day unstaking queue 3. **Confirm Withdrawal.** After delay, kHYPE is burned and your HYPE is returned to your wallet ## Trading in and out of kHYPE Want to exit before the unstaking period ends? You can trade kHYPE on supported platforms offering deep liquidity: - [Kinetiq stake page](/stake) (unstake button) - DEXs - Orderbooks and AMMs > Note: Swapping may incur slippage depending on venue and market conditions, but offers instant liquidity. ## Add kHYPE to your wallet Token address: `0xfD739d4e423301CE9385c1fb8850539D657C296D` ([HyperEVMScan](https://hyperevmscan.io/token/0xfd739d4e423301ce9385c1fb8850539d657c296d)) To add it manually: - Go to your Wallet Provider → “Import Tokens” - Paste the address above - Confirm import --- # Validator distribution Our liquid staking token, kHYPE, is built to make staking safer, more efficient, and more decentralized — both for users and for the network. View [live validator data](/validators) ## Why validators matters Staking should be simple and smart. With kHYPE: - Collect all staking rewards passively - Your stake is spread across the best validators - No manual validator selection required + continuous optimization of delegation - Everything happens automatically — no action needed from you - And it’s all transparent and on-chain > kHYPE turns staking into a passive, professional-grade experience — with no extra work required from users. ## How it works Our tools watch how validators perform in real-time. They rank each validator based on how well they’re performing. This rank directly affects how we delegate stake. We rebalance automatically, so stake is always going to the top-performing validators — not just once, but continuously. This means: - You don’t need to pick validators manually - Your stake avoids underperforming or risky validators - Your staked is only directed to the best performing validators ## How we choose validators **Validators are ranked using five key categories:** - Reliability – Are they online, responsive, and consistently producing blocks? - Security – Have they been slashed? Are their systems safe and well-managed - Economics – Do they offer fair fees and stable rewards? - Governance – Do they vote on proposals and stay active in the network? - Longevity – How long have they been active, and do they keep their software up to date? We combine all of this into one score to get a full picture of how trustworthy and useful each validator is. ## Smart rebalancing system Validator performance evolves. kHYPE ensures your stake does too. ### Performance monitoring - 24/7 scoring updates - Detection of underperformance or slashing - Automated alerts and score adjustments ### Delegation adjustments - Gradual reallocation to top-performing validators - Removal of degraded validators - Addition of new, high-potential entrants ### Rebalancing frequency - Triggered by significant score changes - Emergency rebalancing for critical validator failure - Designed to minimize disruption while optimizing yield and safety ### Risk controls - Stake never over-concentrated - Geographic and operator diversity enforced - Prioritization of decentralization alongside performance ## Built for a growing ecosystem Hyperliquid is still early — the validator set, network activity, and available data are evolving fast. Because of that, the way we score and delegate will also evolve over time. kHYPE is built to grow with the network. We’re actively working with other teams and validators across the ecosystem to improve the dataset, add more context, and keep our system fully up to date. As Hyperliquid matures, so will our validator insights — making kHYPE even smarter, safer, and more accurate over time. ## Autonomous management benefits ### Algorithmic oversight - Quantitative validator selection - No human bias or subjective decision-making - Score-based rebalancing built on verifiable data ### Operational simplicity - No need to research validators - No delegation maintenance required - Hands-off staking with optimized outcomes ### Performance optimization - Delegated only to validators scoring above threshold - Reduced yield leakage from poor validator performance ### Risk mitigation - Stake diversified across multiple validators - Avoids exposure to slashed or inactive validators - Responds to validator issues in real time ## Transparency and verifiability ### Open architecture - All validator scores are published on-chain - Delegation decisions are auditable - Selection logic and scoring weights are documented ### For builders - Your own staking interface - New liquid staking tokens - Validator dashboards or analytics tools ### No black boxes - No manual overrides - No opaque criteria - No hidden fees or redirect incentives ## Current portfolio View [live validator data](/validators) Includes: - Active validators - Delegation percentages - Performance snapshots (uptime, commission, slashing) - Recent rebalancing events and reasons --- # Markets by Kinetiq (kmHYPE) How kmHYPE works, including deposits, withdrawals, and the withdrawal queue. ## What is kmHYPE? kmHYPE is a reward-accruing liquid staking token (LST) that represents HYPE staked to support Markets via [HIP-3: Builder-deployed perpetuals](https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals). Similar to kHYPE, the number of tokens in your wallet remains constant while the value of each kmHYPE increases as deployer revenue is realized. Rewards accumulate and the value of each kmHYPE token increases, which means the kmHYPE:HYPE exchange rate also increases. The longer you hold kmHYPE, the more rewards you accrue and the larger the difference in the exchange rate becomes. ## How withdrawals work There are two ways to withdraw your deposit: ### Direct withdrawals from contract If the current HYPE underlying kmHYPE exceeds the minimum amount of 500,000 HYPE, withdrawals will be processed immediately with an approximately 8.5‑day withdrawal period and a 0.10% withdrawal fee (paid in kmHYPE). If there is no excess HYPE, new withdrawals enter a queue and are processed as soon as more HYPE becomes available. ### Swapping instantly on a supported kmHYPE market You can also swap kmHYPE instantly on supported markets for immediate liquidity, though this may incur slippage depending on venue and market conditions. ## Withdrawal queue The withdrawal queue is a mechanism that ensures withdrawals can be processed even when there isn’t enough excess HYPE available for immediate processing. - **When withdrawals queue**: If the current HYPE underlying kmHYPE does not exceed the minimum amount of 500,000 HYPE, new withdrawal requests enter a queue. - **When withdrawals process immediately**: If there is excess HYPE above the 500,000 HYPE minimum, withdrawals begin immediately with the standard ~8.5-day withdrawal period. - **Queue processing**: Queued withdrawals are processed as soon as more HYPE becomes available (for example, from new deposits or when other withdrawals complete). This ensures that all withdrawal requests are eventually processed, even during periods of high withdrawal demand. ## Add kmHYPE to your wallet Token address: `0x360C140E5344A1A0593D44B4ea6Fc7C3DAf0C473` ([HyperEVMScan](https://hyperevmscan.io/token/0x360c140e5344a1a0593d44b4ea6fc7c3daf0c473)) To add it manually: - Go to your Wallet Provider → "Import Tokens" - Paste the address above - Confirm import For contract addresses, please see the [Contracts and audits](/docs/contracts-and-audits) page. --- # Institutional staking (iHYPE) ## What is iHYPE? iHYPE (“Kinetiq-staked HYPE for Institutions”) is Kinetiq’s institution-only liquid staking pool for HYPE, purpose-built for KYB/KYC-compliant entities. It delivers the same yield-earning benefits as kHYPE but with added controls, privacy, and infrastructure tailored to institutional needs. ## Key features - Private, risk-isolated pool – iHYPE operates separately from public staking pools, ensuring dedicated validator delegation and isolation from retail flows. - Custom validator control – Institutions can designate their own validator(s) for enhanced governance, compliance, or performance preferences. - Custom LST tickers – Deploy under your own branded ticker (e.g., imHYPE) while retaining all core staking benefits. - Regulated infrastructure – Built on enterprise-grade staking rails with operational standards to meet institutional compliance requirements. ## How it works 1. Deposit HYPE into the iHYPE contract (requires institutional onboarding). 2. Receive your institution’s branded LST (Liquid Staking Token). 3. Earn staking yield automatically—redeemable for HYPE at the current exchange rate. ## What institutions are currently using iHYPE? The first institution to stake through iHYPE is Hyperion DeFi, Inc., a U.S. NASDAQ-publicly listed company building a long-term strategic treasury of HYPE. Hyperion DeFi stakes directly via Kinetiq’s compliant liquid staking infrastructure, operating under a dedicated validator and custom ticker. Their adoption of iHYPE sets a precedent for how regulated entities can securely and transparently participate in the Hyperliquid ecosystem, benefiting from staking yields while maintaining full compliance, all via Kinetiq. ## Interested in using iHYPE? Contact us at [contact@kinetiq.xyz](mailto:contact@kinetiq.xyz) to learn more. --- # Integration guide This guide provides practical examples for integrating with the Kinetiq liquid staking protocol using both Solidity smart contracts and TypeScript with Viem. ## Solidity integration ### Interfaces You may download the solidity interfaces here: [contract-interfaces/khype.zip](https://kinetiq.xyz/assets/share/contract-interfaces/khype.zip). Save them to the `interfaces` folder. ```solidity import "./interfaces/IStakingManager.sol"; import "./interfaces/IKHYPE.sol"; import "./interfaces/IStakingAccountant.sol"; ``` ### Contract addresses (Hyperliquid Mainnet) ```solidity address constant STAKING_MANAGER = 0x393D0B87Ed38fc779FD9611144aE649BA6082109; address constant KHYPE_TOKEN = 0xfD739d4e423301CE9385c1fb8850539D657C296D; address constant STAKING_ACCOUNTANT = 0x9209648Ec9D448EF57116B73A2f081835643dc7A; address constant VALIDATOR_MANAGER = 0x4b797A93DfC3D18Cf98B7322a2b142FA8007508f; ``` ### Deposits (staking) #### Basic deposit example ```solidity pragma solidity ^0.8.20; import "./interfaces/IStakingManager.sol"; import "./interfaces/IKHYPE.sol"; contract KinetiqDepositor { IStakingManager public immutable stakingManager; IKHYPE public immutable kHYPE; event StakeCompleted( address indexed user, uint256 hypeAmount, uint256 kHYPEReceived ); constructor(address _stakingManager, address _kHYPE) { stakingManager = IStakingManager(_stakingManager); kHYPE = IKHYPE(_kHYPE); } /** * @notice Stake HYPE tokens and receive kHYPE * @dev Sends native HYPE tokens to the staking manager */ function stakeHYPE() external payable { require(msg.value > 0, "Must send HYPE to stake"); // Get user's kHYPE balance before staking uint256 kHYPEBefore = kHYPE.balanceOf(msg.sender); // Stake HYPE tokens (msg.value is automatically sent) stakingManager.stake{value: msg.value}(); // Get user's kHYPE balance after staking uint256 kHYPEAfter = kHYPE.balanceOf(msg.sender); emit StakeCompleted(msg.sender, msg.value, kHYPEAfter - kHYPEBefore); } } ``` #### Deposit with validation ```solidity contract AdvancedKinetiqDepositor { IStakingManager public immutable stakingManager; IKHYPE public immutable kHYPE; IStakingAccountant public immutable stakingAccountant; event ValidatedStakeCompleted( address indexed user, uint256 hypeAmount, uint256 kHYPEReceived, uint256 expectedKHYPE ); constructor( address _stakingManager, address _kHYPE, address _stakingAccountant ) { stakingManager = IStakingManager(_stakingManager); kHYPE = IKHYPE(_kHYPE); stakingAccountant = IStakingAccountant(_stakingAccountant); } /** * @notice Stake HYPE with validation and expected return calculation * @param minKHYPEExpected Minimum kHYPE tokens expected to receive */ function stakeWithValidation(uint256 minKHYPEExpected) external payable { require(msg.value > 0, "Must send HYPE to stake"); // Check protocol limits require(msg.value >= stakingManager.minStakeAmount(), "Below minimum stake"); require(msg.value <= stakingManager.maxStakeAmount(), "Above maximum stake"); // Calculate expected kHYPE amount uint256 expectedKHYPE = stakingAccountant.HYPEToKHYPE(msg.value); require(expectedKHYPE >= minKHYPEExpected, "Expected kHYPE too low"); // Check if staking would exceed limit uint256 currentTotal = stakingManager.totalStaked(); uint256 stakingLimit = stakingManager.stakingLimit(); require(currentTotal + msg.value <= stakingLimit, "Would exceed staking limit"); uint256 kHYPEBefore = kHYPE.balanceOf(msg.sender); // Execute stake stakingManager.stake{value: msg.value}(); uint256 kHYPEReceived = kHYPE.balanceOf(msg.sender) - kHYPEBefore; require(kHYPEReceived >= minKHYPEExpected, "Insufficient kHYPE received"); emit ValidatedStakeCompleted( msg.sender, msg.value, kHYPEReceived, expectedKHYPE ); } } ``` ### Withdrawals (unstaking) #### Basic withdrawal flow ```solidity contract KinetiqWithdrawer { IStakingManager public immutable stakingManager; IKHYPE public immutable kHYPE; // Track user withdrawal requests mapping(address => uint256[]) public userWithdrawalIds; event WithdrawalQueued( address indexed user, uint256 indexed withdrawalId, uint256 kHYPEAmount ); event WithdrawalConfirmed( address indexed user, uint256 indexed withdrawalId, uint256 hypeReceived ); constructor(address _stakingManager, address _kHYPE) { stakingManager = IStakingManager(_stakingManager); kHYPE = IKHYPE(_kHYPE); } /** * @notice Queue a withdrawal request * @param kHYPEAmount Amount of kHYPE tokens to withdraw */ function queueWithdrawal(uint256 kHYPEAmount) external { require(kHYPEAmount > 0, "Amount must be positive"); require( kHYPE.balanceOf(msg.sender) >= kHYPEAmount, "Insufficient kHYPE balance" ); // Get next withdrawal ID for user uint256 withdrawalId = stakingManager.nextWithdrawalId(msg.sender); // Queue the withdrawal (this will burn kHYPE tokens) stakingManager.queueWithdrawal(kHYPEAmount); // Track withdrawal ID for user userWithdrawalIds[msg.sender].push(withdrawalId); emit WithdrawalQueued(msg.sender, withdrawalId, kHYPEAmount); } /** * @notice Confirm a withdrawal request after delay period * @param withdrawalId ID of the withdrawal request */ function confirmWithdrawal(uint256 withdrawalId) external { // Get withdrawal request details IStakingManager.WithdrawalRequest memory request = stakingManager.withdrawalRequests(msg.sender, withdrawalId); require(request.timestamp > 0, "Withdrawal request not found"); require( block.timestamp >= request.timestamp + stakingManager.withdrawalDelay(), "Withdrawal delay not met" ); uint256 balanceBefore = address(msg.sender).balance; // Confirm withdrawal (this will send HYPE to user) stakingManager.confirmWithdrawal(withdrawalId); uint256 hypeReceived = address(msg.sender).balance - balanceBefore; emit WithdrawalConfirmed(msg.sender, withdrawalId, hypeReceived); } /** * @notice Get all withdrawal IDs for a user * @param user User address * @return Array of withdrawal IDs */ function getUserWithdrawalIds(address user) external view returns (uint256[] memory) { return userWithdrawalIds[user]; } } ``` #### Batched withdrawals ```solidity contract BatchKinetiqWithdrawer { IStakingManager public immutable stakingManager; IKHYPE public immutable kHYPE; IStakingAccountant public immutable stakingAccountant; event BatchWithdrawalQueued( address indexed user, uint256[] withdrawalIds, uint256[] kHYPEAmounts ); event BatchWithdrawalConfirmed( address indexed user, uint256[] withdrawalIds, uint256 totalHypeReceived ); constructor( address _stakingManager, address _kHYPE, address _stakingAccountant ) { stakingManager = IStakingManager(_stakingManager); kHYPE = IKHYPE(_kHYPE); stakingAccountant = IStakingAccountant(_stakingAccountant); } /** * @notice Queue multiple withdrawal requests in a single transaction * @param kHYPEAmounts Array of kHYPE amounts to withdraw */ function batchQueueWithdrawals(uint256[] calldata kHYPEAmounts) external { require(kHYPEAmounts.length > 0, "No amounts provided"); uint256 totalKHYPE = 0; for (uint256 i = 0; i < kHYPEAmounts.length; i++) { require(kHYPEAmounts[i] > 0, "Amount must be positive"); totalKHYPE += kHYPEAmounts[i]; } require( kHYPE.balanceOf(msg.sender) >= totalKHYPE, "Insufficient kHYPE balance" ); uint256[] memory withdrawalIds = new uint256[](kHYPEAmounts.length); for (uint256 i = 0; i < kHYPEAmounts.length; i++) { withdrawalIds[i] = stakingManager.nextWithdrawalId(msg.sender); stakingManager.queueWithdrawal(kHYPEAmounts[i]); } emit BatchWithdrawalQueued(msg.sender, withdrawalIds, kHYPEAmounts); } /** * @notice Confirm multiple withdrawal requests * @param withdrawalIds Array of withdrawal IDs to confirm */ function batchConfirmWithdrawals(uint256[] calldata withdrawalIds) external { require(withdrawalIds.length > 0, "No withdrawal IDs provided"); uint256 totalHypeReceived = 0; uint256 balanceBefore = address(msg.sender).balance; for (uint256 i = 0; i < withdrawalIds.length; i++) { // Verify withdrawal is ready IStakingManager.WithdrawalRequest memory request = stakingManager.withdrawalRequests(msg.sender, withdrawalIds[i]); require(request.timestamp > 0, "Withdrawal request not found"); require( block.timestamp >= request.timestamp+ stakingManager.withdrawalDelay(), "Withdrawal delay not met" ); stakingManager.confirmWithdrawal(withdrawalIds[i]); } totalHypeReceived = address(msg.sender).balance - balanceBefore; emit BatchWithdrawalConfirmed(msg.sender, withdrawalIds, totalHypeReceived); } } ``` ### Complete Solidity integration example ```solidity pragma solidity ^0.8.20; /** * @title KinetiqIntegration * @notice Complete integration example for Kinetiq protocol */ contract KinetiqIntegration { IStakingManager public immutable stakingManager; IKHYPE public immutable kHYPE; IStakingAccountant public immutable stakingAccountant; constructor( address _stakingManager, address _kHYPE, address _stakingAccountant ) { stakingManager = IStakingManager(_stakingManager); kHYPE = IKHYPE(_kHYPE); stakingAccountant = IStakingAccountant(_stakingAccountant); } /** * @notice Get current exchange rate from HYPE to kHYPE * @param hypeAmount Amount of HYPE tokens * @return kHYPE amount that would be received */ function getKHYPEForHYPE(uint256 hypeAmount) external view returns (uint256) { return stakingAccountant.HYPEToKHYPE(hypeAmount); } /** * @notice Get current exchange rate from kHYPE to HYPE * @param kHYPEAmount Amount of kHYPE tokens * @return HYPE amount that would be received (before fees) */ function getHYPEForKHYPE(uint256 kHYPEAmount) external view returns (uint256) { return stakingAccountant.kHYPEToHYPE(kHYPEAmount); } /** * @notice Calculate withdrawal fee for unstaking * @param kHYPEAmount Amount of kHYPE to unstake * @return fee amount in kHYPE tokens */ function calculateWithdrawalFee(uint256 kHYPEAmount) external view returns (uint256) { // calculate withdrawal fee uint256 feeRate = stakingManager.unstakeFeeRate(); return (kHYPEAmount * feeRate) / 10000; // feeRate is in basis points } /** * @notice Check if withdrawal request is ready to confirm * @param user User address * @param withdrawalId Withdrawal request ID * @return isReady True if withdrawal can be confirmed * @return timeRemaining Seconds remaining until confirmation is available */ function isWithdrawalReady(address user, uint256 withdrawalId) external view returns (bool isReady, uint256 timeRemaining) { IStakingManager.WithdrawalRequest memory request = stakingManager.withdrawalRequests(user, withdrawalId); if (request.timestamp == 0) { return (false, 0); } uint256 confirmTime = request.timestamp + stakingManager.withdrawalDelay(); if (block.timestamp >= confirmTime) { return (true, 0); } else { return (false, confirmTime - block.timestamp); } } /** * @notice Get protocol status and limits * @return minStake Minimum stake amount * @return maxStake Maximum stake amount * @return stakingLimit Total staking limit * @return totalStaked Current total staked * @return withdrawalDelay Withdrawal delay in seconds * @return unstakeFeeRate Unstaking fee rate in basis points */ function getProtocolInfo() external view returns ( uint256 minStake, uint256 maxStake, uint256 stakingLimit, uint256 totalStaked, uint256 withdrawalDelay, uint256 unstakeFeeRate ) { return ( stakingManager.minStakeAmount(), stakingManager.maxStakeAmount(), stakingManager.stakingLimit(), stakingManager.totalStaked(), stakingManager.withdrawalDelay(), stakingManager.unstakeFeeRate() ); } } ``` ### Error handling and solutions #### Common errors and solutions ```solidity contract KinetiqErrorHandler { IStakingManager public immutable stakingManager; IKHYPE public immutable kHYPE; event StakeSuccessful(address indexed user, uint256 amount); event StakeFailed(address indexed user, uint256 amount, string reason); event WithdrawalQueuedSuccessful(address indexed user, uint256 amount); event WithdrawalQueuedFailed( address indexed user, uint256 amount, string reason ); /** * @notice Safe staking with comprehensive error handling */ function safeStake() external payable { // Check basic requirements require(msg.value > 0, "KinetiqErrorHandler: No HYPE sent"); // Check protocol limits uint256 minStake = stakingManager.minStakeAmount(); require( msg.value >= minStake, "KinetiqErrorHandler: Below minimum stake" ); uint256 maxStake = stakingManager.maxStakeAmount(); require( msg.value <= maxStake, "KinetiqErrorHandler: Above maximum stake" ); // Check staking limit uint256 totalStaked = stakingManager.totalStaked(); uint256 stakingLimit = stakingManager.stakingLimit(); require( totalStaked + msg.value <= stakingLimit, "KinetiqErrorHandler: Would exceed staking limit" ); // Check if user is whitelisted (if whitelist is enabled) if (stakingManager.whitelistLength() > 0) { require( stakingManager.isWhitelisted(msg.sender), "KinetiqErrorHandler: Not whitelisted" ); } try stakingManager.stake{value: msg.value}() { emit StakeSuccessful(msg.sender, msg.value); } catch Error(string memory reason) { emit StakeFailed(msg.sender, msg.value, reason); // Return HYPE to user payable(msg.sender).transfer(msg.value); } catch { emit StakeFailed(msg.sender, msg.value, "Unknown error"); // Return HYPE to user payable(msg.sender).transfer(msg.value); } } /** * @notice Safe withdrawal queue with error handling */ function safeQueueWithdrawal(uint256 kHYPEAmount) external { require(kHYPEAmount > 0, "KinetiqErrorHandler: Invalid amount"); require( kHYPE.balanceOf(msg.sender) >= kHYPEAmount, "KinetiqErrorHandler: Insufficient kHYPE balance" ); try stakingManager.queueWithdrawal(kHYPEAmount) { emit WithdrawalQueuedSuccessful(msg.sender, kHYPEAmount); } catch Error(string memory reason) { emit WithdrawalQueuedFailed(msg.sender, kHYPEAmount, reason); } catch { emit WithdrawalQueuedFailed( msg.sender, kHYPEAmount, "Unknown error" ); } } } ``` ### Integration best practices 1. **Always check protocol limits** before staking 2. **Calculate expected returns** and set minimum slippage protection 3. **Handle errors gracefully** with try-catch blocks 4. **Verify withdrawal readiness** before attempting confirmation 5. **Track withdrawal IDs** for users in your contract 6. **Consider gas optimization** for batch operations 7. **Monitor protocol events** for state changes 8. **Test thoroughly** on testnet before mainnet deployment ### Gas optimization tips - Batch multiple operations when possible - Cache frequently accessed values - Use `view` functions to estimate gas before transactions - Consider using multicall patterns for complex operations --- ## TypeScript integration This section provides examples for integrating with Kinetiq protocol using TypeScript and Viem for frontend applications. ### Setup and dependencies ```abap npm install viem wagmi # or yarn add viem wagmi # or pnpm i viem wagmi ``` ### Contract configuration ```typescript import { createPublicClient, createWalletClient, formatEther, http, parseEther, } from 'viem' import { hyperEvm } from 'viem/chains' // Contract addresses export const CONTRACTS = { KHYPE_TOKEN: '0xfD739d4e423301CE9385c1fb8850539D657C296D' as const, STAKING_ACCOUNTANT: '0x9209648Ec9D448EF57116B73A2f081835643dc7A' as const, STAKING_MANAGER: '0x393D0B87Ed38fc779FD9611144aE649BA6082109' as const, VALIDATOR_MANAGER: '0x4b797A93DfC3D18Cf98B7322a2b142FA8007508f' as const, } as const // ABI fragments for the functions we need export const KHYPE_ABI = [ { inputs: [{ name: 'account', type: 'address' }], name: 'balanceOf', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [], name: 'totalSupply', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [ { name: 'spender', type: 'address' }, { name: 'amount', type: 'uint256' }, ], name: 'approve', outputs: [{ name: '', type: 'bool' }], stateMutability: 'nonpayable', type: 'function', }, ] as const export const STAKING_ACCOUNTANT_ABI = [ { inputs: [{ name: 'HYPEAmount', type: 'uint256' }], name: 'HYPEToKHYPE', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [{ name: 'kHYPEAmount', type: 'uint256' }], name: 'kHYPEToHYPE', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, ] as const export const STAKING_MANAGER_ABI = [ { inputs: [], name: 'stake', outputs: [], stateMutability: 'payable', type: 'function', }, { inputs: [{ name: 'amount', type: 'uint256' }], name: 'queueWithdrawal', outputs: [], stateMutability: 'nonpayable', type: 'function', }, { inputs: [{ name: 'withdrawalId', type: 'uint256' }], name: 'confirmWithdrawal', outputs: [], stateMutability: 'nonpayable', type: 'function', }, { inputs: [ { name: 'user', type: 'address' }, { name: 'id', type: 'uint256' }, ], name: 'withdrawalRequests', outputs: [ { components: [ { name: 'hypeAmount', type: 'uint256' }, { name: 'kHYPEAmount', type: 'uint256' }, { name: 'kHYPEFee', type: 'uint256' }, { name: 'bufferUsed', type: 'uint256' }, { name: 'timestamp', type: 'uint256' }, ], type: 'tuple', }, ], stateMutability: 'view', type: 'function', }, { inputs: [{ name: 'user', type: 'address' }], name: 'nextWithdrawalId', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [], name: 'minStakeAmount', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [], name: 'maxStakeAmount', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [], name: 'withdrawalDelay', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [], name: 'unstakeFeeRate', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [], name: 'totalStaked', outputs: [{ name: '', type: 'uint256' }], stateMutability: 'view', type: 'function', }, { inputs: [ { indexed: true, name: 'staking', type: 'address' }, { indexed: true, name: 'staker', type: 'address' }, { indexed: false, name: 'amount', type: 'uint256' }, ], name: 'StakeReceived', type: 'event', }, { inputs: [ { indexed: true, name: 'staking', type: 'address' }, { indexed: true, name: 'user', type: 'address' }, { indexed: true, name: 'withdrawalId', type: 'uint256' }, { indexed: false, name: 'kHYPEAmount', type: 'uint256' }, { indexed: false, name: 'hypeAmount', type: 'uint256' }, { indexed: false, name: 'feeAmount', type: 'uint256' }, ], name: 'WithdrawalQueued', type: 'event', }, ] as const // Client setup export const publicClient = createPublicClient({ chain: hyperEvm, transport: http(), }) ``` ### Deposits (staking) ```typescript import { type Address, formatEther, parseEther, type PublicClient, type WalletClient, } from 'viem' /** * Get current exchange rate for HYPE to kHYPE */ export const getKHYPERate = async ({ amount, publicClient, }: { amount: bigint publicClient: PublicClient }): Promise => { const result = await publicClient.readContract({ abi: STAKING_ACCOUNTANT_ABI, address: CONTRACTS.STAKING_ACCOUNTANT, args: [amount], functionName: 'HYPEToKHYPE', }) return result } /** * Get protocol limits and information */ export const getProtocolInfo = async ({ publicClient, }: { publicClient: PublicClient }) => { const [minStake, maxStake, totalStaked, withdrawalDelay, unstakeFeeRate] = await Promise.all([ publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'minStakeAmount', }), publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'maxStakeAmount', }), publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'totalStaked', }), publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'withdrawalDelay', }), publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'unstakeFeeRate', }), ]) return { maxStake, minStake, totalStaked, unstakeFeeRate, withdrawalDelay, } } /** * Validate stake amount against protocol limits */ export const validateStakeAmount = async ({ amount, publicClient, }: { amount: bigint publicClient: PublicClient }): Promise<{ error?: string; valid: boolean }> => { try { const { maxStake, minStake } = await getProtocolInfo({ publicClient }) if (amount < minStake) { return { error: `Amount below minimum stake of ${formatEther(minStake)} HYPE`, valid: false, } } if (amount > maxStake) { return { error: `Amount above maximum stake of ${formatEther(maxStake)} HYPE`, valid: false, } } return { valid: true } } catch (error) { return { error: 'Failed to validate stake amount', valid: false } } } /** * Stake HYPE tokens */ export const stakeHYPE = async ({ amountInHYPE, publicClient, walletClient, }: { amountInHYPE: string publicClient: PublicClient walletClient: WalletClient }): Promise<{ expectedKHYPE: bigint; hash: string }> => { const amount = parseEther(amountInHYPE) // Validate amount const validation = await validateStakeAmount({ amount, publicClient }) if (!validation.valid) { throw new Error(validation.error) } // Get expected kHYPE amount const expectedKHYPE = await getKHYPERate({ amount, publicClient }) // Execute stake transaction const hash = await walletClient.mutate({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'stake', value: amount, }) return { expectedKHYPE, hash } } /** * Estimate gas for staking */ export const estimateStakeGas = async ({ amountInHYPE, publicClient, walletClient, }: { amountInHYPE: string publicClient: PublicClient walletClient: WalletClient }): Promise => { const amount = parseEther(amountInHYPE) const [account] = await walletClient.getAddresses() return await publicClient.estimateContractGas({ abi: STAKING_MANAGER_ABI, account, address: CONTRACTS.STAKING_MANAGER, functionName: 'stake', value: amount, }) } ``` ### Withdrawals (unstaking) ```typescript export interface WithdrawalRequest { bufferUsed: bigint hypeAmount: bigint kHYPEAmount: bigint kHYPEFee: bigint timestamp: bigint } /** * Get HYPE amount for kHYPE tokens */ export const getHYPERate = async ({ amount, publicClient, }: { amount: bigint publicClient: PublicClient }): Promise => { const result = await publicClient.readContract({ abi: STAKING_ACCOUNTANT_ABI, address: CONTRACTS.STAKING_ACCOUNTANT, args: [amount], functionName: 'kHYPEToHYPE', }) return result } /** * Calculate withdrawal fee */ export const calculateWithdrawalFee = async ({ amount, publicClient, }: { amount: bigint publicClient: PublicClient }): Promise => { const feeRate = await publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'unstakeFeeRate', }) return (amount * feeRate) / 10000n // feeRate is in basis points } /** * Get user's kHYPE balance */ export const getKHYPEBalance = async ({ publicClient, userAddress, }: { publicClient: PublicClient userAddress: Address }): Promise => await publicClient.readContract({ abi: KHYPE_ABI, address: CONTRACTS.KHYPE_TOKEN, args: [userAddress], functionName: 'balanceOf', }) /** * Get next withdrawal ID for user */ export const getNextWithdrawalId = async ({ publicClient, userAddress, }: { publicClient: PublicClient userAddress: Address }): Promise => await publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, args: [userAddress], functionName: 'nextWithdrawalId', }) /** * Get withdrawal request details */ export const getWithdrawalRequest = async ({ publicClient, userAddress, withdrawalId, }: { publicClient: PublicClient userAddress: Address withdrawalId: bigint }): Promise => { const [hypeAmount, kHYPEAmount, kHYPEFee, bufferUsed, timestamp] = await publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, args: [userAddress, withdrawalId], functionName: 'withdrawalRequests', }) return { bufferUsed, hypeAmount, kHYPEAmount, kHYPEFee, timestamp, } } /** * Check if withdrawal is ready to confirm */ export const isWithdrawalReady = async ({ publicClient, userAddress, withdrawalId, }: { publicClient: PublicClient userAddress: Address withdrawalId: bigint }): Promise<{ ready: boolean; timeRemaining: number }> => { try { const [request, withdrawalDelay] = await Promise.all([ getWithdrawalRequest(publicClient, userAddress, withdrawalId), publicClient.readContract({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, functionName: 'withdrawalDelay', }), ]) if (request.timestamp === 0n) { return { ready: false, timeRemaining: 0 } } const currentTime = BigInt(Math.floor(Date.now() / 1000)) const confirmTime = request.timestamp + withdrawalDelay if (currentTime >= confirmTime) { return { ready: true, timeRemaining: 0 } } else { return { ready: false, timeRemaining: Number(confirmTime - currentTime), } } } catch { return { ready: false, timeRemaining: 0 } } } /** * Queue a withdrawal request */ export const queueWithdrawal = async ({ kHYPEAmountStr, publicClient, walletClient, }: { kHYPEAmountStr: string publicClient: PublicClient walletClient: WalletClient }): Promise<{ expectedHYPE: bigint fee: bigint hash: string withdrawalId: bigint }> => { const [userAddress] = await walletClient.getAddresses() const kHYPEAmount = parseEther(kHYPEAmountStr) // Validate balance const balance = await getKHYPEBalance({ publicClient, userAddress }) if (balance < kHYPEAmount) { throw new Error('Insufficient kHYPE balance') } // Get expected values const [expectedHYPE, fee, withdrawalId] = await Promise.all([ getHYPERate({ amount: kHYPEAmount, publicClient }), calculateWithdrawalFee({ amount: kHYPEAmount, publicClient }), getNextWithdrawalId({ publicClient, userAddress }), ]) // Execute withdrawal queue transaction const hash = await walletClient.mutate({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, args: [kHYPEAmount], functionName: 'queueWithdrawal', }) return { expectedHYPE, fee, hash, withdrawalId, } } /** * Confirm a withdrawal request */ export const confirmWithdrawal = async ( publicClient: PublicClient, walletClient: WalletClient, withdrawalId: bigint, ): Promise => { const [userAddress] = await walletClient.getAddresses() // Check if withdrawal is ready const { ready, timeRemaining } = await isWithdrawalReady({ publicClient, userAddress, withdrawalId, }) if (!ready) { throw new Error( `Withdrawal not ready. Time remaining: ${timeRemaining} seconds`, ) } // Execute confirmation transaction const hash = await walletClient.mutate({ abi: STAKING_MANAGER_ABI, address: CONTRACTS.STAKING_MANAGER, args: [withdrawalId], functionName: 'confirmWithdrawal', }) return hash } /** * Get all pending withdrawals for user */ export const getPendingWithdrawals = async ( publicClient: PublicClient, userAddress: Address, ): Promise< Array<{ id: bigint ready: boolean request: WithdrawalRequest timeRemaining: number }> > => { const nextId = await getNextWithdrawalId({ publicClient, userAddress }) const pendingWithdrawals = [] // Check the last 10 withdrawal IDs (adjust as needed) const startId = nextId > 10n ? nextId - 10n : 0n for (let id = startId; id < nextId; id += 1) { try { const request = await getWithdrawalRequest({ publicClient, userAddress, withdrawalId: id, }) if (request.timestamp > 0n) { const { ready, timeRemaining } = await isWithdrawalReady({ publicClient, userAddress, withdrawalId: id, }) pendingWithdrawals.push({ id, ready, request, timeRemaining }) } } catch { // Skip invalid withdrawal IDs continue } } return pendingWithdrawals } ``` ### Complete integration example ```typescript import { createWalletClient, custom } from 'viem' import { hyperEvm } from 'viem/chains' /** * Get comprehensive user dashboard data */ export const getUserDashboard = async ({ publicClient, userAddress, }: { publicClient: PublicClient userAddress: Address }) => { const [kHYPEBalance, protocolInfo, pendingWithdrawals] = await Promise.all([ getKHYPEBalance({ publicClient, userAddress }), getProtocolInfo({ publicClient }), getPendingWithdrawals({ publicClient, userAddress }), ]) // Calculate HYPE equivalent of kHYPE balance const hypeEquivalent = kHYPEBalance > 0n ? await getHYPERate({ amount: kHYPEBalance, publicClient }) : 0n return { balances: { hypeEquivalent: formatEther(hypeEquivalent), kHYPE: formatEther(kHYPEBalance), }, protocol: { maxStake: formatEther(protocolInfo.maxStake), minStake: formatEther(protocolInfo.minStake), totalStaked: formatEther(protocolInfo.totalStaked), unstakeFeePercent: Number(protocolInfo.unstakeFeeRate) / 100, withdrawalDelayHours: Number(protocolInfo.withdrawalDelay) / 3600, }, withdrawals: pendingWithdrawals.map( ({ id, ready, request, timeRemaining }) => ({ fee: formatEther(request.kHYPEFee), hypeAmount: formatEther(request.hypeAmount), id: id.toString(), kHYPEAmount: formatEther(request.kHYPEAmount), ready: ready, timeRemainingHours: timeRemaining / 3600, }), ), } } /** * Stake with transaction monitoring */ export const stakeWithMonitoring = async ({ amountInHYPE, publicClient, walletClient, }: { amountInHYPE: string publicClient: PublicClient walletClient: WalletClient }) => { try { // Estimate gas first const gasEstimate = await estimateStakeGas({ amountInHYPE, publicClient, walletClient, }) console.log(`Estimated gas: ${gasEstimate}`) // Execute stake const { expectedKHYPE, hash } = await stakeHYPE({ amountInHYPE, publicClient, walletClient, }) console.log(`Transaction submitted: ${hash}`) console.log(`Expected kHYPE: ${formatEther(expectedKHYPE)}`) // Wait for confirmation const receipt = await publicClient.waitForTransactionReceipt({ hash }) console.log(`Transaction confirmed in block: ${receipt.blockNumber}`) return { expectedKHYPE, hash, receipt } } catch (error) { console.error('Stake failed:', error) throw error } } /** * Complete withdrawal flow with monitoring */ export const withdrawWithMonitoring = async ({ kHYPEAmount, publicClient, walletClient, }: { kHYPEAmount: string publicClient: PublicClient walletClient: WalletClient }) => { try { // Queue withdrawal const queueResult = await queueWithdrawal({ kHYPEAmountStr: kHYPEAmount, publicClient, walletClient, }) console.log(`Withdrawal queued: ${queueResult.hash}`) console.log(`Withdrawal ID: ${queueResult.withdrawalId}`) console.log(`Expected HYPE: ${formatEther(queueResult.expectedHYPE)}`) console.log(`Fee: ${formatEther(queueResult.fee)}`) // Wait for queue confirmation await publicClient.waitForTransactionReceipt({ hash: queueResult.hash }) return queueResult } catch (error) { console.error('Withdrawal queue failed:', error) throw error } } /** * Monitor and auto-confirm ready withdrawals */ export const autoConfirmReadyWithdrawals = async ( publicClient: PublicClient, walletClient: WalletClient, userAddress: Address, ) => { const pendingWithdrawals = await getPendingWithdrawals({ publicClient, userAddress, }) const readyWithdrawals = pendingWithdrawals.filter((w) => w.ready) const confirmPromises = readyWithdrawals.map(async (withdrawal) => { try { const hash = await confirmWithdrawal({ publicClient, walletClient, withdrawalId: withdrawal.id, }) console.log(`Confirmed withdrawal ${withdrawal.id}: ${hash}`) return { hash, id: withdrawal.id, success: true } } catch (error) { console.error(`Failed to confirm withdrawal ${withdrawal.id}:`, error) return { error, id: withdrawal.id, success: false } } }) return Promise.all(confirmPromises) } // Usage example export const initializeKinetiq = async () => { // Setup wallet client (assuming window.ethereum is available) const walletClient = createWalletClient({ chain: hyperEvm, transport: custom(window.ethereum), }) // Get user address (assuming wallet is connected) const accounts = await window.ethereum.request({ method: 'eth_accounts' }) const userAddress = accounts[0] as Address // Get dashboard data const dashboard = await getUserDashboard({ publicClient, userAddress }) console.log('User Dashboard:', dashboard) return { dashboard, publicClient, userAddress, walletClient } } ``` ### Error handling and best practices ```typescript /** * Handle contract errors with user-friendly messages */ export const handleContractError = ({ error }: { error: any }): string => { if (error.message?.includes('insufficient funds')) { return 'Insufficient HYPE balance for transaction' } if (error.message?.includes('Below minimum stake')) { return 'Stake amount is below the minimum required' } if (error.message?.includes('Above maximum stake')) { return 'Stake amount exceeds the maximum allowed' } if (error.message?.includes('Would exceed staking limit')) { return 'This stake would exceed the protocol limit' } if (error.message?.includes('Withdrawal delay not met')) { return 'Withdrawal is still in the delay period' } return error.message || 'Transaction failed' } /** * Retry operation with exponential backoff */ export const retryWithBackoff = async ({ baseDelay = 1000, maxRetries = 3, operation, }: { baseDelay: number maxRetries: number operation: () => Promise }): Promise => { for (let tryCount = 0; tryCount < maxRetries; tryCount += 1) { try { return await operation() } catch (error) { if (tryCount === maxRetries - 1) { throw error } const delay = baseDelay * Math.pow(2, tryCount) await new Promise((resolve) => setTimeout(resolve, delay)) } } throw new Error('Max retries exceeded') } // Usage with error handling export const safeStake = async ({ amount, publicClient, walletClient, }: { amount: string publicClient: PublicClient walletClient: WalletClient }) => { try { const result = await retryWithBackoff({ operation: () => stakeWithMonitoring({ amountInHYPE: amount, publicClient, walletClient, }), }) return { result, success: true } } catch (error) { const message = handleContractError({ error }) return { error: message, success: false } } } ``` --- # Contracts and audits Mainnet contract deployments for the Kinetiq protocol products. ## Kinetiq Staked HYPE (kHYPE) | Contract | Address | | --- | --- | | [kHYPE token](https://hyperevmscan.io/token/0xfD739d4e423301CE9385c1fb8850539D657C296D) | `0xfD739d4e423301CE9385c1fb8850539D657C296D` | | [StakingManager ](https://hyperevmscan.io/address/0x393D0B87Ed38fc779FD9611144aE649BA6082109) | `0x393D0B87Ed38fc779FD9611144aE649BA6082109` | | [PauserRegistry](https://hyperevmscan.io/address/0x752E76ea71960Da08644614E626c9F9Ff5a50547) | `0xac03CABA51e17c86c921E1f6CBFBdC91F8BB2E6b` | | [ValidatorManager](https://hyperevmscan.io/address/0x4b797A93DfC3D18Cf98B7322a2b142FA8007508f) | `0x4b797A93DfC3D18Cf98B7322a2b142FA8007508f` | | [StakingAccountant](https://hyperevmscan.io/address/0x9209648Ec9D448EF57116B73A2f081835643dc7A) | `0x9209648Ec9D448EF57116B73A2f081835643dc7A` | | [OracleManager](https://hyperevmscan.io/address/0x192826e470bd65FDC2CB472eDd834D096233049b) | `0x192826e470bd65FDC2CB472eDd834D096233049b` | | [DefaultOracle](https://hyperevmscan.io/address/0xefbcCc6E33DA1C1ef638cBc0F044968D0f590fED) | `0xefbcCc6E33DA1C1ef638cBc0F044968D0f590fED` | | [OracleAdapter](https://hyperevmscan.io/address/0xefbcCc6E33DA1C1ef638cBc0F044968D0f590fED) | `0xefbcCc6E33DA1C1ef638cBc0F044968D0f590fED` | | [*Operator*](https://hyperevmscan.io/address/0x23A4604cDFe8e9e2e9Cf7C10D7492B0F3f4B4038) | `0x23A4604cDFe8e9e2e9Cf7C10D7492B0F3f4B4038` | ## Markets by Kinetiq (kmHYPE) | Contract | Address | | --- | --- | | [kmHYPE token](https://hyperevmscan.io/token/0x360C140E5344A1A0593D44B4ea6Fc7C3DAf0C473) | `0x360C140E5344A1A0593D44B4ea6Fc7C3DAf0C473` | | [ExchangeRouter](https://hyperevmscan.io/address/0x6AB31532382Ba5cD5E8b5D343Cf5995906bb8DD8) | `0x6AB31532382Ba5cD5E8b5D343Cf5995906bb8DD8` | | [ExchangeManager](https://hyperevmscan.io/address/0x4ef8bBaceE867eFd6Faa684B30ecD12DF74C4A48) | `0x4ef8bBaceE867eFd6Faa684B30ecD12DF74C4A48` | | [StakingManager](https://hyperevmscan.io/address/0x71F0019cC7fa79E4f42587FB7b9a817D8d2429EC) | `0x71F0019cC7fa79E4f42587FB7b9a817D8d2429EC` | | [StakingAccountant](https://hyperevmscan.io/address/0x5901e744759561C63309865Ef8822aBb041655E2) | `0x5901e744759561C63309865Ef8822aBb041655E2` | | [ValidatorManager](https://hyperevmscan.io/address/0x3899b60878c742a18A46A31Ad208bddfA19Fd266) | `0x3899b60878c742a18A46A31Ad208bddfA19Fd266` | | [OracleManager](https://hyperevmscan.io/address/0x673C57b16F3855CB08030290654bb5E26Ac8E273) | `0x673C57b16F3855CB08030290654bb5E26Ac8E273` | | [DefaultOracle](https://hyperevmscan.io/address/0x9c2Fc9AE6261d08EA8f1dBe53F58C99F7eF9FCA2) | `0x9c2Fc9AE6261d08EA8f1dBe53F58C99F7eF9FCA2` | | [OracleAdapter](https://hyperevmscan.io/address/0xD477333725258d5174e91c959c2f5A71Ed681a30) | `0xD477333725258d5174e91c959c2f5A71Ed681a30` | | [PauserRegistry](https://hyperevmscan.io/address/0xcE8018B29C36423F6A512b384B56B25e069Da79e) | `0xcE8018B29C36423F6A512b384B56B25e069Da79e` | | [GlobalConfig](https://hyperevmscan.io/address/0x32C00306e872cC216cF144C2D8c7aFb3Cd4BB0F8) | `0x32C00306e872cC216cF144C2D8c7aFb3Cd4BB0F8` | | [BlockedWithdrawalQueue](https://hyperevmscan.io/address/0x22850d7cFbA41aE241BE61FC56295Db0C159a4ec) | `0x22850d7cFbA41aE241BE61FC56295Db0C159a4ec` | | [GhostLST token](https://hyperevmscan.io/token/0x74323CD0Db2FD826CadCc90153995F1E2b1d0801) | `0x74323CD0Db2FD826CadCc90153995F1E2b1d0801` | | [*Operator*](https://hyperevmscan.io/address/0x4459872f33d7e3b61238a6edc7611463c25D82Fa) | `0x4459872f33d7e3b61238a6edc7611463c25D82Fa` | ## Institutional Deployments These are the institutional deployments of Kinetiq's liquid staking protocol. ### Flowdesk (flowHYPE) | Contract | Address | | --- | --- | | [flowHYPE token](https://hyperevmscan.io/token/0x86d96fF0E78Dba9570b00f75807ce21213a19f3d) | `0x86d96fF0E78Dba9570b00f75807ce21213a19f3d` | | [StakingManager](https://hyperevmscan.io/address/0xfdd35c5179E8594E237031dd945E0584Af29572b) | `0xfdd35c5179E8594E237031dd945E0584Af29572b` | | [StakingAccountant](https://hyperevmscan.io/address/0x968c6AB57CDe284eABA42D811b633BF27BdACC03) | `0x968c6AB57CDe284eABA42D811b633BF27BdACC03` | | [*Operator*](https://hyperevmscan.io/address/0x992d51A0d910985946A71F1eb5a4831736Db80f5) | `0x992d51A0d910985946A71F1eb5a4831736Db80f5` | ### Hyperion (HiHYPE) | Contract | Address | | --- | --- | | [HiHYPE token](https://hyperevmscan.io/token/0x4f322145aBedb2b39f69e7d4531AB4B2e6483154) | `0x4f322145aBedb2b39f69e7d4531AB4B2e6483154` | | [StakingManager](https://hyperevmscan.io/address/0xaD492f9CADcccE9c3c213edd8aE55c152cD3A3ad) | `0xaD492f9CADcccE9c3c213edd8aE55c152cD3A3ad` | | [StakingAccountant](https://hyperevmscan.io/address/0x62E6fa898761dE2345aB3d507b72c422a2829733) | `0x62E6fa898761dE2345aB3d507b72c422a2829733` | | [*Operator*](https://hyperevmscan.io/address/0x0A3600f3F36bbBF306ce7e9fD93aF7e845908Cf1) | `0x0A3600f3F36bbBF306ce7e9fD93aF7e845908Cf1` | ### ASXN (asxnHYPE) | Contract | Address | | --- | --- | | [asxnHYPE token](https://hyperevmscan.io/token/0x8599F2eFA5064C666B920E71381b5aaBc7Bb27F6) | `0x8599F2eFA5064C666B920E71381b5aaBc7Bb27F6` | | [StakingManager](https://hyperevmscan.io/address/0x0c5d890Cf52973aE4A7b10fA7EE18e146d13D87B) | `0x0c5d890Cf52973aE4A7b10fA7EE18e146d13D87B` | | [StakingAccountant](https://hyperevmscan.io/address/0x2312Dd3349De01C2370b5BFFe3Ce5B4f69eAb797) | `0x2312Dd3349De01C2370b5BFFe3Ce5B4f69eAb797` | | [*Operator*](https://hyperevmscan.io/address/0x3eAC994c86DA01538ad5dE1d0fb7BE6CC550b06c) | `0x3eAC994c86DA01538ad5dE1d0fb7BE6CC550b06c` | ### HYLQ (hylqHYPE) | Contract | Address | | --- | --- | | [hylqHYPE token](https://hyperevmscan.io/token/0x498edC41Fa92530920a95483dea7a6CCe91F1C5c) | `0x498edC41Fa92530920a95483dea7a6CCe91F1C5c` | | [StakingManager](https://hyperevmscan.io/address/0x09B4cdA849037D1717e91D201EE416bf1c113895) | `0x09B4cdA849037D1717e91D201EE416bf1c113895` | | [StakingAccountant](https://hyperevmscan.io/address/0x5D544F496FC2E7189375e749E4813dA82a91Cb9e) | `0x5D544F496FC2E7189375e749E4813dA82a91Cb9e` | | [*Operator*](https://hyperevmscan.io/address/0xb73E42C4Ad32eD15BED4cba22Ba380449a4f60d5) | `0xb73E42C4Ad32eD15BED4cba22Ba380449a4f60d5` | ## Audit reports All of Kinetiq’s audits are available at [audits.kinetiq.xyz](https://audits.kinetiq.xyz). | Date | Auditor | Report | | --- | --- | --- | | Jan 15, 2026 | [Spearbit](https://spearbit.com) | [skntq-january-2026-spearbit.pdf](https://drive.google.com/file/d/1LSZWM2sheoh1qeBqjkwkkl_1wO8gtI6H/view) | | Nov 27, 2025 | [Spearbit](https://spearbit.com) | [kmhype-november-2025-spearbit.pdf](https://drive.google.com/file/d/1uffwIAjfRDdCLCTpN66h1zK_Qji41Fr-/view) | | Nov 24, 2025 | [Zenith](https://www.zenith.security) | [kmhype-november-2025-zenith.pdf](https://drive.google.com/file/d/1pMti8B4qM15-v61AyGe-hEdi8zcXR6at/view) | | Nov 23, 2025 | [Pashov Audit Group](https://pashov.com) | [khype-lst-instant-unstake-nov-2025-pashov.pdf](https://drive.google.com/file/d/1ada6eazjmtatQIt38_QrZ3Nks7pYTly1/view) | | June 24, 2025 | [Spearbit](https://spearbit.com) | [khype-lst-june-2025-spearbit.pdf](https://drive.google.com/file/d/121JxhR9TpWGEoa1-GGm9fNbl3ByjOOhe/view) | | Apr 16, 2025 | [Code4rena (C4)](https://code4rena.com) | [khype-lst-april-2025-code4rena.pdf](https://drive.google.com/file/d/1C5F5k-xo7OtDpMnkHikcCpf3YoRcpFcW/view) | | Mar 17, 2025 | [Zenith](https://www.zenith.security) | [khype-lst-march-2025-zenith.pdf](https://drive.google.com/file/d/1S5Xm1rinC7kOt826eXhwrVbX7WtdwsWr/view) | | Mar 6, 2025 | [Pashov Audit Group](https://pashov.com) | [khype-lst-march-2025-pashov.pdf](https://drive.google.com/file/d/1k9jA3JJ_e85AtI-EJRBdo-cq4JOvBok3/view) | --- # Earn kHYPE DeFi strategy vault, powered by Veda ## Overview of Kinetiq Earn Kinetiq has partnered with [Veda](https://x.com/veda_labs) to offer the **Kinetiq Earn vault**, a fully automated kHYPE DeFi strategy vault that allows kHYPE stakers to have access to the highest yielding opportunities across Hyperliquid DeFi utilizing their kHYPE. The vault is managed by Veda’s in-house risk curator, [Seven Seas](https://x.com/sevenseas_c), who manages >$4b in total value locked across all of their vaults. ### Key benefits - **Automated strategy execution** — Automated access to various DeFi protocols - **Capital efficiency** — Capture yield with no manual deployment or rebalancing - **Risk-adjusted opportunity curation** — Institutional-grade vetting and monitoring. - Veda vets each protocol by consulting with respective teams, assessing audits and general security practices, and more. - **Vault token (vkHYPE)** — Earned upon deposit, represents your share of the vault - **Earn kPoints** — Learn more about [kPoints](/docs/kpoints) - **Earn Veda rewards & more** — the “Rewards” section is a live view of what’s earned based on existing deposits and can change at any time depending on how the vault is allocated. All kHYPE stakers are welcome to run whatever strategy they’d like outside Kinetiq Earn, therefore if you prefer a self-custodial approach, feel free to utilize your kHYPE across the various partners supporting kHYPE, you may find them on the [Earn](/earn) page. ## How can I earn? 1. Head to Kinetiq → [Earn](/earn) 2. Deposit kHYPE (or HYPE) into the vault 3. Receive vkHYPE — a receipt token representing your position 4. Veda allocates funds across yield protocols 5. Your vkHYPE appreciates in value 6. Withdraw any time (based on protocol constraints) Track the [Kinetiq Earn vault with Veda](https://debank.com/profile/0x9ba2edc44e0a4632eb4723e81d4142353e1bb160). ## Vault mechanics ### vkHYPE vault token - Tracks your position in the vault - Includes principal + all accrued yield + kPoints ### Fee structure (as of August 18, 2025) - Performance Fee: 20% (profit-only, fully aligned) - Fees are only charged on profits the vault generates, never on deposited capital. - If no profit is made, no fee is taken. - No fees were charged during the first month of operation as this was considered a promotional period by Veda. - No Management Fee - No Entry/Exit Fees Note: APY displayed is post-fee. If the dashboard says 6%, you earn 6% net — no surprises. ### Yield distribution - Rewards from underlying DeFi strategies auto-compound - Users earn a share of any protocol-native token incentives - Vault dashboard displays net performance ### Beyond the Earn vault Prefer self-custody and manual strategies? Visit the [Earn page](/earn) to view protocol integrations with kHYPE. ## Summary of how to start earning ### Option 1: Earn vault 1. Open the [Earn page](/earn) 2. Connect wallet 3. Deposit kHYPE or HYPE 4. Receive vkHYPE receipt token 5. Track earnings via dashboard ### Option 2: Self-directed 1. Visit [Earn page](/earn) 2. Choose supported protocols 3. Connect to DEXs, lending markets, etc. 4. Deploy your strategy manually ## Risk considerations ### Vault-specific - Smart contract risks from vault architecture - Exposure to protocol-level risks (e.g. liquidation, bugs) - Delays in underlying withdrawals (depends on protocol) ### Self-directed - Higher management overhead - Requires tracking of multiple positions - Potential for greater reward and greater risk ### Best practices - Start small to test strategy - Monitor dashboards regularly - Understand underlying protocol dynamics - Diversify where possible --- # KNTQ Governance token of the Kinetiq protocol The **KNTQ** token sits at the center of the Kinetiq protocol and serves as its governance token. KNTQ is the sole instrument through which all of Kinetiq’s value accrues. The KNTQ genesis event took place on **November 27th, 2025** on Hyperliquid, representing the first major token launch in the ecosystem. ## Supply & distribution KNTQ has a maximum supply of **1,000,000,000**. ### Vesting schedule All **core contributors and investors** share the same vesting schedule: - **Total duration:** 3 years - **Cliff:** 1 year - **Vesting:** 2-year monthly linear vesting following the cliff. ## Value accrual mechanisms Kinetiq employs several mechanisms to ensure value flows directly to token holders: - **sKNTQ:** KNTQ can be staked for sKNTQ, featuring a **7-day withdrawal period**. - **Buybacks:** 100% of Kinetiq’s disposable Markets income (minimum 10% of deployer share + builder code revenue). - **Launch revenue:** 100% of Kinetiq’s share of Launch revenue (10% of deployer share) is used for KNTQ buybacks. - **KIP-2 revenue streams:** - **Revenue:** 70% used for KNTQ buybacks (30% to Kinetiq treasury for operations). - **Validator commissions:** 100% of the validator commission share is used for buybacks. > Kinetiq active set validators share 50% of the commission charged on stake from the protocol to opt-in, in perpetuity. - **Burn mechanism:** 100% of KNTQ trading fees are sent to the **assistance fund**, effectively burning them from supply. **All acquired KNTQ from these mechanisms is sent to the sKNTQ contract and distributed proportionally to sKNTQ holders.** ## sKNTQ tiers Staking KNTQ grants users access to specific protocol benefits, including increased referral shares and kmHYPE minting rights. ### Markets referral yield | Tier | Amount (sKNTQ) | % Referral share | | --- | --- | --- | | 1 | 50,000 | 6% | | 2 | 100,000 | 7% | | 3 | 500,000 | 8% | | 4 | 1,250,000 | 10% | | 5 | 2,500,000 | 15% | ### kmHYPE minting allocations | Tier | Amount (sKNTQ) | kmHYPE minting allocation | | --- | --- | --- | | 1 | 50,000 | Up to 1,111 | | 2 | 100,000 | Up to 11,111 | | 3 | 500,000 | Up to 111,111 | | 4 | 1,250,000 | Up to 222,222 | | 5 | 2,500,000 | ∞ (up to cap) | --- # kPoints **Distribution details** - **Snapshots:** Taken every **Tuesday** - **Distributions:** Occur every **Thursday** - **Weekly distributions:** **800,000 kPoints** Details around the kPoints program are kept entirely private, regardless of anyone’s strategy or usage. **Reminder:** Repeated questions about the formula in Discord will result in: muting, timeouts and potential bans for repeat offenders. Thank you for using Kinetiq and participating in our ecosystem. We’re excited to see how you use Kinetiq and its products to shape the future of Hyperliquid DeFi. --- # Launch overview Exchange-as-a-Service (EaaS) ## What is Launch? Launch by Kinetiq is the first Exchange-as-a-Service (EaaS) platform built on Hyperliquid’s HIP-3 protocol, enabling anyone to deploy and operate their own perpetual futures exchange—without the $20M+ capital barrier that previously kept HIP-3 deployments out of reach. By combining Kinetiq’s proven LST infrastructure with a crowdfunding model, Launch makes it possible for teams to raise the 500,000+ HYPE stake required to deploy “builder-deployed markets” on Hyperliquid. Each deployment runs on isolated staking pools, ensuring risk is limited to the exchange you choose to support. ## Why HIP-3 matters HIP-3 introduces builder-deployed perps—a protocol upgrade that lets external teams launch and operate their own perp markets on top of HyperCore infrastructure. Under HIP-3: - Stake Requirement: 500k+ HYPE staked per deployer - Fee Share: Deployers can earn up to 50% of trading fees - Risk Controls: Stakes can be slashed for malicious activity (e.g., bad oracles) This opens the door for more diverse and specialized markets, but the capital requirement is a major hurdle—exactly what Launch solves. ## How Launch works - Crowdfund the stake – Contributors pool HYPE into an exchange-specific staking contract. - Deploy your exchange – Kinetiq infrastructure handles validator setup, smart contracts, and integration. - Operate your markets – Deployers focus on market curation, trading experience, and community. - Earn & distribute fees – Trading fees are automatically shared with contributors. ## Risk isolation with exLSTs Each Launch deployment issues its own exchange-specific LST (exHYPE). - Separate pools for each exchange deployment - Slashing events only affect that specific pool - Contributors receive returns based solely on the exchange they backed Example: Stake in exchange A, get exA-HYPE-completely isolated from exchange B. ## The “Shopify x Kickstarter” model for perp markets Think of Launch as: - Shopify: Full tech stack to run your own exchange without building from scratch. - Kickstarter: Crowdfunding the capital needed to launch via your community. - Deployers focus on markets & community. Contributors back projects they believe in and earn yield from their success. Traders enjoy more market diversity and innovation. ## Benefits by role **For deployers:** - Avoid $20M+ capital lockup - Focus on your edge-market curation, branding, and growth - Earn a share of fees from your exchange **For HYPE contributors:** - Back exchanges aligned with your interests - Earn yield from specific market deployments - Diversify across multiple exLSTs **For traders:** - Access new, specialized markets - Benefit from competitive fees and high-performance infra ## Security Our contracts have been audited by Cantina and Zero Cool. ## What’s next - Testnet deployment & security audits - First wave of partner exchanges launching via Launch - Crowdfunding UI for contributors - Governance frameworks for exchange-specific decisions ## Interested in deploying a HIP-3 exchange or supporting one through Launch? Contact us at [contact@kinetiq.xyz](mailto:contact@kinetiq.xyz) to get started. --- # Deployer & operator guide Kinetiq Launch is the Exchange-as-a-Service (EaaS) platform that lets a team deploy and run a HIP-3 perp dex on Hyperliquid in a few well-defined steps. This guide is for the deployer (the team that bonds capital and chooses the market's roles) and the operator (the address that runs day-to-day lifecycle calls). It covers what you deploy, what you configure, what gets called on-chain, and how the protocol coordinates with HyperCore behind the scenes. What you end up owning when a Launch market is live: a per-market contract suite on HyperEVM, an ERC-20 exLST token unique to your market, a HyperCore perp dex paired with that suite, and a share of the trading fees that flow from it. The path from configuration to live trading is three on-chain calls plus a brief coordination with Kinetiq to register the market's HyperCore API wallet. > **Diagram color key (consistent across every diagram below).** 🟦 **Blue** — HyperEVM contracts / on-chain calls · 🟩 **Teal** — HyperCore side · 🟨 **Amber** — capital / reserve / value flow · 🟪 **Purple** — Kinetiq protocol / enclave · ⬜ **Slate** — external actors & roles · 🟢 **Green** — deployer revenue / exLST appreciation · 🟥 **Red** — risk / terminal state. > **Diagram — Lifecycle at a glance (phase state machine).** The full path from deploy to wind-down, with the call that drives each transition. ## How a Launch market is structured Each market deploys as an **isolated** per-market suite. Capital, exposure, and fee flow stay within the market — a loss or wind-down in one market does not affect another. The suite contains four contracts the deployer should know by name: - `EXManager` — the lifecycle + roles state machine for the market. Holds the phase (UNBONDED → FUNDING → LAUNCHING → LIVE → WOUND_DOWN), gates every operator call, and tracks role membership. - `EXLST` — the market's ERC-20 token. Depositors receive `EXLST` when they stake HYPE; the deployer's bonded `opBond` also mints `EXLST` at bond time. The token's redemption rate appreciates as the buyback loop converts trading fees into reserve HYPE. - `StakingManagerRouter` — the per-market KIP-2 LST router. This is the contract that bonds your `opBond` plus depositor stake to your chosen validator on Hyperliquid, receives staking rewards from the validator delegation, and (after `launch`) holds the HyperCore API wallet registration that connects the market to the on-HC perp dex. - `LaunchFeeSplitter` — the per-market fee router that takes trading fees on HyperCore and splits them between the protocol, the buyback loop, and your deployer treasury. > **Diagram — Contract suite and value flow.** How the four named contracts wire to the validator, the HyperCore perp dex, and the fee splitter. The exLST appreciates from **two independent sources**, both of which compound into the per-market reserve and raise the exLST → HYPE redemption rate over time: - **Native validator delegation rewards.** The entire reserve — your bonded `opBond` plus all depositor stake — is delegated to your chosen Hyperliquid validator. Staking rewards accrue on that delegation continuously, and the keeper layer flows them back into the reserve. - **HyperCore trading-fee buybacks.** A configurable share (`buybackBps`) of the per-market perp dex's trading fees converts to HYPE on HC spot and feeds back into the reserve via a per-market throttle contract that smooths the flow. Both yield streams accrue to every exLST holder pro-rata, including the deployer's bonded position. There is no separate claim or vesting — the redemption rate simply moves up. > **Diagram — Dual-yield appreciation loop.** Both streams compound into the same reserve and lift the redemption rate for every holder. ## Roles you choose at deploy Three role addresses are chosen at deploy time. They can be the same address, distinct EOAs, multisigs, or any mix. Pick them with operational security in mind — they have different powers and different rotation paths. - **Admin** — the meta-authority for your market. The admin's only on-chain power is rotating the operator, admin, and enclaver via `EXFactory.transferOperator` / `transferAdmin` / `transferEnclaver`. It does not run the lifecycle. This is typically your governance multisig. - **Operator** — runs the market lifecycle on `EXManager`: `fund` (transition FUNDING → LAUNCHING), `launch` (LAUNCHING → LIVE), `updateWallet` (rotate the HC API wallet), `setUnwindPhase` and `unwind` (voluntary exit), plus tier upgrades in LIVE. Receives `OPERATOR_ROLE` on the per-market `EXManager`. Can be the same address as admin, or a dedicated operations key. - **Enclaver** — the per-market on-chain identifier the Kinetiq signing enclave checks (via the market's `WALLET_ROLE`) when authenticating HyperCore-side API-wallet requests for your market. **Today**, while the initial deployer cohort onboards through a JSON handshake with Kinetiq, the enclaver is pinned to a Kinetiq-managed address. **Once Kinetiq exposes a deployer-facing API / UI for enclave interactions**, the enclaver becomes a deployer-chosen address: you set it to whichever wallet or service you want driving your market's wallet rotations, and the enclave authenticates incoming requests against your on-chain `WALLET_ROLE` membership. The on-chain mechanism is the same in both modes; what changes is the requester. A fourth role, the **launch client / deployer EOA**, is whoever calls `EXFactory.deployMarket` and bonds the capital. That address becomes the immutable owner of the bond shares and receives them back when the market winds down. > **Diagram — Roles and powers.** Who can call what, and what each role owns. ## Deployment configuration Your market is described by the `MarketParams` struct that you pass to `EXFactory.deployMarket`. Most fields you fill in; a couple are pinned by Kinetiq for the initial cohort. ```solidity struct MarketParams { address admin; address operator; address enclaver; uint256 opBond; address validator; address gate; string lstName; string lstSymbol; uint256 marketTier; address hyperCoreDeployer; address deployerTreasury; uint64 buybackBps; } ``` ### Fields you set The roles you've already chosen — **admin** and **operator** — come first. You also pick: - `validator` — the Hyperliquid L1 validator your market delegates to. Must be in Kinetiq's approved validator set; `deployMarket` reverts if it isn't. - `opBond` — the deployer bond in wei. Must satisfy the network's `globalConfig.minOperatorBond()` floor (**1000 HYPE on mainnet**, 1 HYPE on testnet and mainnet-dryrun) and be 1e10-aligned, because HYPE bridges to HyperCore at 8 decimals and any sub-1e10 wei would be truncated. The bond is sent as `msg.value` on `deployMarket` (so the HYPE must sit on the deployer's **HyperEVM** balance at call time), locked for the life of the market, and returned to the deployer when wind-down finalizes. - `lstName` **/** `lstSymbol` — the ERC-20 name and symbol for your per-market `EXLST` token. Visible to depositors in wallets and explorers. - `gate` *(optional)* — an `IEXGate` contract address for access control on deposits and withdrawals. Set to `0x0` for no gate (the typical initial market setup). When set, the gate's `onDeposit` / `onWithdraw` hooks fire after every action and can revert to reject — useful for whitelisting, tiered caps, or token-lock-based mint allowances. - `hyperCoreDeployer` — the HyperCore-side spot address that owns the HC ticker paired with your `EXLST`. This is the wallet that buys the ticker on the HC auction and deploys the HC spot asset. - `deployerTreasury` — your treasury address on HyperCore spot (not HyperEVM). Receives your share of HIP-3 trading fees via the per-market `LaunchFeeSplitter`. Must already be **activated** on HyperCore — the factory's `deployMarket` checks this and reverts if not. - `buybackBps` — the dial between exLST compounding and direct deployer revenue. Basis points (0–10000) of the post-protocol-fee remainder that route to the per-market buyback loop. Higher values send more value to exLST holders (including your bonded share); lower values send more to your `deployerTreasury` as direct revenue. Typical mainnet value is `1000` (10%). ### Fields pinned by Kinetiq Two fields are pinned by Kinetiq today (not deployer-selectable): - `marketTier` — the market tier index. Tier 1 is the HIP-3 default: a `minHypeStake` floor of 500,000 HYPE (the reserve floor enforced once the market is LIVE) and an `EXLST` supply cap of 750,000 HYPE-equivalent. Higher tiers unlock additional capacity and are gated by Kinetiq's tier registry. - `enclaver` — for the initial deployer cohort, this is set to a Kinetiq-managed address while the JSON-handshake onboarding flow is in place. Once Kinetiq ships the deployer-facing API / UI for the enclave, deployers set this themselves to a wallet or service they control. The on-chain authentication mechanism (the `WALLET_ROLE` check inside the enclave) is unchanged either way. ## HyperCore configuration The HyperCore side of the deploy is described in a small JSON payload the deployer hands to Kinetiq during onboarding. Two distinct concerns live in this JSON. **Asset registration.** The JSON specifies the perp's coin ticker, size decimals, initial oracle price, margin table id, isolated-versus-cross flag, dex namespace, full dex name, and the collateral token id (the asset traders post on the perp; the same token id is what `activateMarket` bridges). Kinetiq submits the `perpDeploy.registerAsset` and accompanying setup variants on the deployer's behalf during onboarding to bring the per-market perp dex online for the first time. **Sub deployers.** The JSON also lists the deployer's own addresses that should be authorized to call specific HC `perpDeploy` variants on an ongoing basis. These are addresses the **deployer controls** — Kinetiq does not custody them. After onboarding, the deployer uses these sub deployer addresses to directly call HC variants: adding new coin tickers to the dex via `registerAsset`, updating oracle prices via `setOracle`, adjusting funding multipliers, halting trading, and so on. No further JSON handshake with the protocol team is required for these ongoing HC operations. ## The deployment sequence The on-chain path from configuration to a FUNDING-phase market is three calls on `EXFactory`. HyperCore must confirm the activation token bridge between phases 2 and 3, so each is its own transaction. > **Before you deploy: enable HyperEVM big blocks for your deployer address.** The per-market suite is roughly thirteen contracts deployed atomically by `EXFactory.deployMarket`, and it will not fit in HyperEVM's default block gas limit. Big blocks must be toggled on for the deploy EOA *before* you call `deployMarket`, or the transaction will revert. ```solidity EXFactory.deployMarket{value: opBond}(params); // 1. escrow opBond, deploy per-market suite EXFactory.activateMarket(marketId, tokenId, amount); // 2. bridge activation token to HyperCore EXFactory.bondMarket(marketId); // 3. finalize bond -> FUNDING ``` > **Diagram — Deployment sequence.** The three `EXFactory` calls and the one-way HyperCore bridge that must confirm between phases 2 and 3. Participant boxes are tinted by domain (slate = deployer, blue = HyperEVM, teal = HyperCore). 1. `deployMarket` — the launch client submits the `MarketParams` struct plus `opBond` HYPE to `EXFactory`. The factory escrows the bond, deploys the full per-market contract suite, and stores `MarketInfo`. *Capital here*: `opBond` HYPE on the deployer EOA **on HyperEVM** (≥ 1000 HYPE on mainnet). If your HYPE balance lives on HyperCore spot, bridge it over to HyperEVM before calling. (Requires big blocks enabled — see callout above.) 2. `activateMarket` — anyone can call this, though typically the launch client does. The factory pulls the activation token from the caller's **HyperEVM** balance (default: USDC; the protocol requires roughly 6 USDC for the three CoreWriter-calling contracts to each receive an HC account) and bridges per-contract shares to HyperCore. *Capital here*: the activation token must be on HyperEVM at call time — bridge from HyperCore spot first if your balance lives there. HyperCore must confirm the bridge before bonding can proceed. 3. `bondMarket` — the launch client closes the loop. No additional capital is required for this call. The factory forwards the already-escrowed `opBond` to be staked in the protocol, where it earns validator delegation rewards alongside depositor stake. The `EXLST` shares minted 1:1 against the bonded stake are escrowed in `EXManager` as the deployer's **skin in the game** — locked for the life of the market and swept back to the deployer only when wind-down finalizes. The market transitions to **FUNDING**, and depositors can now stake HYPE through the protocol's deposit flow. ### Pre-bond exit — `cancelMarket` Between `deployMarket` and `bondMarket`, the launch client may abort the deploy via `EXFactory.cancelMarket(marketId, recipient)`. The factory refunds the escrowed `opBond` to the chosen recipient (defaults to the deploy EOA if omitted). The call is **time-locked**: it becomes available only after `block.timestamp >= cancelEligibleAt`, where `cancelEligibleAt` was snapshotted at `deployMarket` time as `block.timestamp + globalConfig.unwindDelay()`. That delay is 1 day on testnet and mainnet-dryrun, and 7 days on mainnet. One caveat: if the activation token was already bridged to HyperCore via `activateMarket`, it is not recoverable on L1 — bridge transfers are one-way. `cancelMarket` is the right path for a deployer who decides not to launch before bonding — for example a risk-parameter rethink or any other reason to step back. After bonding, the exit path moves to the operator-driven `setUnwindPhase` → `unwind` flow described below. ## What happens after bond — operator lifecycle Once `bondMarket` lands and the market is in FUNDING, the operator takes over for the rest of the lifecycle. The admin's role is reactive (rotate keys if needed). Three flows matter to the operator: going LIVE, ongoing operations, and voluntary wind-down. ### Funding to launch Two operator calls bracket the transition from FUNDING through LAUNCHING into LIVE. ```solidity EXManager.fund(); // 1. FUNDING -> LAUNCHING (reserves >= tier floor) EXManager.launch(walletSignedData); // 2. LAUNCHING -> LIVE (registers HC API wallet) ``` The operator calls `fund()` once the per-market reserve meets the tier floor (500,000 HYPE for Tier 1). It's callable any time reserves are at or above the floor, so the operator can choose to wait until reserves reach the tier's `EXLST` supply cap (750,000 HYPE for Tier 1) before going LIVE if they want to mint more shares first. This is a pure HyperEVM state transition — no HyperCore interaction yet. For `launch`, the contract requires an EIP712-signed `walletSignedData` payload. The payload carries the **HyperCore API wallet** — the "agent" address that signs HyperCore actions on behalf of the market's `StakingManagerRouter` — plus a monotonic nonce and the target market id. The enclave signs this payload with `globalConfig.exWalletAdmin`. Once `EXManager.launch(walletSignedData)` runs, the `StakingManagerRouter` calls CoreWriter action 9 (`addApiWallet`) to register the API wallet on HyperCore. The market is now connected end to end and trading can proceed. > **Diagram —** `launch` **/ API-wallet signing flow.** How the enclave authenticates the request (via `WALLET_ROLE`) and signs the payload that `launch` submits on-chain. `updateWallet` later rotates the wallet through the same path. Boxes: slate = deployer/operator, purple = Kinetiq enclave, blue = HyperEVM, teal = HyperCore. The signing key (`globalConfig.exWalletAdmin`) is held in an enclave so it never leaves the protocol's trusted execution boundary. Before signing, the enclave checks that the request comes from an authorized requester — specifically, that the requester holds `WALLET_ROLE` on the target market's `EXManager`. That role is held by the per-market **enclaver** address chosen at deploy. **For the initial deployer cohort**, the enclaver is pinned to a Kinetiq-managed address and the request flow is a simple JSON handshake: the deployer submits a small JSON payload describing the API wallet they want bound to the market, the enclave returns the EIP712-signed `walletSignedData`, and the operator submits it on-chain. Subsequent rotations via `updateWallet` follow the same path. **Once Kinetiq exposes a deployer-facing API / UI for enclave interactions**, the picture shifts: deployers set the enclaver to a wallet or service they control, and make wallet-payload requests directly through that interface. The enclave still performs the same on-chain `WALLET_ROLE` authentication and the same EIP712 signing — only the requester changes from "Kinetiq protocol team via JSON exchange" to "deployer's own enclaver-bound client." The on-chain verification (signature, market binding, monotonic nonce) is identical in both modes; the JSON handshake today is an onboarding-velocity choice rather than a trust mode the protocol depends on. ### Ongoing operations While the market is LIVE, the operator's recurring on-chain surface is small. The main call is `updateWallet(walletSignedData)` — rotating the HyperCore API wallet at any time using the same Kinetiq-signed payload path as `launch` (allowed in LIVE and WOUND_DOWN). Gas top-ups for HyperCore HIP-3 auctions are paid by the deployer's sub deployer addresses on the HyperCore side rather than from EVM, so no operator EVM call is needed for that. The admin can rotate the operator, admin, or enclaver at any time via `EXFactory.transferOperator` / `transferAdmin` / `transferEnclaver`. Each is an atomic revoke-and-grant on `EXManager`; the previous holder loses the role in the same transaction. Tier upgrades to higher reserve floors flow through a queue-then-confirm pattern, time-locked by `globalConfig.tierUpgradeDelay`. These are enabled by Kinetiq when higher tiers are introduced. ### Voluntary unwind The operator initiates a wind-down with `setUnwindPhase(true)`. This snapshots `unwindEligibleAt = block.timestamp + globalConfig.unwindDelay()` and immediately freezes the operator's lifecycle calls (`fund`, `launch`, tier flow, operator-relay `updateWallet`). Deposits and withdrawals stay open so depositors can exit. The operator can reverse course with `setUnwindPhase(false)` before `unwindEligibleAt` elapses. After the delay (1 day on testnet/mainnet-dryrun, 7 days on mainnet), the operator calls `unwind()` to finalize. The `opBond` shares sweep back to the deployer and the market enters WOUND_DOWN, a terminal phase where withdrawals and confirms remain available for exit liquidity. One important caveat for LIVE-phase unwinds. From FUNDING or LAUNCHING, `unwind()` finalizes after `unwindDelay` alone. From LIVE, it additionally requires Kinetiq's HC-side attestation that the on-HC perp dex has begun unwinding, **and** the elapsed time since the market's HyperCore link (when Kinetiq attested the perp deploy was live) must satisfy `minLinkAgeForUnwind`. That cliff is 1 day on testnet/mainnet-dryrun and **183 days on mainnet**. Operators planning a mainnet wind-down should account for it. > **Diagram — Voluntary unwind, two finality paths.** Pre-LIVE phases finalize on `unwindDelay` alone; a LIVE-phase unwind adds the HC attestation and the `minLinkAgeForUnwind` cliff (red). ## Fees and the deployer treasury HIP-3 trading fees on the per-market HC perp dex flow through a three-way split. Hyperliquid takes 50% directly at the protocol level; the remaining 50% is the DEX share. Kinetiq takes a protocol fee from the DEX share (initially 10% — so 5% of total trading fees). The post-protocol-fee remainder then splits between the per-market buyback loop and the deployer's direct revenue, with `buybackBps` as the dial: - **Buyback share** (`buybackBps` of the remainder) routes to the per-market buyback wallet, which buys HYPE on HC spot and compounds it back into the market reserve via a per-market throttle contract that smooths the flow. Higher buyback means more exLST appreciation, including for your own bonded position. - **Deployer share** (the rest) routes to your `deployerTreasury` on HyperCore spot as direct, immediately-claimable revenue. A worked example at the typical `buybackBps = 1000` (10%): from 100% of trading fees, Hyperliquid receives 50, Kinetiq's protocol fee takes 5, the buyback loop receives 4.5, and the deployer treasury receives 40.5. Tuning `buybackBps` upward shifts more of that 45% post-protocol-fee remainder toward the buyback loop; tuning it down shifts more to direct treasury revenue. > **Diagram — Fee split (worked example at** `buybackBps = 1000`**).** Percentages shown as share of total trading fees. ## Slashing risk The per-market reserve — your bonded `opBond` plus every depositor's stake — is delegated to your chosen Hyperliquid validator and exposed to Hyperliquid's HIP-3 deployer slashing mechanism. The risk is real and structural; deployers should communicate it clearly to depositors when promoting the market. ### HIP-3 deployer slashing Slashing triggers, thresholds, and the validator-vote process are specified in the [HIP-3 slashing documentation](https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals#slashing). Hyperliquid notes that the expected mainnet outcome is that slashing never triggers, but the protocol-level mechanism is real and applies for the full life of the bonded delegation, including the unstaking queue period. ### Pro-rata impact on exLST holders Within the Kinetiq Launch HyperEVM structure, a slash on the bonded reserve is absorbed **pro-rata across all exLST holders**, including the deployer's own bonded position. There is no separate deployer protection — alignment between deployer and depositors is structural. The protocol's confirm step is slashing-aware: when a withdrawal confirms, it pays out the smaller of the queue-time HYPE amount and the recomputed amount at confirm time. Withdrawals never receive more than was earned, but they can receive less if the reserve was slashed in the interim. > **Diagram — Slashing-aware exit.** A slash is absorbed pro-rata, and the confirm step pays the smaller of queue-time and confirm-time amounts. ### Force unwind in extreme events In the event of an extreme slashing event, **exLST holders in coordination with Kinetiq can force-unwind the perp dex**, allowing remaining capital to exit through the slashing-aware withdrawal path. This is an emergency escape hatch, not the normal voluntary-unwind flow — the operator-driven `setUnwindPhase` → `unwind` path described above remains the primary wind-down mechanism for non-emergency exits. ## Pre-flight rehearsal Before committing real capital, Kinetiq provides a fork-based rehearsal tool that exercises the full lifecycle end to end — deploy, activate, bond, deposit, withdraw, reward distribution, and the confirm flow — against a live network fork without any on-chain effect. Deployers run this with their planned deploy address as the simulated sender; the rehearsal reads the address's live balance on the fork and logs whether it would have had enough HYPE and activation token for a real deploy, then continues via test-environment top-ups so the full sequence runs regardless. Running the rehearsal before a mainnet deploy is strongly recommended. Mainnet's 1000 HYPE bond floor is non-trivial, the per-market suite requires HyperEVM big blocks to be pre-enabled, and the activation token bridge is one-way. A successful rehearsal confirms all of the above will work for your address before you spend gas on the real path. ## Onboarding and support Kinetiq operates the enclave, the initial HyperCore `perpDeploy` submissions, and ongoing keeper services (reward distribution, withdrawal queue processing) for every Launch market. The deployer and operator stay in control of role transfers, lifecycle decisions, treasury, and the day-to-day HyperCore operations through their authorized sub deployer addresses. The initial `registerAsset` for a new market is handled by Kinetiq during onboarding; subsequent tickers on the same dex are deployer-driven through the sub deployer addresses you control. To begin onboarding, contact the Kinetiq team at [`contact@kinetiq.xyz`](mailto:contact@kinetiq.xyz) with the rough shape of your market — collateral token, intended tier, validator preference, and any custom sub deployer needs. The team responds with the deployer config JSON template and walks through the deploy sequence on testnet first, then mainnet-dryrun, then production mainnet. --- # FAQ ## General questions ### Q: What is Kinetiq? A: Kinetiq is a protocol built on Hyperliquid that allows users to stake HYPE and receive kHYPE — a liquid staking token that earns rewards from validator performance while remaining usable in DeFi. ### Q: What is kHYPE? A: kHYPE is a liquid staking token for HYPE. It accrues yield passively as validators write data to the Hyperliquid blockchain. It’s usable across DeFi and grows in value over time. ### Q: How is this different from staking HYPE directly? A: Staking through Kinetiq gives you a liquid, reward-accruing token (kHYPE). You don’t need to pick validators or manage delegation. Your kHYPE grows in value and can be traded or used in DeFi. ### Q: How does kHYPE accrue rewards? A: kHYPE increases in value relative to HYPE as rewards accrue. The amount of kHYPE in your wallet remains constant — but its redemption value in HYPE grows. ### Q: Why is the exchange rate not 1:1? A: As time passes, the kHYPE:HYPE exchange rate increases due to validator rewards. For example, 1 kHYPE might be worth 1.05 HYPE after a year. ### Q: How does kHYPE compare to rebasing tokens? A: Unlike rebasing tokens (which increase in quantity), kHYPE is a reward-accrual model where value increases via exchange rate, keeping the token count stable and DeFi-compatible. ## Staking & rewards ### Q: How long does it take to start earning? A: Immediately. As soon as you stake HYPE, your kHYPE begins accruing rewards. ### Q: Do I need to claim rewards? A: No. Rewards auto-compound into the kHYPE:HYPE exchange rate. No action needed. ### Q: Is there a minimum staking amount? A: Yes, a minimum of 5 HYPE. This is due to some technical implementations. For amounts <5 units we suggest conducting a swap from HYPE to kHYPE via supported DEXs. ### Q: Can I stake more later? A: Yes! You can stake additional HYPE at any time and receive kHYPE at the current exchange rate. ### Q: What’s the current APY? A: APY varies based on validator performance and amount of stake. Returns are visible via the kHYPE:HYPE exchange rate and the protocol dashboard. ### Q: I just want passive yield. What’s the easiest option? A: Check out the Kinetiq Earn Vault. It automatically deploys your kHYPE into high-yield strategies with no management required. ### Q: I prefer to manage my own DeFi strategies. Can I do that? A: Yes. You can use kHYPE directly in supported DeFi integrations like lending markets, CDP platforms, and yield trading protocols. ### Q: Can I switch between Earn Vault and DIY? A: Absolutely. You can withdraw from the Earn Vault at any time and redeploy your kHYPE manually—or vice versa. ### Q: Which option earns more yield? A: It depends on market conditions and your strategy. The Earn Vault is optimized for convenience and steady returns, while DIY gives you more control to potentially chase higher yields. ## Withdrawals & timing ### Q: How do I unstake my kHYPE? A: You can: 1. **Unstake:** Initiate unstaking, wait approximately 8–9 days, then confirm the withdrawal. 2. **Swap instantly:** Trade kHYPE on a supported DEX for immediate liquidity. ### Q: Is there a delay before I can withdraw? A: Unstaking has an approximately 8–9 day unstaking period. ### Q: Can I cancel an unstake? A: No. Once unstaking has been initiated, it cannot be cancelled by the user. ### Q: Does kHYPE earn rewards during the unstaking period? A: No. kHYPE stops earning rewards once unstaking is initiated. ## Safety & security ### Q: Is Kinetiq secure? A: Yes. All contracts are: - Audited by Spearbit, Zenith, Pashov, and Code4rena. - Verified on-chain. - Protected by multi-sig administrative access controls. - Emergency pause functionality - Security is of the highest priority. Any future upgrades will be thoroughly reviewed. - Uses [Hypernative](https://x.com/HypernativeLabs) for all event monitoring ### Q: Can validators be slashed? A: Currently, Hyperliquid has no slashing — however it is entirely possible that it is enforced in the future and therefore must be communicated as a future risk in the event that Kinetiq allocates stake to validators that due suffer a slashing event by not abiding by the rules of the network. For more information as to how StakeHub mitigates this risk, visit [StakeHub](/docs/stakehub) ### Q: Is there insurance or coverage? A: While not explicitly insured, risk mitigation is achieved via audits, diversification, emergency tools, and conservative strategies. While today there are no exogenous protocols that offer insurance coverage on Kinetiq / kHYPE risks, perhaps in the future there may be. ### Q: Is kHYPE safe for DeFi use? A: Yes — it’s a standard ERC-20 token. Use only with trusted DeFi protocols. ## Technical details ### Q: How is the exchange rate calculated? A: Validator rewards flow into the protocol and increase the exchange rate between kHYPE and HYPE. This rate updates daily based on actual performance. ### Q: What is StakeHub? A: StakeHub is Kinetiq’s automated validator scoring and delegation engine. It scores validators and rebalances stake continuously. ### Q: Can I choose my own validators? A: No — StakeHub handles validator selection to maximize performance and safety. ### Q: What chain is Kinetiq on? A: Kinetiq is native to Hyperliquid, using its L1 and HyperEVM environments. ### Q: How often does StakeHub rebalance? A: Continuously — triggered by validator performance shifts, slashing risk, or new high-performing entrants. ## Troubleshooting ### Q: I don’t see my kHYPE in my wallet. A: Add it manually using this address: `0xfD739d4e423301CE9385c1fb8850539D657C296D` ### Q: My transaction failed. A: Check: - Gas fees - Network congestion - Wallet connection - Slippage settings - Hard refresh your browser ### Q: I can’t confirm my withdrawal. A: Make sure: - The full withdrawal delay has passed - You’re using the correct withdrawal ID - You’re on the correct network - Hard refresh your browser ### Q: Where can I get help? A: Try these: - [Discord](https://discord.kinetiq.xyz/) - [Docs](/docs) ## Integration & developer questions ### Q: Can I build on Kinetiq? A: Yes — all contracts are verified and available for integration. ### Q: Are APIs available? A: Standard blockchain RPCs apply. Dedicated APIs are in development. ### Q: Can institutions use Kinetiq? A: Yes. Contact the team for institutional onboarding. ### Q: Are there rate limits? A: None at the protocol level. Standard blockchain limits may apply. ## kPoints questions ### Q: When are kPoints distributed? A: Snapshots are taken every Tuesday. Distributions occur every Thursday. ### Q: How many kPoints are distributed? A: 800,000 kPoints are distributed weekly. ### Q: Can you tell me the exact formula? A: No. The kPoints formula is private and will not be disclosed under any circumstances. Continued questioning about the formula in Discord may result in muting, timeouts, or bans. ### Q: Where can I learn more? A: Visit the official [kPoints documentation](/docs/kpoints).