> ## Content Index > Fetch the complete content index at: https://onchain-fx.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # How I would design a Brazilian power market on Hyperliquid - URL: https://onchain-fx.ghost.io/how-i-would-design-a-brazilian-power-market-on-hyperliquid/ - Published: 2026-09-17T08:59:28.000Z - Updated: 2026-09-17T14:49:16.000Z - Description: Listing the contract is the easy part. Building a market that companies trust enough to hedge real Brazilian power exposure is the product. - Author: Guilherme Bissoli - Tags: Market Infrastructure, Hyperliquid, Energy, Brazil, Derivatives, #lang-en Listing the contract is the easy part. Building a market that companies trust enough to hedge real exposure is the product. If I were trying to build a Brazilian power market on Hyperliquid, I would not begin with: PLD-PERP. I would begin with a much more boring question: What exactly are we asking two parties to exchange risk on? That is where the market begins. ## Start with one contract The first product should be deliberately narrow. Something like: PLD\_SECO\_DEC26 Cash-settled. No physical delivery. Reference: the arithmetic average of the selected hourly PLD observations for the Southeast/Central-West submarket during December 2026. Buyers and sellers trade the contract. They post collateral. Positions are marked. At expiry, the market settles financially against the benchmark. The specification has to define: the benchmark source; the submarket; the observation period; the relevant timezone; the treatment of missing observations; the treatment of republished data; the settlement timestamp; the final settlement formula; the benchmark-change fallback; the collateral currency; the conversion rule if benchmark and collateral use different currencies. The first real asset is not the smart contract. It is the rulebook. ## Why I would not start with a perpetual Perpetuals are native to crypto. Energy exposure is not. A generator does not usually want continuous exposure to Brazilian power. It wants to know the economic result for: November; December; Q1; next calendar year. That means the natural object is closer to a dated future or swap. So I would build: PLD\_SECO\_DEC26 then: PLD\_SECO\_JAN27 PLD\_SECO\_FEB27 PLD\_SECO\_Q1\_27 PLD\_SECO\_CAL27 The product becomes a curve. That is what real hedgers need. ## The benchmark must be boring The oracle design should be intentionally conservative. For the first contract, I would avoid any attempt to create an onchain synthetic PLD. Use the official published reference. The logic should look approximately like this: Source: CCEE Region: Southeast/Central-West Observation: hourly PLD Period: defined calendar month Final settlement: arithmetic average of all valid observations during the period Then define what happens when reality becomes messy. If CCEE republishes a number before final settlement, which version counts? If an observation is missing, do we wait? Use the prior published value? Exclude the hour? If methodology changes during the life of the contract, does the contract continue under the new methodology? Does a material methodology change trigger an adjustment event? Those decisions have to exist before the first position is opened. ## Oracle governance matters more than oracle technology A lot of crypto discussions treat the oracle as an API problem. It is not. It is a governance problem. Someone needs to answer: What data is authoritative? Who can submit it? Who can challenge it? How long does a challenge window last? When does a price become final? What happens if the source is unavailable? The technical architecture could be simple. Multiple independent submitters could read the official publication. The system could require agreement across several observations. The final settlement event could have a delay before becoming irreversible. But the hard part is not the code. It is agreeing on what constitutes truth. ## Collateral creates the next design decision The benchmark is in reais. Hyperliquid collateral is naturally dollar-based. That creates a second market inside the first one. A trader can be right about Brazilian electricity and still lose or gain because BRL/USD moved. There are several ways to deal with this. ### Option 1: settle the contract in USD Convert the final BRL/MWh benchmark into USD using a defined FX reference. Simple for global participants. But now the product contains explicit FX basis. ### Option 2: BRL-denominated P&L with dollar collateral The position is economically BRL-denominated, while collateral remains in dollars. That keeps the underlying exposure closer to local power risk but requires continuous FX conversion for margin. ### Option 3: use a BRL digital settlement asset Conceptually clean. Operationally and legally much more complicated. I would probably begin with option 1 or 2. The important point is that the FX rule must be written into the contract. It cannot be an operational afterthought. ## Margin should be designed for energy, not copied from crypto This is probably the most important design choice. Power is capable of moving violently. The model therefore needs to know something about the underlying market. I would begin with conservative leverage. Maybe very conservative. The goal of the first market should not be maximizing capital efficiency. It should be surviving. Margin needs to account for: historical PLD volatility; regulatory floor and cap structure; stress scenarios; FX movement if collateral is dollar-based; oracle update frequency; liquidity available for liquidation. A market can technically support high leverage. That does not mean it should. For an early power contract, the credibility of the system is more valuable than leverage. ## Real hedgers change the margin conversation A generator may have a natural short exposure to electricity prices. Economically, it is already hedged by the physical asset. But the trading system does not see the power plant. It only sees financial collateral. That means a perfectly sensible physical hedge can generate large margin calls. So a fully collateralized market solves one problem and creates another. It reduces bilateral credit risk. It increases liquidity demand. That is why the long-term architecture probably needs to think beyond stablecoin-only collateral. Possible future collateral could include: cash; stablecoins; tokenized government securities; high-quality receivables; other eligible financial assets. But I would not introduce that complexity into the first market. First, prove the price market. ## Liquidation has to assume there may be no buyer Crypto liquidation engines often assume another participant can absorb the position. Power markets may be thinner. That changes everything. Imagine a large participant needs to be liquidated during a violent move. If the market has little depth, selling the position may itself move the price enough to create further liquidations. So the liquidation architecture should include: position-size limits; conservative leverage; concentration limits; liquidation buffers; staged liquidation; possibly deployer or market-maker backstop mechanisms. The contract is only as strong as its behavior during the worst hour of the year. ## The hard part is market making Suppose we successfully deploy: PLD\_SECO\_DEC26. Nothing happens. There are no bids. There are no offers. There is no market. That is the real risk. A functioning market needs three groups. ### Hedgers Generators. Retailers. Traders. Large consumers. Batteries. Other participants with actual exposure. ### Market makers Entities willing to continuously quote both sides. They turn economic interest into executable liquidity. ### Risk capital Participants willing to take views without having physical exposure. Macro funds. Commodity traders. Quantitative funds. Crypto-native traders. Without hedgers, the market has no economic reason to exist. Without market makers, hedgers cannot trade efficiently. Without risk capital, market makers cannot recycle exposure. You need all three. ## The first liquidity program should be explicit I would not pretend liquidity appears organically. It needs to be designed. For the first contract, I would set clear market-making requirements: minimum quote size; maximum spread; minimum uptime; defined trading windows; inventory limits; fee rebates; possibly direct deployer incentives. The objective is not huge volume. The objective is creating a trustworthy two-sided market. Ten million dollars of real hedge volume with consistent quotes is more interesting than one billion dollars of wash volume. ## Funding is probably the wrong mental model Perpetual markets use funding to keep contract prices near spot. A dated PLD contract does not need to behave like that. It has an expiry and a final benchmark. Its price should reflect expectations about the settlement value. The relevant dynamics become closer to a futures curve. The basis between: current PLD; forward expectations; contract price becomes information. That is good. We should not automatically force every real-world market into perpetual mechanics just because crypto likes perpetuals. ## Settlement should be almost boring At the end of the contract: collect the approved observations; calculate the benchmark; apply the defined FX rule if needed; publish the final settlement price; allow a short challenge period; settle positions; close the market. Nothing clever. If final settlement is complicated, the contract specification is not finished. ## Then we add the curve Once one market works, expand carefully. December. January. February. Q1. Q2. Calendar year. Now market makers can quote spreads. Participants can trade relative value. The market starts producing a curve. And that curve may eventually become as important as the individual contract. Because a public, continuous curve is itself infrastructure. It tells: generators what the market thinks future power is worth; consumers what forward procurement costs; lenders something about projected revenues; batteries something about expected volatility; investors something about the future economics of the system. The financial market begins producing information for the physical system. ## Machines can eventually consume the curve This is where the infrastructure becomes particularly interesting. A battery management system could observe: spot price; forward curve; current charge; expected demand; collateral cost. Then make an economic decision. A data center could compare: power price; compute revenue; hedge price; curtailment economics. A generator could compare: forward sale; merchant exposure; financing cost. Markets become APIs. And physical infrastructure starts consuming them. ## What I would not put onchain This matters as much as the architecture itself. I would not put: physical dispatch authority; grid-security decisions; measurement that already has an authoritative regulated source; every contractual detail of a PPA; identity and compliance data; regulatory discretion into public smart contracts simply because it is technically possible. Some systems benefit from determinism. Others require institutions. The objective is not maximum decentralization. It is better market infrastructure. ## Regulation is part of the product design A market can be technically perfect and commercially irrelevant if the intended participants cannot legally use it. For Brazilian energy, the regulatory architecture needs to be considered from the beginning. Questions include: Is the instrument a derivative? Who can offer it? Who can access it? What jurisdiction is the venue in? How is collateral treated? How does stablecoin settlement interact with Brazilian virtual-asset and FX rules? Does the instrument create an exposure that needs local reporting? How does an institutional hedger account for it? These are not questions to solve after launch. They determine who the product is actually for. ## The real experiment I would measure success with a very small set of metrics. How much real physical exposure is being hedged? How tight is the spread? How deep is the book? How concentrated is open interest? How much collateral is required per unit of hedge? How often do liquidations occur? How closely does the contract converge to final settlement? How much of the volume comes from participants outside Brazil? If those numbers work, something important has happened. We would have separated Brazilian electricity risk from some of the infrastructure friction currently surrounding it. And that is a much larger result than putting a commodity ticker on a blockchain. ## The product is not the contract The contract is perhaps a few pages of specification and some code. The product is the ecosystem around it: benchmark → oracle → market makers → curve → collateral → hedgers → settlement → capital That is the thing we would actually have to build. And that leads to the conclusion I keep coming back to. The future of digital assets in energy is probably not tokenized electricity. It is a financial layer that allows energy risk to move more freely than the physical asset ever could. If we get the benchmark, liquidity and regulatory design right, PLD could be an unusually interesting place to test that idea. And if it works, the first important outcome may not be a crypto market. It may simply be a better energy market. --- Market Infrastructure / Hyperliquid / Energy — 02 Part 1: [Hyperliquid, energy and the next market infrastructure](https://onchain-fx.ghost.io/hyperliquid-energy-and-the-next-market-infrastructure/). This concludes the first two-part Market Infrastructure study. The broader question remains: Which other markets are expensive, illiquid or inaccessible not because the underlying risk is unusual, but because the infrastructure around that risk is old? That is the question this series will keep following. Subscribe to ONCHAIN FX for the next Market Infrastructure study. This article is a conceptual market-design exercise and does not constitute investment, legal or regulatory advice. --- **Follow the money through Brazil.** ONCHAIN FX covers markets, capital, stablecoins, technology, infrastructure and the systems behind moving serious money. Get the next note in your inbox. [Subscribe](#/portal/signup) Moving meaningful volume through Brazil? [Talk to us.](https://onchain-fx.ghost.io/about/)