Launch App

Brila Token: Community Questions Answered

Brila Token: Community Questions Answered

What is BRLA?

What is BRLA, where does it live, and what wallets and gas token does it use?

BRLA is a new token launching natively on HyperEVM — Hyperliquid's Ethereum-compatible execution environment. HyperEVM is not a separate blockchain. It runs inside Hyperliquid L1, secured by the same consensus and sharing the same state as Hyperliquid's trading engine. Smart contracts, order books, and liquidity all operate on one unified chain. BRLA is a standard ERC-20 on HyperEVM, which means familiar tooling like MetaMask, and other standard wallets should work out of the box. Gas is paid in HYPE.

How does launch liquidity work?

How does BRLA launch liquidity work across HyperCore, HIP-1, and HIP-2?

BRLA launches with a native spot order book on HyperCore. HyperCore is Hyperliquid's trading engine. The launch is through a token standard called HIP-1. There is no separate DEX deployment. The order book is built into the protocol.

On top of that, a mechanism called HIP-2 (Hyperliquidity) provides automated, protocol-level market making from day one. It places buy and sell orders at tight 0.3% intervals, updating every few seconds, with no human operators required. The liquidity seeded into HIP-2 is permanently locked — it cannot be removed. The result: BRLA has a continuously maintained spread on a live order book at launch, without depending on external liquidity providers.

How does the TRU swap portal work?

How do TRU token holders access BRLA, how much supply is allocated, and when is the swap unlocked?

TRU token holders access BRLA through a dedicated swap portal. 35% of BRLA's total supply of one billion tokens — 350 million BRLA — is allocated specifically to TRU swap participants. If you hold TRU, the portal is your mechanism to claim your allocation. The swap is 100% unlocked on April 30, 2026 — no cliff, no vesting.

The remaining supply covers the Foundation, team, advisors, market makers, and an unminted reserve, all with their own terms. TRU swappers receive the largest single allocation in the entire distribution.

How are HyperEVM and HyperCore connected?

Is HyperEVM connected to HyperCore through a bridge, or do both environments share unified state?

HyperEVM is an EVM execution environment (Cancun hardfork, no blob support, EIP-1559 active) that runs as a first-class component of Hyperliquid L1 block production under HyperBFT consensus. It does not communicate with HyperCore via cross-chain message passing. HyperCore state and HyperEVM state share the same root. Meaning, state transitions for both are committed atomically in each L1block.

Block architecture is dual-type: small blocks produce every ~1 second at a 2M gas limit, suited for order operations and fast confirmations; large blocks produce approximately every minute at 30M gas, suited for contract deployment and compute-heavy operations. Chain ID 999 on mainnet (998 testnet). RPC: https://rpc.hyperliquid.xyz/evm.

Fee mechanics deviate from standard EVM: both base fees and priority fees are burned to the zero address's EVM balance. Validators running HyperBFT do not capture tips — there is no MEV extraction surface via fee priority as it exists on Ethereum.

HyperEVM exposes read precompiles for live HyperCore order book state — contracts can read mid prices, best bid/ask, and oracle prices without an external oracle dependency. Bidirectional contract-to-HyperCore interaction is available via CoreWriter system contracts, enabling smart contracts to execute market orders, manage stake, and handle validator delegation directly from EVM execution context.

How is BRLA deployed with HIP-1?

How does HIP-1 token deployment work, what is the spot slot auction, and how is the ERC-20 linked to HyperCore?

BRLA is deployed as a HIP-1 native token on HyperCore, linked to an ERC-20 contract on HyperEVM. HIP-1 deployment requires winning a Dutch auction for a spot slot. Auctions run on a 31-hour cycle. The starting price is 500 HYPE or 2x the last winning bid if the previous auction cleared — whichever is higher — and declines linearly to 500 HYPE over the cycle. Payment is denominated in HYPE (switched from USDC on May 22, 2025).

The ERC-20 linking operation: after deploying the ERC-20 contract on HyperEVM, the deployer executes a requestEvmContract action on HyperCore proposing the contract address as the linked EVM token. The full token supply is allocated to a system address formatted as 0x20 followed by the token index in big-endian encoding. This system address is the atomic settlement layer between both representations — it is not a smart contract and has no admin keys.

Transfer mechanics are asymmetric by design:

  • HyperCore → HyperEVM: queued to the next EVM block
  • HyperEVM → HyperCore: executes in the same L1 block, costs ~200k gas, non-rounded amounts due to decimal mismatches are burned rather than returned

maxSupply is set at HIP-1 deployment and is protocol-enforced immutable — it can only decrease through fees or burns. There is no upgrade path or admin override.

How does HIP-2 seed liquidity?

How does HIP-2 maintain protocol-level liquidity, what parameters control it, and can seeded liquidity be removed?

HIP-2 is not a smart contract AMM. It runs in Hyperliquid's block transition logic as part of consensus — there are no keeper transactions, no EOA calls, no front-runnable update windows. It cannot be griefed.

Configuration is set at deployment via five parameters:

ParameterDescription
spotThe HIP-1 token being seeded
startPxFloor price in USDC
nOrdersTotal number of order levels on each side
orderSzToken quantity per order level
nSeededLevelsNumber of initial buy-side levels pre-funded in USDC

Order placement is recursive: each level is priced 0.3% above the previous, creating a uniform spread ladder on both sides of the book. The system rebalances when block time is at least 3 seconds since the previous update block — it is block-cadence driven, not timer-driven.

Seeded USDC and tokens are sent to a system address and are irrecoverable by any party, including the deployer. This is intentional: it eliminates the liquidity withdrawal vector common to AMM-based launches and guarantees a protocol-enforced bid floor as long as the system address retains balance on both sides. HIP-2 coexists on the same order book with independent market makers placing their own orders — it sets a baseline, not a ceiling.

The practical output: a 0.3% bid-ask spread maintained every ~3 seconds from block one, on a central limit order book, with no operational dependency on external actors.

Sources