Truefi Truefi governance separates BRLA coordination from contract execution
Truefi governance distinguishes BRLA coordination under Brila from the authority to execute protocol transactions. The transition plan assigned capital allocation and treasury strategy to a Panama-based structure, with separate provisions for temporary contract administration. BRLA ownership grants no claim on protocol assets or revenue.
Who decides after TRU voting ends?
Brila's Panama-based structure was the designated steward for capital allocation and treasury strategy in TFIP-41, published March 5, 2026. That proposal connected TRU governance's sunset to completion of the migration. It assigned BRLA a governance and coordination role within the successor ecosystem, while leaving detailed voting mechanics to a separate framework.
BRLA launched on April 30, 2026. The April 2026 transition announcement said TRU would retain tradability while losing its project utility. That separates the legacy token from the successor governance instrument. The Brila Team's April 27, 2026 access Q&A said a multisignature wallet would handle admin and upgrade rights after launch. Developers were to transfer deployer and admin rights to that wallet.
Discussion, approval, and execution describe different stages of a decision. A forum response expresses a view. A binding vote applies its own eligibility and approval rules. A successfully executed transaction changes contract state.
BRLA's ERC-20 representation lives on HyperEVM. Legacy administrative contracts can sit on Ethereum mainnet. Token ownership in the first environment does not establish authority over contracts in the second.
Temporary authority over legacy contracts
TFIP-42, published March 26, 2026, proposed transferring the legacy Timelock's administrative roles to an Ethereum mainnet Gnosis Safe. The specified wallet used a 4-of-7 signature threshold. That means four authorized signer approvals, not four BRLA holders or four forum votes.
The proposal covered vault factories and legacy contracts under the Timelock's control. It called for transferring roles, removing the Timelock's old privileges, and confirming the changed permissions onchain. Its reversal conditions included BRLA going live on HyperEVM and deployment and auditing of cross-chain governance, followed by a new governance proposal. A token launch alone did not meet that whole condition. The publication describes requested changes and does not confirm their execution.
BRLA allocations and the voting denominator
BRLA's launch allocation gives a denominator for comparing token categories, without establishing how many votes any category can cast. The launch distribution reserved 350,000,000 BRLA, or 35% of the 1,000,000,000-token allocation, for TRU swap participants. This figure counts units of the ecosystem token. It is not a percentage of treasury assets, protocol revenue, or votes in a particular proposal. The March 19, 2026 allocation clarification also described 27% as an unminted reserve, subject to future governance decisions. That reserve amounts to 270,000,000 BRLA within the allocation. Allocation size, token availability, and voting eligibility answer separate questions.
Treasury discretion and token-holder rights
Brila's treasury model gives governance discretion over ecosystem spending without granting holders a personal right to redeem the treasury. TFIP-41 directed protocol revenues to the Foundation treasury and allowed governance to deploy them. Its listed uses included grants, liquidity initiatives, partnerships, and other strategic treasury operations. Those are decisions about pooled resources, without an automatic distribution owed to BRLA holders. The reconstitution terms give BRLA no ownership interest, asset claim, or entitlement to protocol revenue. The operating businesses include credit vaults, Cyan's NFT finance, and Elara's treasury management. Revenue from those activities does not turn a governance token into a lender's vault share.
Does a governance decision control every credit vault?
A governance motion does not automatically change every vault's operating rules. Under the documented manager-onboarding model, governance approves a manager and adds the manager's address to the factory allowlist. The manager can then create a portfolio. The allowlisting step governs deployment permission; it does not demonstrate capital deployment or an individual borrower's repayment.
Portfolio managers configure lending arrangements and deploy capital within the vault's permissions. Deposit, withdrawal, and transfer controllers apply separate operating rules. Some portfolio parameters are fixed at creation; others allow changes. A governance proposal's economic aim therefore needs to match the specific action that an authorized contract can perform.
A treasury request before transaction authorization
In this hypothetical case, a BRLA holder wants the treasury to fund an ecosystem activity. The request has no binding approval, and the holder has no administrative signing role. The holder wants to avoid transaction costs for an action that cannot authorize the payment. A forum response can explain the request and seek discussion. The holder submits that response, which records the request without changing treasury balances.
A payment needs authorization through the relevant treasury contract. With no binding approval or signing role in this case, the holder stops before signing a transaction. Execution fees would depend on the actual operation and network conditions. Paying a fee would not create the missing authorization.
Closed TRU claims and the limits of technical support
TRU claims ended in the second quarter of 2026, and the access portal is closed. Remaining TRU balances do not create a fresh participation window.
The Brila Team's May 11, 2026 portal update addressed users who completed participation but encountered technical claim or wallet compatibility problems. It committed development effort without promising an immediate fix. That commitment concerned affected participants; it did not reopen general access.
Legacy recoveries beside future treasury allocations
TFIP-41 left Archblock-administered loans and defaults with their existing recovery processes. It also preserved the forum for creditor communications and stated that the reconstitution did not erase historical obligations. That arrangement separates legacy creditor issues from Brila's planned capital allocation across its operating businesses.
A proposal to allocate future treasury funds addresses ecosystem operations. A creditor's recovery request addresses a particular loan obligation. They can appear in the same forum without granting the same powers or claims on the same assets.
Everyday questions about Truefi governance
How many wallets supported the reconstitution vote?
The March 22, 2026 governance update reported two participating wallets, both voting in favor of the reconstitution proposal. It reported no opposing votes. The count describes support among participating wallets; it does not measure support across all TRU holders. Wallet counts also do not establish how many individual people participated, because a person can control multiple addresses.
Why did locked TRU create a governance concern during migration?
TFIP-42 described a temporary gap in which locked TRU could not vote and BRLA governance was not yet deployed. The March 26, 2026 proposal warned that low participation could leave legacy administrative contracts exposed to governance attacks. The warning concerned that transition configuration, with legacy control still passing through the Timelock.
Which rules determine the threshold for a BRLA proposal?
The applicable BRLA governance framework determines any proposal threshold and quorum. TFIP-41 left detailed mechanics to a separate framework and did not specify numerical BRLA thresholds. Historical TRU voting settings therefore do not establish the requirements of a BRLA ballot. Token supply figures describe allocations; they cannot substitute for the eligibility and approval rules of an implemented voting system.
Can a multisignature administrator raise the native HIP-1 supply limit?
A multisignature wallet cannot override the native HIP-1 token standard's capped supply rule. HIP-1 sets the native maximum at token genesis. That limit concerns the HyperCore representation; it does not describe every administrative permission attached to related contracts. BRLA links a native HIP-1 token on HyperCore to an ERC-20 on HyperEVM, so each component retains its own scope.
Does an announced contributor vesting schedule prove that tokens are locked?
An announced vesting schedule does not establish that a contract enforces a lock. The Brila Team's April 27, 2026 access Q&A described vesting contracts as not yet created and intended onchain enforcement after minting. That dated statement records the launch plan. It does not establish the present lock status or voting eligibility of a particular contributor allocation.