# Building Derivative Products On Hyperliquid - Aleksa Urosevic | Decenter/Perpflow

- Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community)
- Date: 2025-10-07
- Duration: 17:04
- Topics: People & Blogs
- Watch: https://streameth.org/watch/yt-CIh81SnqQxY
- YouTube: https://www.youtube.com/watch?v=CIh81SnqQxY

## Description

Building Derivative Products On Hyperliquid - Aleksa Urosevic | Decenter/Perpflow

## Transcript

Hi everybody. So today I'll be giving a quick talk about building derivative products and financial products and hyperlquid and more specifically I'll be talking about the pre-ompiled contracts and the unique opportunities that arise due to the it's okay it's okay due to the dual execution of the hyperlquid chain and the hyper core and hypervm synergy. First a quick introduction about myself. So my name is Alexa. Um I work as a researcher at the center R&D. It's the birthplace of DeFi saver and now also perflow. Uh perflow is a yield platform or hyperlquid. Um which I will get into more in the later part of my presentation. Okay. So first for those of you that are maybe not that much familiar with what Hyperlid is, Hyperlquid is a completely separate layer 1 blockchain that is built and optimized for derivatives trading. It operates under the HyperBFT consensus mechanism and it is highly performant. It has a throughput of close to 200,000 orders per second and with a block time of 200 milliseconds. uh its state execution is split into two components. So the hyper core component is the component that first launched and it's the one that has right the 200 millisecond block and can and you have a throughput of 200,000 orders per second and on it you trade with the derivatives the per the spot market it has the clo the central limit order book and it's highly performant and optimized for per trading. Now the second execution layer that as I said operates under the same consensus mechanism is the hypervm and it has the all the familiar things that all EVM systems have. You can deploy right smart contracts right in solidity and so on. Now what is the main issue with the dual execution system and that is how do you handle the communication between hyper core execution layer and hypervm execution layer. And now how hyperlquid does this is through the pre-ompiles. Now pre-ompile contracts are not something new. Uh they are they already exist on Ethereum and on Ethereum they're used for fun for operations that you know are constantly native and they are gas intensive. So pre-ompiled contracts are gas efficient functions embedded directly into Ethereum on client level meaning that these are not solidity smart contracts compiled right in EVM they are written in go on client level and you can access these functions and these contracts at fixed addresses between 0x01 to 0x9. Examples of these functions for Ethereum are elliptic curve functions the shot 256 encryption modular exponentiation and so on. all the functions that are constantly being used in Ethereum. So, Hyperlquid uses the pre-ompiled contracts also, but to serve it serves a different purpose uh in the hyperlquid ecosystem. In the hyperlquid ecosystem, it is used to connect and bridge hypervm with hyper core. So you want to have the familiar EVM atomic sol uh smart contract interface while also having access to the highly performing order books that hyper core offers and the deep liquidity that it comes with. So how does hyperlquid does this? It has two systems of contracts. The read pre-ompiles and the write pre-ompiles. The read pre-ompile contracts allow you to query the current state of hyper core and to read any of the information from hypercore. So this could be reading user balances, reading what which positions users have in certain perpetuals, the oracle prices of the perpetuals, the order book mid price of the given market and so on. And as you can see from the code, you just call a pre-ompile address. You give it the user's address and the token address and it will return to you the balance for the token of the user. The other system of pre-ompile contracts are the right pre-ompiles and the right pre-ompiles allow you to execute actions on hyper core. Now I didn't mention it read pre-ompiles are currently live on mainet and the right pre-ompiles are still in the test net phase but the right pre-ompiles are the one that are the most anticipated because they will allow you to execute actions on hyper core from hypervm. What this could be is sending orders to the order book uh transferring funds from one L1 account to another delegating stake to validators in the hyperbft consensus mechanism and so on. Uh now how the right pre-ompiles work are you call a pre-ompile contract it emits an event that the validators that operate the hyperlquid L1 listen to and they include your order in the next L1 block. So you here you have an example of sending in IOC orders. So that's just an immediate or cancel order to the order book. You you select which burp you want to trade, what is the direction you want to trade in, the limit price and size. The send token delegate is the example of giving a certain validator address a certain amount of hype to stake in the HyperBft consensus. Now I want to give you four examples here today of what unique things you can build with this. Uh and I'm not sure what happened to the text here. What? Okay. So, forget about the text. Something happened. I'll talk. Uh, so the first example is the pre-ompiles and the ERC20 token example. So what you can do with the dual uh chain architecture is you can deploy a familiar right ERC20 token on hyperVM and at the same time you can deploy a spot market a spot order book on hyper core it's done for a Dutch auction you buy a ticker right and you you can deploy any spot market on the on the L1 and through the pre-ompiles you can connect these two markets so you can make this token one to one fungeible on these two chains so when you send to a certain pre-ompile address and one one of these token you will get it minted immediately in HyperVm and vice versa. What this creates right is you can have all the D5 functionality on Hyper EVM with the RC20 token standard plus the deep liquidity and performance that Hyperlid L1 offers to you. A second example is the decentralized staking. So the current stake >> sorry Ah, you'll fix the slides. Okay. Okay. Uh, so uh how currently staking works on hyperlquid is staked hype uh you send you send it into a staking contract, right? But the staking contract has to send it to an EOA address on L1 which then delegates the stake to validators, right? But with this token delegate function, you can have uh it all from happen from a smart contract, right? And that's what the kinetic hype team is currently doing. So you just put it into a staking contract and it calls the delegate function on the right pre-ompile and delegates the stake to hyper core validator that you choose. Another example of um another example of using the pre-ompiles is the Yeah. Should I wait for the presentation or >> just a minute? >> Okay. Okay. Okay. Oh, wait. >> Yeah, it's okay. Okay, great. Okay, so where was I? Uh, yeah, the pre-ompiles. So, so here here's a third interesting example of what you can use the pre-ompiles for is to execute liquidations in lending or CDP protocols. So imagine you have a classic lending protocol uh on EVM and you place XYZ collateral to buy uh to borrow ABC token. Now the lending pool uh can with with the pre-ompiles it can issue it can execute automatic liquidations. So what it can do is it can do it all in a decentralized way by using the read pre-ompiles to read the prices from the order books, calculating if your position has reached the liquidation threshold and then using the right pre-ompiles to access the deep liquidity of the order books on hyper core and sell the collateral asset thereby performing an fully onchain liquidation. Uh okay and the fourth final example I want to give to you is an example of how we plan to uh change our product to use the right pre-ompiles and to create a vault for our users. So let me first give you a quick introduction of what we do at Perflow. So, Perflow currently is a uh non-custodial one-click execution dashboard for running the funding fee strategy and on Hyperlquid. And what the funding fee strategy is is essentially you are shorting the perpetual contract on one side and buying the exact same size of the token. And essentially, you're creating a delta neutral position. Meaning that if you open the funding strategy on hype token, if hype goes up by a dollar, you will lose the same amount on the short short perpetual contract and you will win the same same amount on the spot side. Right? So the only exposure you have, you have no exposure to the price of the underlying asset. You only have exposure to the funding fee and funding fee is the mechanism that keeps the perpetual price in line with the spot price. And funding fees are there to reduce the basis, right? The spread. So when uh the demand pressure is higher in the perpetual markets, the funding fee gets wider. When it is less than in the spark market, it get it goes on the other side. And a funding fee is acred every hour. Longs pay shorts if the pressure is bigger on the per markets and shorts pay longs if the pressure is bigger on the spot demand side. Now empirically looking we looked at the data for the past five years and due to the lack of liquidity on the short side of the order book the funding fee when annualized has always been returning close to 15 to 20% on liquid perpetuals to the short side of the traders. So the protocol has to incentivize the short traders by by funding fee and therefore maintaining the peg. Now how we do this strategy currently we have a non-custodial setup we are a front front end rapper on hyperlquid we just executes the transactions in your wallet the problem with this is you have to monitor the liquidation part of the of the per now to automate this uh currently you would have to have a centralized solution where the money goes to an EOA it trades and it sends the money back to the user when he wants to withdraw it because currently without the right pre-ompiles you cannot execute you cannot execute transactions on L1 from Hyper EVM. But with the release of right pre-ompiles, this becomes possible. How? So this is the architecture. What we plan to do is to deploy a classic ERC 4626 vault on Hyper EVM where users would just deposit the collateral asset and get a share of our vault. In this case, the collateral asset is the USDT. and through the right pre-ompiles this vault will execute the transactions on L1 creating this delta neutral position. So what this means is you put in USDT and we take this USDT and we execute two actions with the right pre-ompiles. One is we buy hype for half the money for half the notional size and at the same time we short the perpetual on hype right and create we create this delta neutral position and the only exposure we have is the funding fee. If the funding fee is on the side of the short traders, meaning that longs pay shorts, we earn money. If it is the other case, we lose money. But empirically speaking, the the funding fees have always been on on the side of the short traders. Okay, so these were the four examples. There are many more examples and we'll see what happens once the right pre-ompiles will launch. But for the end I would like to talk about the problems um and the possible solutions to these problems that arise with the pre-ompile contract. Um the main problem is that if you look because this is right a dual block system you have the EVM blocks you have the L1 blocks and the L1 blocks go much faster than the EVM blocks currently. Um what you do is when use when you use the read pre-ompiles you read data from the previous block on L1 and when you write the data when you want to issue orders to L1 you write the data to the next block from EVM right now this is a problem because this creates uh it's not fully atomic right and as we saw in when I was talking about the right pre-ompiles you just emit an event and the validators include your transaction in the next block of L1 Now this doesn't guarantee to you that the trade has been executed on hyper core, right? Because uh it only guarantees you that the event has been emitted. So you would need to check in the next block. An offchain component would need to check in the next block if the transaction has really executed and update the contract on it. Now this can become really cumbersome and difficult maybe. So we see that this can be probably you know done in a separate solution but we'll see. Um yeah I think that's it. Uh thank you all for listening. This is the QR code to perflow. Um yeah any questions? [Applause] Any questions? >> Yeah. >> Yeah. Thanks for a great presentation. I just wanted to ask if uh there there is uh some estimated time of arrival of those right pre-ompiles. >> Yeah. So the team hasn't given us any official official stats, but I think in the next couple of months is the is the estimated time, but no official information. So how do you sync the price when you read from the before and you write it later? Like do you use like some kind of slipage or how do you define it? Uh you you're asking me if I'm reading from the last block the price how do I know which limited price to use? Yeah. So the blocks are extremely fast. So it you know it can't change that much but that's why the right pre-ompiles don't have like you send immediate cancel orders. What that means is you just say the limit price and if it gets executed on it it executed if not it's canceled. So that's how it works. Yeah. But it it is a problem you know that that's the last thing that that's that's the thing I was talking about this latency. Okay. Thank you guys.