HAI Infrastructure Update

11d ago•

bullish:

bearish:

This post follows our main statement detailing the root cause and technical breakdown of the recent exploit. If you missed it, we recommend starting here — it covers what happened, how the breach was contained, and why no client funds or core infrastructure were impacted.

This post is about what’s next for $HAI, and how we’re restoring order, trust, and value — step by step.

TL;DR:

The incident was caused by a legacy private key tied to an old bridge.
$HAI will be restarted via a secure LayerZero-based OFT token for EVM-compatible chains.
$HAI on VeChain will remain on its current contract, as it wasn’t affected. All CEXs and DEXs on VeChain will continue to use the same token.
All legitimate token holders before the incident will be restored 1:1 based on a pre-incident snapshot.
BSC<>VeChain, BSC<>ETH & ETH<>VeChain Native Bridges are down and will remain down. Infrastructure is being rebuilt — properly.
New contracts = safer design. Multi-sig, pausable, blacklist, no custom bridges.
Manual claim on BSC/ETH via hAI App. 6-month window.
A portion of $HAI is locked on Base due to old mechanics. We’re working on a fix and will update soon.

What We’re Doing — and Why

We’re not patching the system. We’re rebooting it — clean, secure, and aligned with the vision we already announced: turning $HAI into a fully tokenized asset, with real business exposure.

This migration isn’t about fixing a mistake. It’s about removing every weak point from the previous outdated design, and giving $HAI a fresh foundation for long-term growth.

What’s Coming — Step by Step

Snapshot Taken
After the initial investigation, the last pre-incident blocks are 51800329 and 22747526 on BSC and ETH, respectively. The last pre-attack block timestamps are Jun-20–2025 06:40:00 PM +UTC and Jun-20–2025 06:39:59 PM +UTC.
We will also include the $HAI tokens that users had locked in Flash Pools (HackPot) on Base, as well as the SafeSwap bridge transactions to Base before it was shut down.
Deploy New OFT Token
Issue a fresh HAI token on Ethereum, BSC, and Base (Coinbase’s Layer-2), using LayerZero’s OFT standard to unify supply across chains. The new token uses the same name/symbol, total supply, and tokenomics as before, but starts from the snapshot distribution.
Distribution
Deploy a claim contract on Base that holds the total amount of HAI tokens from the snapshot. All eligible addresses and their token amounts are encoded in a Merkle tree (calculated from the snapshot), read more here. Users will interact with the hAI App to claim their tokens: they submit a transaction with a Merkle proof of inclusion to withdraw their allocated HAI. A fixed claim of 6 months will be set; after this deadline, any unclaimed tokens will be withdrawn by the contract owner. The contract owner will be a multi-signature wallet for security (addressing the previous single-key failure).
SafeSwap bridge migration
The only non-LZ bridge that will be left is SafeSwap with only one route — Vechain <> Base. Users can then bridge their tokens from Base anywhere else via LayerZero (i.e. built-in mechanics to the OFT token).
Security Hardening
The new contract will be upgradeable and secure. Key features include: a multi-signature “Ownable” governance structure, a Pausable emergency brake, an address blacklist for bad actors, and strict access controls. No custom bridges will be written; cross-chain transfers use LayerZero’s native messaging. Upgrades will be carefully controlled via a multi-sig policy.
Best-Practice Deployment
Leverage OpenZeppelin’s upgradeable library and proxy pattern to allow future fixes. Thorough testing (including pause/unpause and blacklist tests) will be done. The team will coordinate with LayerZero to configure Verifier networks (DVNs) and executors for secure cross-chain messaging.
Comprehensive Extractor integration
Leverage Instructor’s watchers to ensure that all potentially vulnerable areas of the contracts are covered (admin role changes, transfers to suspicious or blacklisted addresses, minting events, emergency changes or governance interactions)
Post-Migration Liquidity Pool Initialization
After the successful deployment and distribution of the new HAI token, all existing liquidity pools on BSC, Ethereum, and Base that use the old HAI token will be shut down completely.

⚠️ Note on Base

