WWW.BLOCKCAST.CC
Monero [XMR], one of the most renowned privacy coins, underwent a successful hard fork on block 2,688,888, this Sunday (14 August). The upgrade incorporated significant changes to make the network more secure and private. But the question is- Did XMR see any interesting happenings on-chain or on its price action? Upgraded life The team behind […]
Visit us at https://is.gd/xVLpJu
Visit us at https://is.gd/QohRnR
Visit us at https://is.gd/GSh4bP
Visit us at https://is.gd/exgdgs
Visit us at https://is.gd/AQTOSF
What are the smart contract vulnerabilities in the Ethereum application layer, data layer, consensus layer, and network layer?
Title of the original text: “Exploring the Vulnerabilities of Decentralized Finance (DeFi) Blockchain Smart Contracts”
Written by: Abba Garba, WeBlock CTO
Translation: HAO
Blockchain is a new type of distributed system system, which uses P2P peer-to-peer network communication, block storage, distributed algorithm consensus and encryption algorithm to prevent tampering. In essence, the blockchain can be seen as a distributed database maintained by all network nodes. Compared with traditional distributed databases, blockchain is more suitable for applications that have clear requirements for decentralized trust due to its complete data backup, open and transparent network, no tampering, complete information traceability and weak trust model Scenes. In particular, typical blockchain application scenarios include digital payment, product traceability, copyright protection, supply chain finance, etc. In the blockchain system, smart contracts play an extremely important role in implementing distributed application deployment and expanding application functions. Compared with traditional applications, the blockchain system has the characteristics of openness, transparency, execution, non-tamperability, and non-reliance on third parties, and the smart contracts running on the blockchain system architecture can satisfy various decentralized applications. The needs of the scene, including the rapid development of decentralized finance (DeFi) projects in recent years.
As of January 15, 2021, Decentralized Finance (DeFi) has become a successful financial paradigm with more than US$4.5 billion in capital. It uses blockchain-based smart contracts to ensure its integrity and security. Decentralized finance is a new development area for the exchange, lending or borrowing of tokens. Usually, these instructions are regulated by smart contracts (rather than a single centralized legal person or individual) and/or controlled by a multi-party, decentralized governance mechanism (such as DAO) to control the “revenue” or income flow. Decentralized Finance (DeFi)-gradually emerging on top of the existing blockchain platform. The components of this new field include those related to loans, asset trading and derivatives markets. As a decentralized application, smart contracts manage a large number of digital assets, which also makes them vulnerable to various attacks.
This article will elaborate on the security of smart contracts from three dimensions: First, the security of smart contracts due to loopholes in each layer of the Ethereum architecture. Secondly, various recent attacks on DeFi and smart contracts will also be discussed. Finally, we will discuss how existing feasible tools and other effective practices can minimize such attacks.
Before discussing the vulnerabilities of smart contracts, let us briefly outline the architecture of Ethereum smart contracts.
The blockchain network can deploy and automatically execute programming script tasks. These programs are called smart contracts and are used to define custom functions and rules to be called during the transaction. Blockchain technology based on smart contracts has been applied to various industries, such as finance, supply chain management, healthcare energy, and government services. Only certain blockchain platforms support smart contracts: Ethereum is the first to support smart contracts. Other blockchain platforms (such as EOS, Lisk, Bitcoin and Hyperledger Fabric) are compatible with the deployment and execution of smart contracts. A script type language called Solidity is used to develop smart contracts in the Ethereum platform. In this part, we introduced the security vulnerabilities related to the implementation of smart contracts on the Ethereum platform. Smart contracts can hold and manage the corresponding function Credit (address) {a large number of virtual currencies that may be worth thousands of dollars. Therefore, opponents constantly try to manipulate the execution of smart contracts to support their activities. Essentially, smart contracts run on a distributed and permissionless network, which inherits many vulnerabilities. In traditional systems, this small part of the centralized application can be re-developed or patched.
On the contrary, in a decentralized blockchain network, unless extreme measures are taken, the deployed smart contract cannot be modified or upgraded in the real-time network. The unchanging feature of smart contracts is their security advantages and disadvantages. Because of this immutability, hackers cannot change or modify the contract for their own benefit. However, developers cannot modify the smart contract application after deployment. They can cancel or terminate the contract and create a new smart contract, and then deploy it again. Therefore, due to security considerations, a large-scale test of the smart contract should be carried out before deploying the smart contract. We focused on the basic building blocks of the Ethereum smart contract architecture, as shown in Figure 1, which includes the Ethereum architecture.
Figure 1: The environment used to run the Ethereum blockchain is to interact with the four layers of the Ethereum architecture service through a Web user interface. The application layer is a database for storing blockchain data and supporting consensus protocols. Encryption mechanism and Internet services used at the network layer [20]
Application layer: The Ethereum client executes smart contracts in the EVM, where the smart contract is associated with the Ethereum account. Ethereum supports two types of accounts: externally owned accounts (EOA) and contract accounts. EOA is used to store user funds in Wei, which is the smallest sub-denomination of Ether and is worth 10-18 Ether. EOA is associated with the public key and resolved by the public key; access to EOA is verified by showing the ownership of the corresponding private key. Instead, a contract account is associated with a piece of executable bytecode (ie, a smart contract), which defines some interesting business logic. Smart contracts are the cornerstone of DApps. DApp usually uses the user interface as its front end and some smart contracts as its back end. Some DApps will issue their own cryptocurrencies called tokens for initial coin offering (ICO) and exchanges. Ethereum-based tokens are a special type of smart contract (such as ERC-20) [20]. Smart contracts are executed in EVMs, which are quasi-Turing complete machines using a stack-based architecture. The term “quasi” means that the execution is limited by the gas provided by the transaction. In the application layer of Ethereum, various vulnerabilities occur, leading to many attacks, as shown in the diagram in the application layer.
Data layer: contains the blockchain data structure. A transaction is an interaction between an EOA (called the sender) and another EOA or contract account (called the recipient). The transaction is specified in the following way:
Consensus layer: to ensure that the state of the blockchain is consistent. At the time of writing, Ethereum takes approximately 12-14 seconds to create a block, which means that multiple miners can create valid blocks at the same time, and there may be many blocks. Ethereum uses a variant of the GHOST consensus protocol to select the “heaviest” branch as the main chain, where the “heaviest” branch is rooted in the subtree of the fork in question, and has the highest cumulative block difficulty, while noting the obsolescence The block is not on the main chain. But note that Ethereum uses Proof of Stake (PoS) to replace its current Proof of Work (PoW).
Network layer: An Ethereum peer-to-peer (P2P) network that manages nodes or clients, so that nodes can always obtain the updated status of the blockchain from certain active nodes. The Ethereum network is a structured P2P network in which each node (i.e. client) stores a copy of the entire blockchain. For node discovery and routing, each node maintains a dynamic routing table, which contains 160 buckets, and each bucket contains up to 16 other node IDs, IP addresses, and UDP/TCP port entries. Ethereum uses the RLPx protocol to discover the target client, and uses the Ethereum wire protocol to facilitate the exchange of Ethereum blockchain information (such as transactions, blocks) between the clients.
Ethereum blockchain environment: running in the following four-layer environment: the web interface for users to interact with the Ethereum blockchain; the database of Ethereum customers, which is used to store blockchain data; the encryption mechanism for security purposes ; And the Internet infrastructure that supports blockchain communication between Ethereum nodes. We distinguish the Ethereum blockchain architecture from the environment, because attacks on the Ethereum blockchain may come from the environment, and these attacks may be better solved in the environment instead of being solved by Ethereum.
It focuses on the smart contract vulnerabilities in each layer of the Ethereum system, as shown in Figure 2.
Figure 2: Classification of vulnerabilities in each layer of Ethereum
Ethereum application layer
Reentrancy: This vulnerability was originally discovered from the DAO attack[1]. When the external callee contract calls back the function in the caller contract before the user contract is completed (that is, it is a cyclic call in a sense), it will This vulnerability occurs. This allows the attacker to bypass appropriate validity checks until the caller’s contract is exhausted or the transaction runs out.
Delegated call injection: This vulnerability was first discovered from the attack on Parity Wallet [2]. In order to promote code reuse, EVM provides an opcode delegation call, which is used to insert the bytecode of the callee contract into the bytecode of the caller contract. As a result, the malicious callee contract can directly modify (or manipulate) the state variables of the caller contract. This vulnerability is caused by the fact that the callee contract can update the state variables of the caller contract. The statement aims to call a stateless contract shared as a library through delegated calls, which can completely prevent this vulnerability.
Frozen Ether: This vulnerability was discovered for the first time from the attack on Parity Wallet [3]. The vulnerability occurred because users were unable to deposit money into their contract accounts and were unable to spend funds from these accounts, effectively freezing their funds.
Upgrade contract: The idea of ​​introducing contract upgrade is to alleviate the problem that smart contracts cannot be modified once deployed, even if they are found to have loopholes in the future. In order to allow contract upgrades, there are two methods: (i) divide the contract into proxy contracts and logical contracts so that developers can upgrade the latter instead of the former; (ii) use registry contracts to save the updated contracts. Although these methods are effective, they introduce a new vulnerability: when the contract developer becomes malicious, the updated contract may be malicious. This vulnerability (ie, insecure contact update) is still an unresolved issue.
DoS with accidental restoration: This happens because the calling party contract encounters an external call failure and the transaction is restored, or the called party contract deliberately performs a restoration operation to interrupt the execution of the calling party contract. This vulnerability is caused by the execution of the caller contract restored by the caller contract. By enabling the receiver to call the transaction to “extract” the funds reserved by the sender for the receiver, this loophole can be prevented, thereby effectively preventing the sender’s transaction from being restored.
Integer overflow and underflow: This vulnerability was discovered for the first time in an attack against BEC tokens [4]. This happens when the result of the operation exceeds the range of the Solidity data type, for example, leading to unauthorized manipulation of the attacker’s balance or other state variables. The vulnerability is caused by the Solidity source code not performing correct verification on digital inputs, and neither the Solidity compiler nor the EVM provides integer overflow/underflow detection. This vulnerability can be prevented by using the SafeMath library to deal with these problems.
Manipulating balance: This vulnerability occurs when the control flow decision of the contract depends on this value. To balance or balance the balance, an attacker can use it to make himself the only person who can get money. This vulnerability can be prevented by not using any contract balance in the condition statement [5]. Authentication via tx.origin: tx.origin is a global variable in Solidity, which refers to the original EOA that initiated the problematic transaction. This vulnerability occurs when the contract uses tx.origin for authorization, which may be compromised by phishing attacks. This vulnerability can be prevented by using msg.sender instead of tx.origin for authentication, because msg.sender returns the account that caused the message.
Incorrect visibility: The visibility of features is incorrectly specified, allowing unauthorized access.
Unprotected suicide: The owner of the contract (or an entrusted third party) can use suicide or self-destruction methods to destroy the contract. When the contract is cancelled, its associated bytecode and storage will be deleted. The vulnerability is caused by insufficient identity verification enforced by the contract. This vulnerability can be mitigated by enforcing, for example, multi-factor authentication, which means that suicide operations must be approved by multiple parties.
Leaking Ether to any address: When any caller can withdraw funds from the contract, the loophole will not occur. The caller is neither the owner of the contract nor the investor who deposits funds into the contract. This vulnerability is caused by the inability to check the identity of the caller when the caller invokes the function of sending ether to an arbitrary address. This vulnerability can be prevented by proper authentication of the function of sending funds.
Confidentiality failure: In the blockchain, due to the public nature of the blockchain (that is, the transaction details are well-known), restricting the visibility of variables or functions does not ensure that the variables or functions are confidential. One possible solution to prevent this vulnerability is to use encryption techniques, such as timing commitments [6].
Insufficient signature information: This vulnerability occurs when the digital signature is valid for multiple transactions. When a sender (such as Alice) sends money to multiple recipients through a proxy contract (rather than initiate multiple transactions), it may This vulnerability can occur. This vulnerability was originally exploited in a replay attack against smart contracts. This vulnerability can be prevented by incorporating appropriate information (such as current value and timestamp) in each message.
DoS with unrestricted operations: This vulnerability was first observed in the Govern Mental contract [7].
Unchecked call return value: This vulnerability is also known as an exception for handling errors. It has two variants, called gas-less sending and unchecked sending. This situation occurs when the return value of the low-level call is not checked, and execution may continue even if the function call throws an error [8].
Uninitialized storage pointer: Looking back, in Solidity, contract state variables are always placed in storage continuously starting from slot 0. For compound local variables (for example, struct, array, or mapping), assign references to slots in unoccupied object storage to point to state variables.
Wrong constructor function name: This vulnerability was originally observed from the Rubixi contract [9]. The name of the constructor function is incorrect. It allows anyone to become the owner of the contract. Before Solidity 0.4.22, a function declared with the same name as the contract was regarded as a contract constructor, and this function was only executed when the contract was created.
Type conversion: This vulnerability was first discovered in [10]. A contract written in Solidity language can call another contract by directly referencing an instance of the callee contract.
Outdated compiler version: Occurs when a contract uses an outdated compiler, which contains errors, thus making the compiled contract vulnerable to attack. This vulnerability can be prevented by using the latest compiler.
Short address: This vulnerability was first implemented in [11] and has been extensively discussed.
Ether lost to an isolated address: Ether lost to isolation occurs when remittances, Ethereum only checks that the length of the recipient’s address does not exceed 160 digits, and does not check the validity of the recipient’s address. If money is sent to an isolated address that does not exist, Ethereum will automatically register the address instead of terminating the transaction. Since the address is not associated with any EOA or contract account, no one can withdraw the transferred funds, which is actually lost. This vulnerability is caused by the inability of EVM to isolate protection. At the time of writing, this vulnerability can only be prevented by manually ensuring the correctness of the recipient address.
Call stack depth limitation: This vulnerability is caused by the insufficient execution model of EVM and has been eliminated by the hard fork of EIP-150, which redefines the fuel consumption rules of external calls, making it impossible to reach 1,024 in Call stack depth.
Underestimated opcode: This vulnerability was first discovered from two DoS attacks [12] [13].
Transaction order dependency (also known as front-end operation): This refers to concurrency issues, that is, the upcoming state of the blockchain depends on the execution order of transactions, but is determined by the miners.
Time dependency: This vulnerability occurs when the contract uses block.timestamp as part of the trigger condition or as a source of randomness that can be manipulated by malicious miners when performing key operations (such as remittances). The vulnerability is caused by Ethereum, which only requires the timestamp to be greater than the timestamp of its parent block and within 900 seconds of the current clock.
Generate randomness: For example, many gambling and lottery contracts randomly select winners. The usual practice is to generate pseudo-random numbers based on some initial private seeds (such as block.number, block.timestamp, block.difficulty or blockhash). However, these seeds are fully controlled by miners, which means that malicious miners can manipulate these variables to make themselves a winner. This vulnerability is caused by a manipulable entropy source.
Data layer vulnerabilities
Indistinguishable chains: When Ethereum was divided into two chains, ETH and ETC [13], this vulnerability was first observed from cross-chain replay attacks. Recall that Ethereum uses ECDSA to sign transactions. Before the EIP-155 [7] hard fork, each transaction contained six fields (ie, random number, recipient, value, input, gasPrice and gasLimit). However, digital signatures are not chain-specific, because chain-specific information is not even known at that time. As a result, transactions created for one chain can be reused by another chain. This vulnerability has been eliminated by merging the chainID into the field.
“Empty Account” in State Trie: This vulnerability was first discovered from a DoS attack reported in References [12] [13].
Vulnerabilities in the consensus layer
The problem that can be outsourced: Recall that Ethereum adopted a PoW problem called Ethash, which is designed to resist ASICs and limit the use of parallel computing (due to the fact that most of the work of miners will be reading data sets. Passing limited Memory bandwidth). However, cunning miners can still divide the task of searching for solutions to difficult problems into multiple smaller tasks and then outsource them. The vulnerability is caused by Ethash, which only makes the puzzle solution partially sequential in the original image search, instead of relying on sequential PoW.
Probabilistic finality: This vulnerability is caused by the design of the Ethereum blockchain that prefers availability rather than consistency, which is selected according to the CAP theorem [14].
DoS with block padding: This vulnerability was first observed in the Fomo3D contract [15]. The vulnerability only caused the attacker’s transaction to be included in the newly mined block, while other transactions were abandoned by the miners for a period of time. This can happen when the attacker provides a higher gasPrice to incentivize miners to choose the attacker’s transaction. This vulnerability is caused by a greedy mining incentive mechanism. At the time of writing, there is no solution to prevent this vulnerability.
Honest mining assumption: This vulnerability is caused by the consensus protocol because it is incompatible with incentives, see [16]. At the time of writing, this vulnerability is still an unresolved issue.
Block reward: It refers to the block reward mechanism, which is used to deal with the increase of stale blocks due to the rapid generation of blocks. However, this mechanism has a side effect, that is, allowing selfish miners to turn old blocks into blocks and get rewards, thereby effectively incentivizing selfish mining and double spending.
Verifier’s dilemma: This vulnerability was first reported in Reference [17] and refers to when a new transaction requires effortless calculations, regardless of whether the miner chooses to verify the transaction, it will be attacked. If the miners verify the computationally intensive transactions, they will spend a lot of time and provide an advantage to the attacker in the next block competition; if the miners accept the transaction without verification, the blockchain may contain incorrect transactions. This vulnerability is caused by the high cost of validating resource demand transactions in Ethereum. This vulnerability can be mitigated by limiting the amount of computation required to verify all transactions in the block [17]. However, it is not clear how to eliminate this vulnerability.
Vulnerabilities in the network layer
Creation of infinite nodes: This vulnerability is for Geth client versions prior to 1.8. In the Ethereum network, each node is identified by a unique ID, which is a 64-byte ECDSA public key. An attacker can create an unlimited number of nodes (that is, with the same IP address) on a computer, and then use these nodes to monopolize the incoming and outgoing connections of certain victim nodes, thereby effectively connecting the victim to the network. Isolate other peer nodes. This vulnerability is caused by weak restrictions on the node generation process. This vulnerability can be eliminated by using a combination of IP address and public key as the node ID. The Geth developers have not yet adopted this countermeasure, which they believe has a negative impact on the usability of the client.
Unrestricted incoming connections: This vulnerability is in the Geth client prior to version 1.8 [18]. Each node can have a total of maxpeers connections (the default value is 25) at any point in time, and can initiate up to 1 (1 + maxpeers)/2⌋ outbound TCP connections with other nodes. However, there is no upper limit on the number of incoming TCP connections initiated by other nodes. By establishing many incoming connections for maxpeers to victim nodes that do not have outbound connections, the attacker has the opportunity to overshadow the victim. In Geth v1.8, by imposing an upper limit on the number of incoming TCP connections to the node, the default value is ⌊maxpeers/3⌋= 8, which eliminates this vulnerability.
Public peer selection: This vulnerability was detected in Geth client versions prior to 1.8 [18].
Peer selection: This vulnerability refers to the fact that when the Geth client selects a node from its routing table to establish an outbound connection, it always obtains the header of a randomly selected bucket. Since the nodes in each bucket are sorted by activity, an attacker can send a message to the Geth client regularly to keep the node in front of other nodes. By randomly selecting a uniform node from the set of all nodes in the routing table, instead of randomly selecting a node from the header of each bucket, this vulnerability has been eliminated in Geth v1.9.
Independent block synchronization: It allows attackers to partition the Ethereum P2P network without monopolizing the connection of the victim’s client. Recall that each block header contains a difficulty field, which records the difficulty of mining the block. The total difficulty of the blockchain is represented by totalDifficulty, which is the sum of the difficulty up to the current block.
RPC API exposure: This vulnerability was originally discovered through attacks on Geth and Parity clients [19].
Quote:
[1] https://www.coindesk.com/understanding-dao-hack-journalists
[3] https://medium.com/blockcat/on-the-parity-multi-sig-wallet-attack-83fb5e7f4b8c
[4] https://nvd.nist.gov/vuln/detail/CVE-2018-10299
[6] https://eprint.iacr.org/2016/1007.pdf
[7] https://www.reddit.com/r/ethereum/comments/4ghzhv/governmentals_1100_eth_jackpot_payout_is_stuck/
[10] https://medium.com/golem-project/how-to-find-10m-by-just-reading-blockchain-6ae9d39fcd95
[12] https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/
[13]https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513?gi=3b0603be9186
[14] https://dl.acm.org/doi/10.1145/3149.214121
[15] https://medium.com/coinmonks/how-the-winner-got-fomo3d-prize-a-detailed-explanation-b30a69b7813f
[16] https://dl.acm.org/doi/10.1145/3212998
[17] https://dl.acm.org/doi/10.1145/2810103.2813659
[18] https://ljk.imag.fr/membres/Jean-Guillaume.Dumas/Enseignements/ProjetsCrypto/Ethereum/236.pdf
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.
The combination of the perpetual market and the spot market is the most basic and commonly used strategy.
Written by: Weiting Chen, Perpetual Protocol Growth Manager
Prior to this, we have learned the relevant knowledge of perpetual contract transactions several times.
This is the most traded derivative in the cryptocurrency market, reaching billions of dollars in daily trading volume.
The problem is that participating in contract transactions involves leverage. Leveraged trading is risky-especially when the market is contrary to your predictions. You may be liquidated, resulting in loss of assets.
But… did you know? There is a relatively safe way to obtain a considerable rate of return while maintaining market neutrality.
It cannot completely eliminate risk (because you still need to trade with leverage), but it does provide a way to earn passive income from these widely traded derivatives. More importantly, you can play the role of the system, which protects you from market fluctuations.
Weiting shows you several methods, one of which has an astonishing rate of return of 32% APY.
But please pay attention! For traders, this is a fairly advanced strategy-not for everyone. Therefore, please proceed with caution.
Below we will introduce how to use the capital rate to get rich.
In today’s strategy, we will learn how to earn income through the capital rate of perpetual contract transactions while maintaining market neutrality. Before we begin, I would like to point out that because the market is dynamic, the strategies mentioned in this issue may not always be effective. It all depends on market conditions.
Having said that, after reading the book, you can still learn how to achieve market neutrality and obtain benefits from funding rates in a variety of ways.
let’s start.
If you already understand how perpetual contracts and funding rates work, please skip this section.
A perpetual contract is a derivative tool that allows you to be bullish or bearish on the corresponding asset without having to hold actual assets. If the user is bullish on the price of the underlying asset (perpetual contract price), he can open a long position with leverage; on the contrary, if he is bearish, he can open a short position.
Since it is a derivative product, the internal price of the perpetual contract is not necessarily the same as the spot price of the underlying asset. This is why if everyone opens a long position on the derivatives exchange, it will push the price of derivatives to continue to rise, which creates opportunities for arbitrageurs to open short positions to drive down prices.
Moreover, in order to further push the price of the perpetual contract (called the “marked price”) to the spot price of the underlying asset (the “index price”), derivatives exchanges usually adopt a method called “funding rate payment”. Mechanism to provide incentives, so that more traders take (bullish or bearish) the choice of the lesser side.
The working method of fund rate payment is as follows:
In a given time interval (usually every eight hours), the derivatives exchange calculates the difference between the time-weighted average price of the marked price (ie, “TWAP”) and the TWAP of the index price. If the difference is greater than 0 (funding rate> 0), it means that there are too many long positions on the exchange.
Conversely, if the difference is negative (funding rate <0), the long position holder will pay a certain funding fee from his margin to the short position holder, and vice versa.
Summary:
Two things can affect the direction of funding rates:
The first thing should be self-explanatory-if the overall market sentiment is bullish on an asset, the funding rate may be positive because there are more longs than shorts. Otherwise, the funding rate is expected to be negative.
However, the characteristics of the trading venue also play a role in determining the funding rate.
For example, in the perpetual agreement , although the daily trading volume of the ETH/USDC perpetual market exceeds 10 million USDC, the prices of derivatives are often lower than the spot prices in centralized exchanges, as shown in the following figure:
My explanation for this phenomenon is that the perpetual agreement uses the constant product curve of x * y = k within the virtual automated market maker (vAMM) to determine the price of the perpetual contract, which is derived from the exchange under the order book model Compared with product transactions, more funds are needed to drive market prices.
Therefore, traders are more conservative on the perpetual agreement platform-because if traders buy too aggressively during a bull market, they may have to wait longer for the price to rise to the level where they usually expect to close their positions.
Therefore, since the ETH/USDC market was launched on the perpetual agreement, the funding rate has been negative most of the time. On the contrary, in exchanges that use the order book model such as FTX, the funding rate of the same asset is usually positive during the bull market (see the table below for details).
Before delving into the following guidelines, it is important to understand what a market neutral strategy is.
There is a good definition on Investopedia : a market neutral strategy is an investment strategy that attempts to profit from the rise and fall of prices in one or more markets, while trying to completely avoid a certain form of market risk.
For today’s strategy, the market-neutral strategy we will implement is to create a portfolio of positions whose profits and losses offset each other so that investors can (mainly) profit from capital expenses.
Let’s start with a simple example.
The easiest way to achieve market neutrality is to establish a position in the perpetual market, the direction of which is to obtain the funding fee, and to establish a position in the opposite direction in the spot market.
For example, because the perpetual market’s funding costs on the perpetual agreement are usually negative, you can open a long position through perp and open a short position in the corresponding asset of the equivalent position on a margin trading platform such as Fulcrum or dYdX.
Remember: when the funding rate is negative, the shorts pay the funding costs to the longs.
If the underlying asset is too new to be listed on any margin trading platform, you can try your luck on Cream Finance, which is similar to Aave or Compound, but its listed assets are more diverse. If you can, you can also sell the borrowed assets on Uniswap to offset your long position in the perpetual market.
Conversely, if the funding rate in the perpetual market is generally positive, you can open a short position in that market and purchase the underlying asset in a spot market such as Uniswap.
For those who want to implement this strategy: Remember to consider transaction fees, interest rates and gas fees for margin trading.
As mentioned earlier, the funding rate on perpetual agreements is usually negative, while the funding rate on order book exchanges is usually positive. In order to profit from this situation, traders can open positions on their respective platforms with the same position size but in the opposite direction of long and short.
For example, at the time of writing, the hourly funding rate of the ETH/USDC perpetual market on the perpetual agreement is -0.0039%, which means that if you hold a long position at the end of the hour, you will receive funding fees.
At the same time, on dYdX, the 8-hour funding rate for the same market is 0.0689%, which means that if you hold a short position within the funding rate settlement time, you will receive funding fees.
According to this strategy, you can open a long position of 5 ETH on the perpetual agreement with a leverage of 2 times, and at the same time open a short position of 5 ETH on dYdX with a leverage of 2 times. Assuming that the funding rates of the two agreements remain unchanged, then you can accumulate a total of 0.03% of remuneration from your corresponding positions every 8 hours, that is, the APR is 32.85%.
💡Note from the author: I have used a lower leverage here because I want to reduce the risk of liquidation.
For a perpetual market where the funding rate is always paid in the same direction, you can establish a position to obtain funding fees in this market, and open a corresponding position under the same underlying asset market in the opposite direction in the quarterly futures market. In this way, you can maintain market neutrality and still receive funding costs.
💡Traditional futures contracts have no funding rate mechanism.
For example, in November last year, when the Filecoin perpetual market and quarterly futures market were launched on FTX, due to its high fully diluted valuation, the funding rate of the perpetual contract has been negative since the first day.
If we can go back in time, we can open a long position of 100 FIL in the perpetual market and open a short position of 100 FIL in the futures market on December 28.
There may be a question that keeps echoing in your mind: “When should I close my position?” Well, it depends on your strategy. However, I will consider closing the position when the following two situations occur: 1) When the direction of payment of funds costs has changed for a period of time, that is, the market sentiment has changed; or 2) When the quarterly futures expire.
However, at present, this strategy can only be executed on centralized exchanges, because there are very few perpetual markets on decentralized exchanges, even those with the richest collection of perpetual markets in decentralized exchanges On perpetual agreements, there are only less than twelve markets.
But I think the situation will be greatly improved this year because:
If you have enough creativity, in addition to funding rates, you can also find more income methods.
Given that the funding rate on perpetual agreements is usually negative, you can combine long positions on perpetual agreements with short positions on Synthetix to achieve market neutrality.
With this combination, you can get:
Let me use the previous example to explain the strategy in detail.
Nowadays, the funding rate of the ETH/USDC perpetual market based on the perpetual agreement is -0.0039%, so you should open a long position to obtain funding fees.
Suppose you open a long position of 1 ETH here with a leverage of 2 times. Similarly, low leverage can reduce the risk of liquidation of positions.
Then, you go to the Synthetix exchange to obtain 1 iETH, which is back-tracking the price of ETH (back-tracing means that if the price of ETH goes up by 1 USD, the price of iETH goes down by 1 USD).
💡You need sUSD to trade on the Synthetix exchange. If you need to buy, Curve is a good choice.
Once you receive your iETH, your combined position should be market-neutral-if ETH goes up by $1, then your long profit on the permanent agreement is $1, which offsets the $1 loss of iETH on Synthetix. In the last step, you need to go to Synthetix’s income page to pledge your iETH tokens, so that you will receive pledge rewards on SNX. The current annualized income of iETH pledge exceeds 100%.
There are many ways to use funding rates to get returns while maintaining market neutrality.
Whether it is implementing a more basic strategy such as a combination of perpetual market + spot market, or trying to take advantage of the dual advantages of funding rates on different platforms, or even using other DeFi protocols such as Synthetix, it can bring you benefits.
However, it is more important to realize that some of these strategies are only feasible under certain market conditions (for example, the direction of payment of capital rates), and such market conditions are not always the same.
In any case, once you have a deep understanding of how the funding rate works and the underlying market dynamics, you can usually find a way to take advantage of the funding rate.
Just please be cautious, because there are risks in leveraged trading, and you may still be liquidated!
The DOT participating in the auction is locked on the Polkadot relay chain and will be returned to the original account after the parachain ends.
Original title: “Detailed Explanation of Polkadot and Kusama Parachain Bidding PLO”
Written by: CANAAN
Source: Polkadot Technical Community
Before understanding the parachain auction, you first need to understand the multi-chain basic model of Polkadot and Kusama. Unlike Ethereum, which only has two layers of chain and application, Polkadot is composed of the following three layers:
Polkadot is composed of multiple layer1 parachains like Ethereum, but not any blockchain can be connected to Polkadot. The Parachain team needs to win the “Parallel Slot Auction” in order to obtain a slot for access to Polkadot.
You can think of parachain slots as parking spaces on the edge of the World Cup Stadium. These locations are in great demand, especially the ones that opened first.
Only by obtaining a slot can you become a “Polka Parachain” in the true sense, because the slot can provide the security of Polkadot sharing, cross-chain interoperability, on-chain governance, no-fork on-chain upgrades, and scalability , Low handling fee, etc.
To get a parachain slot, you have to win the parachain auction. Of course, you can buy a parachain slot from the market (if someone wants to sell it).
Before the parachain auction officially starts, in fact, we cannot determine which teams (or individuals) will participate in the auction. Once the auction starts, all participating data can be publicly available on the chain.
There are two ways for bidders to participate: use crowdloan (also called PLO) funds, or use your own Polkadot wallet (if you are a big one)
The auction will use an unlicensed candle auction format. Candle auction is a commonly used auction method for merchant ships in the 16th century. This method is characterized by random termination within a certain period of time, and the highest bidder is the winner at the end.
Polkadot and Kusama’s auctions are basically the same, and the official will announce the specific start and closing time.
The participating team needs to determine two pieces of information:
It should be noted that as long as the auction is terminated, participants can continue to increase the number of tokens participating in the auction.
So when will the auction be completely terminated?
In addition to the end time that everyone knows, the Polkadot system will also generate an end time at any time, this time will be converted into the number of blocks, and it will be the key time to finally decide who is the winner.
The team that wins the slot will launch their own mainnet as soon as possible. Teams that have not won a slot can participate in the next round of slot auctions (generally, there will be a new auction every 2 weeks)
After that, Polkadot and Kusama slot auctions will become an ongoing periodic event until the capacity is expanded to a total of 100+ parachains.
Parachain bidding support team raises DOT (Bid for Polkadot Slot) or KSM (Bid for Kusama Slot) through crowdfunding.
Unlike IC0, IC0 allows the user to give the token to the team and then exchange it back for the project’s token. The problem is that they don’t know whether the team will follow the white paper to achieve all the milestones, which also led to a lot of scams. Today, the blockchain industry is much more mature than the crazy 2017.
And we also have a brand new model, Crowdloan, also called PLO.
For example, if you take out 100 DOTs to participate in the PLO of Parachain A, if Parachain A successfully bids for slots for 2 years, these 100 DOTs will be locked on the Polkadot for 2 years, and Parachain A will So reward you with their Token.
This part of the reward will also have a ratio of unlocking and locking, such as 30% directly to you, and 70% unlocked over time.
The most important thing is that the 100 DOTs you provide are locked on the Polkadot relay chain, and the parachain team cannot take it away, so even if the parachain team fails in the end, there will be no such thing as IC0. Huge principal risk.
After 2 years, your 100 DOTs will be unlocked and can be circulated. The only thing you lose is about 12% annualized mortgage income during this period.
So when the slot expires in 2 years, what will happen to the parachain?
Q: How many slots will there be in each auction?
A: Considering that the Parachain team will bid for different periods of 6-24 months, the number of slots in each auction will change accordingly at any time.
Q: Can the DOT that participates in the PLO auction be used for other purposes? Such as participating in stake
A: Cannot participate in mortgage and auction at the same time.
Q: Will Kusama and Polkadot bid at the same time?
A: Kusama will start first. The Polkadot auction will only begin when the Kusama auction has stabilized. As time progresses, subsequent auctions will be synchronized periodically.
Q: What is the cycle of adding new slots on Kusama?
A: This is still unclear, maybe every two months or so.
Q: Can the project crowdfund DOT to bid for Kusama slots?
A: No way.
Q: How many teams are expected to participate in the auction? How many slot positions will there be this year?
A: The total number of slots is currently unclear. We expect to have 100+ slots.
Q: Is the real-time data of parachain auctions public?
A: Parachain auction is an on-chain module, and all data will be open and transparent.
Q: Which project is the most powerful competitor of Parachain?
A: It can only be seen after the auction starts, it is unclear
Q: Will there be large institutions to bid for parachains in the future?
A: We believe that in the future, large institutions, enterprises, and even governments may participate in the parachain auction. In the future, Polkadot’s governance can be participated by the CEOs of the world’s top 500, government management, etc., which is entirely possible.
Q: Do parachains need to prove themselves on kusama? Or can both parties bid at the same time?
A: You can bid at the same time.
Q: Is there an upper limit for the amount of a single PLO address? Is KYC required?
A: This is decided by the parachain project.
Reference link:
“Polkadot & Kusama Crowdloans and Parachain Auctions — Simplified”
WWW.BLOCKCAST.CC 