Due to long-term locking mechanics, a portion of current $HAI supply remains in a Virtuals pool (https://app.virtuals.io/virtuals/18632) on Base. This creates complications for full migration. We’re actively working on a solution or viable option to address this. An update on this part will follow shortly.

Omnichain Fungible Token (OFT) Standard

The new HAI token will be implemented as a LayerZero Omnichain Fungible Token (OFT). The OFT standard lets an ERC-20 token exist on multiple chains with a unified supply. Under this model, when a user sends HAI from chain A to chain B, the token is burned on A and minted on B (read more here and here). This ensures the total cross-chain supply remains constant and prevents double-spends or inflation. For example, sending 100 HAI from Ethereum to BSC will call _debit on the Ethereum contract (burning 100 HAI) and _credit on the BSC contract (minting 100 HAI).

LayerZero’s OFT is implemented by having each chain’s HAI contract inherit from OFT.sol, which itself extends LayerZero’s OApp (omnichain application) plus a standard ERC-20. This provides both the usual ERC-20 functions and cross-chain message handling. Internally, the OFT contract emits a cross-chain message via LayerZero’s endpoint; decentralized verifiers (LayerZero’s DVNs) confirm the message, and then a transaction on the destination chain executes the mint. All chains use LayerZero’s official protocol, avoiding any custom bridging code. Notably, we will configure the OFT as a “native OFT” rather than using an adapter escrow: HAI tokens are burned and minted directly on each chain. This makes HAI itself the bridged asset, instead of locking it behind an escrow contract.

In summary, the HAI token architecture will follow LayerZero’s recommended OFT pattern:

Unified Supply: Only one total supply across all chains. Tokens move by burn/mint.
Cross-Chain Messaging: Uses LayerZero endpoints and DVNs to relay transfers.
No custom bridge contracts are needed.
Mint/Burn Logic: _debit() will burn on send, _credit() will mint on receive. The initial supply of HAI will be minted on Base and distributed to eligible users using the distributor contract via the hAI App.
Chain Configuration: The contract owner can set which Verifier networks (DVNs) and executors to use on each chain.We will configure at least the default LayerZero DVNs for security, and consider adding more verifiers for higher trust.

Using the OFT standard means HAI on Ethereum, BSC, and Base will each be the same token in a logical sense, with balances flowing via messages. This simplifies future expansion: to support a new chain (e.g. Arbitrum), the team just deploys the same OFT contract on that chain and configures its LayerZero endpoint, rather than designing a new bridging solution.

Upgradeable Contract Design

Given the need for future fixes and governance changes, the HAI contracts will be upgradeable proxies rather than immutable deployments. Following OpenZeppelin’s guidelines, we will deploy a proxy (transparent or UUPS) pointing to an implementation contract that contains the logic (read more here and here). This allows future upgrades of functionality.
Key points for the upgradeable design:

Initializers Instead of Constructors: As required for proxies, the HAI contract logic will have no constructor. Instead, we’ll implement an initialize() function with the initializer modifier, useful link. This function will set the token’s name, symbol, total supply, and any initial state. Using OpenZeppelin’s Initializable ensures it can only be called once. For example, __OFT_init(“Hacken DAO”, “HAI”) would set up the ERC-20 name/symbol. All parent initializers (e.g. ERC20Upgradeable, OwnableUpgradeable, etc.) must be called within this function.
Upgradeable Libraries: We will import from @openzeppelin/contracts-upgradeable (ERC20Upgradeable, OwnableUpgradeable, PausableUpgradeable, etc.) to ensure the code is compatible with proxy deployment. Normal OZ contracts (with constructors) cannot be used.
Disable Implementation Initialization: The implementation contract itself will call _disableInitializers() in its constructor to prevent it from being initialized or taken over. This is a standard best practice to lock the logic contract.
Ownable/Multi-Sig Ownership: We will make the proxy’s “owner” a multi-signature wallet rather than an EOA. Although we’ll use the Ownable2Step pattern for access control, the actual owner key will be a safe with M-of-N signers. This prevents a single compromised key from taking over upgrades or pausing the contract. As explained in guidance, multi-sig “requires multiple signatures for transactions, providing security against lost or compromised keys” (read more here) and avoids a single point of failure.
Proxy Deployment: We may use deterministic deployment (CREATE2) if we choose to align addresses across chains, but it’s not strictly necessary. On each chain we’ll deploy an upgradeable proxy pointing to the HAI logic, and then call initialize with the new total supply and initial distribution parameters.

Important note — the total supply of the token, along with its name, symbol and decimals will not be upgradeable or changeable in any way.

Security Features

The new HAI contract will include multiple built-in protections to prevent a repeat exploit and allow emergency response:

Pausable: Using OpenZeppelin’s Pausable module, the owner can pause all token transfers (except perhaps whitelist functions) in an emergency, read more here. This emergency brake means that if a new vulnerability is detected, the team can freeze token movement instantly. For example, transfer and transferFrom will have the whenNotPaused modifier. This follows established practice: tokens like USDC are pausable, allowing maintenance during exploits, more info here.
Blacklist: The contract will maintain a blacklist (mapping of addresses) that prevents certain addresses from transacting, read more here. In practice, the contract’s transfer and transferFrom functions check require(!isBlacklisted[msg.sender]). The owner (multi-sig) can add or remove addresses. This lets us block known malicious actors or sanctioned wallets, more info.
For instance, if an attacker address tries to re-enter the system, it can be immediately blacklisted.
Ownable (Multi-Sig Governance): All privileged functions (pausing, blacklisting, upgrading) will require the contract owner. We will set the owner to be a secure multi-signature wallet, read more here. This means multiple key holders must agree to upgrades or emergency actions, removing single-key risk. Multi-sig wallets are “commonly used as wallets” to avoid single points of failure. In other words, instead of one private key controlling HAI upgrades, M of N admins must sign transactions.
No Custom Bridges: The token will only use LayerZero’s messaging for cross-chain transfers. We will not implement any custom bridging logic, unlike older tokens that wrote their own bridge contracts. By relying on LayerZero’s battle-tested protocol, we inherit its security model (validator set, retries, etc.). Practically, this means users call a function like sendFrom() in the OFT contract, and we let LayerZero handle the rest. This avoids introducing new bugs in a custom bridge.
Safe Libraries: We will use OpenZeppelin’s libraries for all standard functionality (ERC20, SafeMath if needed, etc.). For example, if we ever need to transfer underlying tokens (in an adapter), we would use SafeERC20. Additionally, careful attention will be paid to any non-standard behavior. The OZ security guidance notes that integrating tokens with unusual behavior (fee-on-transfer, hooks, etc.) requires extra care, read more here and here.
Testing and Audits: We will write extensive tests for pause/unpause and blacklist scenarios. Only the owner should be able to pause or blacklist; paused state should block transfers; blacklisted addresses should be blocked.
We will also simulate the previous exploit: for example, test that only the correct privileged accounts can mint or that revoke-minter functions work. We will carry out a comprehensive in-house audit that will verify that these controls cannot be bypassed.

By combining these features, the risk of a single key compromise is greatly reduced. If an admin key is lost, we can pause the contract and/or upgrade to replace it. If a malicious user is detected, they can be blacklisted. Pausable contracts and blacklists are “your first line of defense” in high-stakes scenarios.

Cross-Chain Operations and Best Practices

Decentralized Verifier Network (DVN) Configuration: In LayerZero V2, each OFT can customize which Verifiers validate cross-chain messages. By default, LayerZero uses a multisig (e.g. “LayerZero Multisig 3/5”) as its verifier. For extra security, we may add additional verifiers (e.g. community-run endpoints) so that even if one fails, others can attest. We will set a high threshold of confirmations before minting on the destination. This reduces censorship and exploits risk.
Gas Management: The cross-chain executor (LayerZero relayer) pays gas on the destination chain. We will allow the payer to be either the sender or the contract owner, depending on use cases. For user transfers, typically the user includes destination gas.
Future Chain Additions: If we later add HAI on a new chain, we simply deploy the OFT there and repeat the setTrustedRemote and config steps. Because OFT is designed to be “natively multichain”, adding a chain does not require a new bridge logic.
Monitoring and Upgrades: The owner (multi-sig) will keep an eye on LayerZero announcements for any required endpoint changes or critical fixes. If a vulnerability is found post-deployment, the upgradeable pattern allows us to patch by deploying a new implementation and pointing the proxy to it (subject to multi-sig approval).
No Further Minting: $HAI contracts will have no arbitrary mint function available (except via LZ bridge flows). We will remove or disable any “mint” function that is not part of the OFT interface to prevent future inflation. Only cross-chain sends will create new tokens on a chain (which exactly offset burns).

Testing and Quality Assurance

Before launch, we will conduct extensive testing (unit tests and integration tests) for all critical features. In particular:

Test pause/unpause: Ensure transfers revert when paused, and succeed again after unpause, more info here.
Test blacklist: Ensure a blacklisted address cannot send/receive, and after unblacklist normal function resumes.
Test bridge transfers: Simulate LayerZero messages (can use mocks or testnet) to ensure tokens move correctly.
Test upgrades: Use Hardhat Upgrades to simulate an upgrade, verifying storage is preserved.
Check all non-critical fallback behaviors (e.g. sending to the zero address should fail as usual).
Test distribution: Test the manual claims to reassure that it works as expected.