├── assets ├── .keep ├── iip-13-flow.jpg ├── iip-14-flow.png ├── iip-15-flow.jpg ├── iip-21-flow.jpg ├── iip-22-flow.png ├── iip-36-flow.png ├── iip-21-price.jpeg ├── iip-22-bucket-state.png ├── iip-13-state-machine.jpg ├── iip-14-paymaster-flow.png ├── iip-22-delegate-state.png ├── iip-42-mint-fallback.png ├── iip-55-tokens-mapping.png ├── iip-42-optimistic-mint.png └── iip-50-delegate-revenue-and-productivity.png ├── .gitignore ├── iip-4.md ├── iip-26.md ├── iip-2.md ├── iip-5.md ├── iip-30.md ├── iip-27.md ├── iip-3.md ├── iip-21.md ├── iip-8.md ├── iip-11.md ├── iip-1.md ├── iip-32.md ├── iip-10.md ├── iip-40.md ├── iip-24.md ├── iip-52.md ├── iip-31.md ├── iip-29.md ├── iip-49.md ├── iip-28.md ├── iip-15.md ├── iip-12.md ├── iip-X.md ├── README.md ├── iip-20.md ├── iip-48.md ├── iip-22.md ├── iip-36.md ├── iip-14.md ├── iip-33.md ├── iip-41.md ├── iip-42.md ├── iip-7.md ├── iip-50.md ├── iip-13.md ├── iip-55.md └── iip-25.md /assets/.keep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .idea -------------------------------------------------------------------------------- /assets/iip-13-flow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-13-flow.jpg -------------------------------------------------------------------------------- /assets/iip-14-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-14-flow.png -------------------------------------------------------------------------------- /assets/iip-15-flow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-15-flow.jpg -------------------------------------------------------------------------------- /assets/iip-21-flow.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-21-flow.jpg -------------------------------------------------------------------------------- /assets/iip-22-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-22-flow.png -------------------------------------------------------------------------------- /assets/iip-36-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-36-flow.png -------------------------------------------------------------------------------- /assets/iip-21-price.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-21-price.jpeg -------------------------------------------------------------------------------- /assets/iip-22-bucket-state.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-22-bucket-state.png -------------------------------------------------------------------------------- /assets/iip-13-state-machine.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-13-state-machine.jpg -------------------------------------------------------------------------------- /assets/iip-14-paymaster-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-14-paymaster-flow.png -------------------------------------------------------------------------------- /assets/iip-22-delegate-state.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-22-delegate-state.png -------------------------------------------------------------------------------- /assets/iip-42-mint-fallback.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-42-mint-fallback.png -------------------------------------------------------------------------------- /assets/iip-55-tokens-mapping.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-55-tokens-mapping.png -------------------------------------------------------------------------------- /assets/iip-42-optimistic-mint.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-42-optimistic-mint.png -------------------------------------------------------------------------------- /assets/iip-50-delegate-revenue-and-productivity.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iotexproject/iips/HEAD/assets/iip-50-delegate-revenue-and-productivity.png -------------------------------------------------------------------------------- /iip-4.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 4 3 | Title: Lowering the block interval time 4 | Author: Dustin Xie (dustin.xie@iotex.io) 5 | Status: Implementing 6 | Type: Standards Track 7 | Created: 2019-08-01 8 | ``` 9 | 10 | ## Abstract 11 | 12 | Currently the IoTeX blockchain is producing a block at every 10 seconds. As a result, the transaction confirmation time lies in the range of 10~20 seconds with an average of 15 seconds. We are doing engineering study to investigate the feasibility to lower the block interval time. 13 | 14 | ## Implementation 15 | 16 | We need to adjust the following things of the blockchain protocol: 17 | 18 | - Adjust timing configuration in consensus module; 19 | - Adjust block reward and epoch reward setting to keep the same payout yield; 20 | 21 | ## Updates 22 | 23 | Once we finish the feasibility study, the new block interval time and activation timeline/plan will be announced. 24 | 25 | ## Copyright 26 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 27 | -------------------------------------------------------------------------------- /iip-26.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 26 3 | Title: Use VersionedDB to reduce CandidateBucket index DB size 4 | Author: Dustin Xie 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2023-12-04 9 | ``` 10 | ## Abstract 11 | This IIP introduced the concept of VersionedDB and utilized it to reduce the size of CandidateBucket index DB. It also discussed several techniques to optimize the DB operation 12 | 13 | ## Motivation 14 | CandidateBucket index DB is an auxiliary DB needed by API node. It stores the candidates and buckets at each epoch, and serves requests for API and analyser queries. API retrieves this data for query of each epoch's delegate list. Analyser polls this data for calculation of bucket rewards. 15 | As of now, this DB size has reached a whopping 110GB. This has caused a heavy burden on storage and the rate of size increase is not sustainable for the future. A solution is needed to reduce the DB size and better manage the file size increase. 16 | 17 | ## Proposal 18 | TBA 19 | 20 | ## Specification 21 | TBA 22 | 23 | ## Rationale 24 | TBA 25 | -------------------------------------------------------------------------------- /iip-2.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 2 3 | Title: Increasing Daily Epoch Reward Amount to 450K IOTX 4 | Author: Zhijie Shen (zhijie@iotex.io) 5 | Discussions-To: https://discord.gg/NxMKT5A 6 | Status: Final 7 | Type: Standards Track 8 | Created: 2019-06-08 9 | ``` 10 | 11 | ## Abstract 12 | 13 | When IoTeX MainNet was launched, only 12 out of 36 delegates came from the community, while the remaining ones are the 14 | bots. Now the number of real delegates have grown to 36. It's reasonable to motivate the community on operating the network 15 | in a further decentralized way, so that we propose to raise the epoch reward amount from 300K IOTX per day (24 epochs) to 450K. 16 | 17 | ## Implementation 18 | 19 | The per epoch epoch reward is 12,500 defined in the genesis config now. The number will be adjusted to 18,750, which 20 | will make it 450,000 totally for every 24 epochs. A new block height needs to be defined, from which the new epoch 21 | reward number will be used. 22 | 23 | ## Timeline 24 | 25 | The epoch reward amount adjustment will be rolled out with v0.7.2, and the hard fork will happen on 864,001-st block. 26 | 27 | ## Voting Process 28 | 29 | We will collect the opinion from the community to decide if we want to increase the epoch reward amount. As the on-chain voting is not ready yet, we will vote in the discord channel: https://discord.gg/NxMKT5A. The voting process is defined here: https://docs.google.com/document/d/1qAcZtNeX6vadLTXp6k1CEADVJwNv7BMZQrtQSLhgpqQ/edit. 30 | 31 | ## Update 32 | 33 | We originally planed to increase epoch reward to 350K per day, but after discussion, we decided to increase to 450K per day 34 | directly. Another uber proposal vote that propose for this is https://member.iotex.io/polls. 35 | 36 | ## Changelog 37 | 38 | 2019-07-31: New epoch reward amount was activated 39 | 2019-07-19: Update the progress 40 | 2019-06-08: Created the issue 41 | 2019-06-10: Added the details 42 | 2019-06-17: Added the voting details 43 | -------------------------------------------------------------------------------- /iip-5.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 5 3 | Title: Classifying EVM Error Status 4 | Author: Dorothy Ko (dorothy@iotex.io) 5 | Status: Final 6 | Type: Standards Track 7 | Created: 2019-08-14 8 | ``` 9 | 10 | 11 | ## Abstract 12 | Currently every execution of smart contracts on IoTeX Blockchain doesn't show any information of error if it fails to execute or deploy the smart contract. In order to give an information of error to the end-user, this standard outlines a common set of EVM Error Status Code. Therefore, we classify the possible EVM error and define EVM error status code. And we propose to give the EVM Error Code to the Receipt Status, so that it is visible to users/developers and accordingly it enhances UX(User Experience) and DX(Developer Experience). 13 | 14 | ## Motivation 15 | Sometimes, we failed to execute or deploy a smart contract. However, currently its status gives us just simple status such as Success(1) or Failure(0) in receipt and it doesn't give us any information of the reason of failure. In terms of user and developer experience, it makes us difficult to utilize the smart contract execution. 16 | 17 | ## Specification 18 | 19 | > General Status 20 | 21 | | code | Description | 22 | |------|--------------| 23 | | 0 | Failure | 24 | | 1 | Success | 25 | 26 | 27 | > 1xx for EVM Execution Error Status 28 | 29 | | code | Description | 30 | |------|--------------------------------------| 31 | | 100 | Unknown | 32 | | 101 | Execution out of Gas | 33 | | 102 | Deployment out of gas (store code) | 34 | | 103 | Max call depth exceeded | 35 | | 104 | Contract address collision | 36 | | 105 | No compatible interpreter | 37 | | 106 | Execution reverted | 38 | | 107 | Max code size exceeded | 39 | | 108 | Write protection | 40 | 41 | 42 | 43 | ## Backwards Compatibility 44 | This IIP may cause breaking chain because it changes the receipt status. Therefore, it needs a hard fork, such as height upgrade(Bering). So we propose to apply this modification of receipt status to blocks after Bering-Height and it'll prevent from the potential incompatibility issue. 45 | 46 | 47 | ## Implementation 48 | The status of receipt in the block after Bering-Height will include EVM Error Status code. 49 | 50 | 51 | ## Copyright 52 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 53 | -------------------------------------------------------------------------------- /iip-30.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 30 3 | Title: Deploy Circle Standard Token to ioTube (USDC.e) and Migrate ioUSDC to USDC.e 4 | Author: Qevan & Giuseppe 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2024-05-16 9 | ``` 10 | 11 | ### Background 12 | ioTube, the official bridge of IoTeX, introduced ioUSDC, a bridged token from Ethereum, on 9/14//2021. Since its launch, ioUSDC has been integrated with over 10 DeFi protocols and is held by over 5,000 wallet addresses. Recently, Circle proposed the [Bridged USDC Standard](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md), a specification and process for deploying a bridged form of USDC on EVM blockchains. This standard includes the optionality for Circle to seamlessly upgrade to native USDC issuance in the future. The Bridged USDC Standard provides a secure and standardized method for any EVM blockchain and rollup team to transfer ownership of a bridged USDC token contract to Circle, facilitating an upgrade to native USDC. 13 | 14 | ### Proposal 15 | 16 | 1. **Deployment of Circle Standard Token (USDC.e)** 17 | - Deploy the Circle standard token on IoTeX, using the symbol USDC.e as per Circle's recommendation. 18 | 19 | 2. **Migration from ioUSDC to USDC.e** 20 | - Enable users to convert their ioUSDC tokens to USDC.e seamlessly. 21 | 22 | 3. **Interoperability between USDC.e and ioUSDC** 23 | - Allow users to convert USDC.e back to ioUSDC to maintain compatibility with existing DeFi protocols that support ioUSDC. 24 | 25 | 4. **Bridge Support Enhancement** 26 | - Update ioTube to support bridging between USDC on Ethereum and USDC.e, replacing the current support for USDC on Ethereum and ioUSDC. 27 | 28 | ### Implementation Details 29 | 30 | 1. **Smart Contract Deployment** 31 | - Deploy the smart contract for USDC.e as specified by Circle. 32 | 33 | 2. **Wrapper Smart Contract** 34 | - Develop and deploy a wrapper smart contract that facilitates the conversion between ioUSDC and USDC.e. 35 | 36 | 3. **Validator Upgrades** 37 | - Upgrade all validators on ioTube to handle the new bridge functionality between USDC on Ethereum and USDC.e. 38 | 39 | 4. **DeFi Protocol Integration** 40 | - Recommend all DeFi protocols on IoTeX to support the new USDC.e token. 41 | 42 | ### Conclusion 43 | By implementing the proposed deployment and migration strategy, IoTeX will enhance its DeFi ecosystem's compatibility and ensure seamless token transactions for users. This initiative will leverage Circle's standard token format, positioning IoTeX for future integrations and improvements. 44 | -------------------------------------------------------------------------------- /iip-27.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 27 3 | Title: Collaborative Reward Claiming 4 | Author: Chen Chen (chenchen@iotex.me) 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2024-02-01 9 | ``` 10 | 11 | ## Abstract 12 | The Collaborative Reward Claiming Proposal aims to introduce a new method for claiming rewards by allowing proxies to conduct claiming operations on their behalf. This approach enables increased flexibility and convenience in the reward claiming process. 13 | 14 | ## Motivation 15 | Currently, due to the limitation of only being able to claim rewards by themself, nodes have to set the reward address to an Externally Owned Account (EOA), leading to potential security risks. By enabling reward address to be set to a contract account, the security of these rewards can be significantly enhanced. Introducing a reward proxy strategy would make it feasible to designate node rewards to contract accounts, providing a more secure option. This advancement not only mitigates security vulnerabilities associated with EOAs but also paves the way for a more robust and secure reward distribution system. 16 | 17 | ## Specification 18 | ### Claim Params 19 | Building upon the existing "ClaimFromRewardingFund" action, an "address" field is added to represent the account address where rewards should be claimed from and to. 20 | ``` 21 | type ClaimFromRewardingFund struct { 22 | amount *big.Int 23 | address string // newly added field 24 | } 25 | ``` 26 | The new account address can be an: 27 | - EOA/CA: Representing the rewards claiming from and to 28 | - Empty: Denoting account is the transaction sender, for backward compatibility. 29 | 30 | ### Procedure 31 | 1. Determine the account for reward claim: 32 | 1. If the "address" field is not empty, consider it as the reward account. 33 | 2. Otherwise, consider the transaction sender as the reward account. 34 | 2. Verify that the account has a sufficient balance of rewards. 35 | 3. Deduct the specified reward balance from the reward pool and transfer it to the reward account. 36 | 37 | ## Rationale 38 | 39 | ## Backwards Compatibility 40 | The updated action is backward compatible, and not setting the "address" field will result in the claim of rewards for the sender's account. 41 | 42 | ## Security Considerations 43 | Post-update, any EOA account is allowed to initiate reward extraction for account A. However, since rewards are only disbursed to A, malicious actors can, at most, affect the timing of others' reward claiming but cannot steal the rewards. This is deemed acceptable. 44 | 45 | ## Copyright 46 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-3.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 3 3 | Title: Removing the per action gas limit 4 | Author: Zhijie Shen (zhijie@iotex.io) 5 | Status: Final 6 | Type: Standards Track 7 | Created: 2019-06-17 8 | ``` 9 | 10 | ## Abstract 11 | 12 | Currently every action on IoTeX blockchain cannot consume more than 5 million gas. Even if user specifies the gas limit 13 | to a number greater than 5M, it will be capped to 5M by the system. This prevents developers from deploying some big 14 | contracts. Therefore, we propose to remove this per action gas limit, and let the action consume as much gas as possible 15 | until the block gas limit (20M now) is hit, as long as the action executor has enough IOTX for the gas fee. 16 | 17 | ## Rationales 18 | 19 | There are following rationales behind this proposal: 20 | 21 | - When launching the mainnet, the per action gas limit is introduced to prevent the risk of a big action overwhelming 22 | the block processing. After about 2 months running production, monitoring and testing, the blockchain platform turns 23 | out to be mature enough to execute big actions. As long as, the executor has enough IOTX for the gas fee, the action 24 | should be allowed to consume the whole block gas capacity. 25 | 26 | - Ethereum's current block gas limit is 8M, and it doesn't have per transaction gas limit cap. Therefore, there are smart 27 | contracts that are deployable on Ethereum, but not IoTeX yet. Making per action gas limit go beyond 8M will avoid the 28 | potential gas risk of migrating Ethereum dapps onto IoTeX. 29 | 30 | - Moreover, after removing the per action gas limit, the action can consume as much as 20M gas. It will even enable 31 | developers to deploy the contracts that are not deployable on Ethereum. 32 | 33 | ## Implementation 34 | 35 | We need to adjust the following things of the blockchain protocol: 36 | 37 | - Remove the per action gas limit from action execution context; 38 | - Remove the logic of capping action gas limit to the per action gas limit; 39 | - Define the read gas limit config, and replace the per action gas limit with it when restricting a state/contract read 40 | API call. 41 | 42 | Note that the read gas limit is a node/system config, which could vary from node to node. 43 | 44 | Note that the per action gas limit can't be removed from the genesis for the backward compatibility. 45 | 46 | ## Updates 47 | 48 | The per action gas limit is removed in the release `v0.7.2`, and will be activated from block 864,001. 49 | 50 | The per action gas limit removal was activated on 2019-07-31. 51 | 52 | ## Copyright 53 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 54 | -------------------------------------------------------------------------------- /iip-21.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 21 3 | Title: Bridge IOTX from IoTeX to Ethereum 4 | Author: Leo (leo@iotex.io) 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2023-04-17 9 | ``` 10 | 11 | ## Abstract 12 | 13 | This proposal outlines a plan to bridge the IOTX coin from IoTeX network to Ethereum and implement CIOTX (Crosschain IOTX) token on Ethereum, with the aim of improving its utilization and demand in DeFi protocols on Ethereum and exchanges. 14 | 15 | ## Motivation 16 | 17 | While IOTX has been successfully bridged to Binance Smart Chain and Polygon using ioTube and used on those chains for over two years, its legacy ERC-20 version, IOTX-E, has limited supply and low circulating availability on Ethereum. This restricts its usage and potential in DeFi protocols on Ethereum, as well as circulating on some centralized exchanges, with listing of IOTX-E, such as Coinbase, Bittrex. Therefore, we propose introducing CIOTX on Ethereum via ioTube bridge. CIOTX will be fully backed by the circulated IOTX on IoTeX network, thus having enough supply for use in any DeFi app on Ethereum and CEX circulating. Below is the price curve for IOTX-E/IOTX: 18 | 19 | ![price](./assets/iip-21-price.jpeg) 20 | 21 | ## Specification 22 | 23 | ### Bridge IOTX from IoTeX network to Ethereum using ioTube 24 | 25 | CIOTX is a wrapped IOTX on IoTeX network, which can be burnt and minted by ioTube bridge. CIOTX can be burnt on ioTube and minted on Ethereum, thus enabling its circulation on Ethereum. When there is more demand on Ethereum, CIOTX can be bridged from IoTeX network to Ethereum, and when there is more demand on IoTeX network, CIOTX can be bridged back from Ethereum to IoTeX network. 26 | 27 | ### As a standard ERC-20 token, CIOTX can be used in any protocol on Ethereum 28 | 29 | CIOTX can be used in popular DeFi protocols on Ethereum, such as Uniswap, Curve, Aave, Compound, etc. 30 | 31 | ### Swap between CIOTX and IOTX-E 32 | 33 | CIOTX can be paired with IOTX-E on DEX like Uniswap, Curve to allow users to swap between the two at a market price - As CIOTX and IOTX-E may have different values based on demand, they can possibly be paired on DEX like Uniswap, Curve to allow users to swap between the two tokens at a market price, thus enabling the market to determine their respective prices. 34 | 35 | ![flow](./assets/iip-21-flow.jpg) 36 | 37 | ### Easier Listing Process by Centralized Exchanges 38 | 39 | Cryptocurrency exchanges that prefer to utilize ERC-20 tokens now have the exciting opportunity to list CIOTX on Ethereum, which is fully backed by native IOTX coin. The listing will be an easy and simple process. 40 | 41 | ## Conclusion 42 | 43 | By implementing this proposal, IoTeX will have a more comprehensive ecosystem of IOTX-backed tokens that can be used across different blockchains, increasing their overall utility and value. 44 | 45 | ## Backwards Compatibility 46 | 47 | There is no backward compatibility concern. 48 | 49 | ## Security Considerations 50 | 51 | There is no security concern. 52 | 53 | ## Copyright 54 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 55 | -------------------------------------------------------------------------------- /iip-8.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 8 3 | Title: Delegated Actions 4 | Author: Raullen Chai (raullen@iotex.io) 5 | Status: Draft 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2020-07-23 9 | ``` 10 | 11 | ## Abstract 12 | TBD 13 | 14 | ## Motivation 15 | In many IoT scenarios, devices usually don't have initial balance in their wallets to initiate actions with IoTeX blockchain. To set up the initial balances on these devices requires extra work and is not scalable (think about one million devices deploying to the field). This pain point applies to human beings who want to interact with the blockchain/DAO. 16 | 17 | We need some kind of "delegation" to address this problem at the protocol level, i.e., all 0-balance accounts can delegate their gas fees to a non-0-balance account if the latter agrees. This is practical and useful in many scenarios, e.g., the account of a controller of devices (which could be a person, an app, or a device) covers all gas costs for the devices managed. 18 | 19 | At a high level, we require the delegation scheme to be **flexible** (i.e., support different delegation policies) and **safe** (i.e., rate-limit and revoke to mitigate the malicious consumption of another account's balance). 20 | 21 | ## Specification 22 | Since all transactions within the IoTeX network is termed as `Actions`, we call such a delegate `Delegated Actions`, and we call regular actions `Normal Actions`. Note that `delegate` here should not be confused with a delegate in the context of Roll-DPoS. 23 | 24 | At a high level, there are three key differences for a delegated action, comparing to a normal action: 25 | - Bind: a delegate agrees to cover a delegatee's transaction cost 26 | - Consume: when a delegatee initiate an action, the protocol charges its delegate for the gas fee; if the delegate has not enough balance, the action fails 27 | - Unbind: a delegate terminates the contract for covering the delegatee's transaction cost 28 | 29 | ### Bind 30 | Delegate initiates an action (bearing with a policy) to notify the protocol its willingness to cover the gas cost for certain delegatee addresses. The policy at least specifis the following: 31 | ``` 32 | - Delegatee address or adresses 33 | - Number of actions 34 | - Total gas consumed in IOTX 35 | - Start at block height 36 | - End at block height 37 | - Whitelist/blacklist, e.g., delegatee can/cannot initiate action with certain addresses 38 | - Rate limit, e.g., delegatee can consume at most X IOTX in Y blocks. 39 | ``` 40 | 41 | ### Consume 42 | 43 | 44 | ### Unbind 45 | 46 | 47 | ## Backwards Compatibility 48 | - The existent gas model stays the same while the new model is added. Therefore, there is no backward compatibility issue. 49 | - May not even require a custom UI/tools if standardized 50 | 51 | ## Test Cases 52 | TBD 53 | 54 | ## Implementation 55 | No implementation yet. 56 | 57 | ## Copyright 58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 59 | 60 | ## Reference 61 | - https://www.freecodecamp.org/news/universal-ethereum-delegated-transactions-no-more-ethereum-fees/ 62 | - https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf 63 | -------------------------------------------------------------------------------- /iip-11.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 11 3 | Title: Prevent replay attack by enabling chainID in IoTeX transaction 4 | Author: Dustin Xie (dustin.xie@iotex.io) 5 | Status: WIP 6 | Type: Standards Track 7 | Created: 2021-08-17 8 | ``` 9 | 10 | ## Abstract 11 | This document proposed a solution to prevent replay attack on the IoTeX blockchain 12 | 13 | ## Proposal 14 | A [`chainID`](https://github.com/iotexproject/iotex-proto/blob/master/proto/types/action.proto#L210) 15 | field is actually reserved in the IoTeX transaction structure, we could activate 16 | this field to mitigate potential replay attack by: 17 | 18 | 1. Use a different chain ID for mainnet and testnet when signing transactions 19 | 2. Enforce chain ID check at block producing, transaction with chain ID that is 20 | different from target network will be rejected 21 | 22 | So far the default `chainID` = 0, this change will take place in 2 phases: 23 | 1. A transitional period with a mix of the default and new chain ID, and 24 | transactions with `chainID` = 0 will still be accepted 25 | 2. At next hard-fork, chain ID check enforcement is activated. Only those 26 | transactions with new chain ID can be accepted, any transaction that carries 27 | `chainID` = 0 will be rejected 28 | > Chain ID for native transaction 29 | 30 | | Chain ID | Network | Endpoint | 31 | | --- | --- | --- | 32 | | 1 | Mainnet | api.iotex.one:443, api.iotex.one:80 | 33 | | 2 | Testnet | api.testnet.iotex.one:443, api.testnet.iotex.one:80 | 34 | 35 | ## Impact 36 | This change will impact all products and services that involve transaction 37 | processing on our mainnet and testnet, including: 38 | - Product/service that use antenna SDK: ioPay desktop/mobile, mimo/iotube, 39 | hermes, airdrop/drip 40 | - Product/service that integrates IoTeX into their own SDK: trustwallet 41 | - Crytpo exchanges: they might use our antenna or their own SDK, need to 42 | carefully understand each one's situation 43 | - Other components that I may miss 44 | 45 | ## Upgrade plan 46 | 1. Implement the chain ID in antenna SDK and iotex-core 47 | 2. Rollout to testnet, use ioctl to test and verify 48 | 3. Start transitional phase: 49 | 1. Rollout to mainnet (with hard-fork disabled) 50 | 2. Notify all impacted products/service/exchange to upgrade to new antenna 51 | SDK 52 | 3. Verify new transaction does have correct value for chain ID 53 | 4. Final enabling 54 | 1. Activate the hard-fork on testnet 55 | 2. Verify transaction process on testnet still working normally when chain 56 | ID check is enforced 57 | 3. Activate the hard-fork on mainnet 58 | 59 | ## Replay Attack Immunity 60 | The use of a different chain ID prevents replay attack between IoTeX mainnet 61 | and testnet. 62 | 63 | On the other hand, the raw hash of IoTeX native tx is computed as the keccak256 64 | hash of the tx's serialized data bytes, that is: 65 | ``` 66 | data = tx.Serialize() 67 | h = keccak256(data) 68 | ``` 69 | which is different from [EIP155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md#specification) 70 | specification, so the same tx will have different raw hash values when signing 71 | as native tx vs. signing as RLP-encoded (see [here](/iip-10.md)). Hence the 72 | proposed solution is also immune to replay attack targeted between the IoTeX 73 | and Ethereum blockchain. 74 | 75 | ## Copyright 76 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-1.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 1 3 | Title: Improving slashing policy enforced on underperforming delegates 4 | Author: Zhijie Shen (zhijie@iotex.io) 5 | Status: Draft 6 | Type: Standards Track 7 | Created: 2019-05-20 8 | ``` 9 | 10 | ## Abstract 11 | 12 | Currently, a delegate will lose all the epoch reward for the epoch where it misses 85% productivity threshold. We 13 | propose to replace this slashing policy with excluding the delegate for the next 3 epochs' block production and all 14 | kinds of reward to reduce the impact on IoTeX's quality of service (QoS) and motivate delegates to provide robust 15 | infrastructure. 16 | 17 | ## Motivation 18 | 19 | Sometimes we saw some delegate nodes were in unhealthy status (e.g., block height is no longer growing), so that it 20 | can't produce blocks if they are chosen as active consensus delegates in a certain epoch. This prolongs the confirmation 21 | latency for those transactions sent during the time slot of unhealthy delegates' block proposal rounds. Moreover, the 22 | unhealthy nodes would take more than one epoch's time to recover due to communication delay, diagnostics process and etc. 23 | 24 | Meanwhile, we have quite a few other good delegate nodes in the pool, which is ready to produce blocks but just doesn't 25 | have enough votes yet. 26 | 27 | Given the observations above, we are looking for the good mechanism to improve IoTeX's QoS as well as motivate delegates 28 | to provide robust infrastructure. 29 | 30 | ## Approach 31 | 32 | We propose to achieve this by using a new slashing policy. When a delegate misses 85% productivity threshold (aka misses 33 | 3+ out of 15 blocks), it will 1) be excluded from the consensus delegate pool for the next 3 epochs and 2) it will miss 34 | all kinds of rewards during this 3 epochs. 35 | 36 | Alternatively, the `X+1`-th delegate, where `X` is the number of consensus delegates, will be moved into consensus 37 | delegate pool, and have the change to be rolled as the active consensus delegate. 38 | 39 | Note that we have an existing slashing policy, which is skipping the epoch reward for the current epoch where 85% 40 | productivity threshold is missed. This policy will be removed once the new policy is enabled to keep the policy concise. 41 | 42 | By doing this, we could make that 1) IoTeX QoS could be less impacted while a delegate is repairing the node, and 2) the 43 | resource of the standby delegates could be leveraged. 44 | 45 | Last but not least, we propose 3 epochs because it seems to a reasonably enough time for a responsive delegate to 46 | recover the node. However, this number could be debatable. 47 | 48 | ## Implementation 49 | 50 | It needs to change [iotex-core](https://github.com/iotexproject/iotex-core/) to implement the new policy: 51 | 52 | - At the end of each epoch, a new productivity summary action should be processed so that all delegates should reach the 53 | consensus on the final productivity in the current epoch, and the productivity metrics will be written into the state DB. 54 | 55 | - When polling the consensus delegates for `X`-th epoch, check the productivity from `X-3`-th to `X-1`-th epochs. If a 56 | delegate misses the productivity threshold in anyone of these epochs, it will be remove from the list. 57 | 58 | - The current slashing policy implemented in the rewarding protocol needs to be removed. 59 | 60 | This is protocol level change, so that it will result in a hard fork. 61 | 62 | In addition to the protocol level change, we may also need to: 63 | 64 | - Provide API for delegates to check if they are slashed for some epochs; 65 | 66 | - Reflect the slashing results on the member portal so that the voters could be notified. 67 | 68 | ## Changelog 69 | 70 | 2019-05-20: Drafted the proposal of new productivity slashing policy -------------------------------------------------------------------------------- /iip-32.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 32 3 | Title: A new NFT based staking buckets 4 | Author: Coder Zhi (@CoderZhi) 5 | Discussions-to: 6 | Status: WIP 7 | Type: Standards Track 8 | Category Core 9 | Created: 2024-06-01 10 | ``` 11 | 12 | ## Abstract 13 | This IIP proposes a new system staking contract, which is an ERC721 contract. Each bucket will be represented as an NFT token and the buckets created in the new contract are of the same features as the native staking buckets. It will overcome the limitations of the current native staking protocol and enable the seamless integration of various DeFi projects, enhancing liquidity and flexibility for investors. 14 | 15 | ## Motivation 16 | The most commonly used buckets in IoTeX blockchain are native staking buckets. The native staking buckets are restricted in terms of tradability, as the native protocol does not support very complicated operations. This limitation reduces liquidity and restricts the potential use cases of staked assets in the DeFi ecosystem. 17 | 18 | Different from the previous version [IIP13](https://github.com/iotexproject/iips/blob/master/iip-13.md), in which investors could only choose some specific staking amount and duration combinations, this version allows investors to create buckets of any amount and any duration, as long as the amount is not less than a minimum value and the duration is not larger than a maximum value. With the same attribute restriction as the native staking buckets, the migration from the native staking buckets to the new NFT based buckets is easy to implement. 19 | 20 | The new staking contract will: 21 | * Improve accessibility: The ability to trade staking buckets lowers the entry barriers for new investors and allows for more efficient capital allocation within the ecosystem. 22 | * Enhance liquidity: By making staking buckets tradable, investors can easily buy, sell, and transfer their staked assets, increasing overall market liquidity. 23 | * Increase flexibility: NFT-based staking buckets can be used as collateral, integrated into DeFi platforms, and utilized in various financial products, providing greater flexibility and opportunities for investors. 24 | 25 | ## Specification 26 | The proposed smart contract will include the following key components: 27 | 28 | 1. Bucket creation 29 | When an investor stakes their coins, a corresponding NFT will be minted, representing the staked amount and duration. Similar to the native buckets, the staked amount should be larger than 100 IOTX and the maximum duration is 3 years. 30 | 31 | 2. Bucket modification 32 | Investors could transfer the ownership, lock/unlock the staking duration, expand a bucket by increasing staked amount and/or duration, merge multiple buckets into one, and unstake/withdraw buckets. 33 | 34 | 3. Staking rewards 35 | Staking rewards will continue to accrue to the holder of the NFT, ensuring that the rightful owner receives the benefits. The amount of rewards are the same as native staking buckets. 36 | 37 | 4. Donation 38 | Bucket owners could donate the staked amount to the beneficiary specified in the contract. 39 | 40 | 5. Security and Compliance 41 | Audit and Verification: The smart contract will undergo thorough security audits to ensure its robustness and reliability. 42 | Compliance: The system will adhere to relevant regulatory requirements, ensuring that it operates within legal frameworks. 43 | 44 | 6. Migration 45 | In the native protocol, migration from a native staking bucket to an NFT-based bucket will be supported. 46 | 47 | 48 | ## Backwards Compatibility 49 | The new system staking contract has no conflict with the existing staking system, thus it will be backwards compatible. 50 | 51 | ## Implementation 52 | The implemenation of this new system staking contract could be found in [github](https://github.com/iotexproject/iip13-contracts/blob/main/src/SystemStaking2.sol). 53 | 54 | ## Copyright 55 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-10.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 10 3 | Title: Support Web3.js APIs 4 | Author: Dustin Xie (dustin.xie@iotex.io) 5 | Status: WIP 6 | Type: Standards Track 7 | Created: 2021-03-29 8 | ``` 9 | 10 | ## Abstract 11 | This document proposed an improvement for IoTeX blockchain to support Web3.js APIs and integrate seamlessly with standard tools and dapps. 12 | 13 | ## Motivation 14 | Since its launch, IoTeX blockchain has its definition of APIs known as `Antenna`. As time goes by, we receive more and more requirements to have IoTeX blockchain to support commonly used tools and dapps such as metamask, truffle, remix, subgraph, etc.. 15 | 16 | ## Specification 17 | Four components are required to make this work: 18 | 19 | 1. A new proxy service that receives raw transaction encoded in RLP, translates it to IoTeX tx format and relays to IoTeX blockchain endpoint. Upon receiving the raw transaction, the proxy performs the following tasks: 20 | 1. decode the raw transaction, extract (nonce, gas price, gas limit, recipient, amount, payload) 21 | 2. extract the signature from the transaction 22 | 3. call IoTeX endpoint API to determine if the recipient is a regular address or contract 23 | 4. pack all into an IoTeX tx (transfer or execution depending on iii) using decoded data + signature in step 1 and 2 24 | 5. send the IoTeX transaction to the corresponding IoTeX blockchain endpoint 25 | 26 | 2. Protobuf support 27 | 1. A new field `uint32 encoding` is added to IoTeX transaction's protobuf definition to identify which network the transaction is targeting 28 | 2. `encoding = 1` indicates the transaction is encoded in RLP format, while `encoding = 0` (default value) is used by IoTeX native transaction 29 | 30 | 3. iotex-core support for transaction with `encoding = 1` 31 | 1. decode the transaction, extract (nonce, gas price, gas limit, recipient, amount, payload) 32 | 2. use these + node's external chain ID to reconstruct the raw transaction and compute the corresponding raw hash 33 | 3. verify signature from the transaction against the raw hash 34 | 4. reject the tx if verification fails 35 | 36 | 4. iotex-core support for global external chain ID 37 | 1. at the start-up of an IoTeX node/server, it will need to bind to an external chain ID to indicate which network this node is on. See table below 38 | 2. this global ID is used to compare against `externChainID` in the IoTeX transaction. A transaction with the wrong external chain ID will be rejected. 39 | 40 | > External chain ID 41 | 42 | | Chain ID | Network | Endpoint | 43 | | --- | --- | --- | 44 | | 4689 | Mainnet | api.iotex.one:443, api.iotex.one:80 | 45 | | 4690 | Testnet | api.testnet.iotex.one:443, api.testnet.iotex.one:80 | 46 | 47 | ## Replay Attack Immunity 48 | We require that the received raw tx (usually sent by Metamask) must be conforming 49 | to EIP-155 rules, and we registered distinct chain ID for IoTeX mainnet (4689) 50 | and testnet (4690). According to [EIP155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md#specification), 51 | same tx will have different raw hash values when signing with different chainid. 52 | Hence the proposed solution is immune to replay attack targeted between the IoTeX 53 | and Ethereum blockchain. 54 | 55 | If a raw tx does not conform to EIP-155, the corresponding raw hash won't be able 56 | to pass signature verification and the tx will simply be rejected. 57 | 58 | ## Backwards Compatibility 59 | This IIP introduces a new compatible type of on-chain transaction that does not exist before. Hence it is back-compatible with existing data on the chain; no hard-fork is needed. 60 | 61 | ## Implementation 62 | - The new proxy service - https://github.com/iotexproject/babel-api 63 | - iotex-core support - https://github.com/iotexproject/iotex-core/commit/6348f251bcc57b675cc97a660b0c795156be04df 64 | - External chain IDs registreation - https://github.com/ethereum-lists/chains/commit/5f49c91806717479ac72cbbc0fd0028c24c69239 65 | 66 | ## Copyright 67 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 68 | -------------------------------------------------------------------------------- /iip-40.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 40 3 | Title: Deprecate io1 Address Format 4 | Author: IoTeX Lab 5 | Type: Standards Track 6 | Category Core 7 | Created: 2024-10-22 8 | ``` 9 | 10 | ## Abstract 11 | 12 | This IIP proposes deprecating the native `io1...` address format in favor of the widely recognized Ethereum-compatible `0x...` format across the IoTeX ecosystem. After evaluating the pros and cons, we recommend a phased transition to enhance user experience, reduce confusion, and align with industry standards. 13 | 14 | ## Motivation 15 | 16 | In 2020, IoTeX added support for the Ethereum-compatible `0x...` address format along with support for the Ethereum API, facilitating interactions with users, developers, and third-party tools familiar with Ethereum. Currently, IoTeX supports both `io1...` and `0x...` address formats. While existing community members are accustomed to this duality, new users often face confusion, leading to errors and support issues. 17 | 18 | ## Proposal 19 | 20 | After evaluating the advantages and disadvantages of maintaining both address formats, to promote mass adoption and simplify onboarding, we propose deprecating the `io1...` format. 21 | 22 | ### Cons of Maintaining Both Formats 23 | 24 | 1. **User Confusion**: New users risk sending tokens to the wrong chain or are unsure how to proceed when withdrawing to wallets like MetaMask. 25 | 26 | 2. **Ledger App Issues**: Users must adapt between `io1...` and `0x...` formats, causing confusion about the destination network. 27 | 28 | 3. **Perceived Unauthorized Transfers**: Discrepancies between input and displayed addresses lead users to suspect unauthorized activities. 29 | 30 | 4. **Wallet Inconsistencies**: Different wallets using different formats hinder user migration and create confusion. 31 | 32 | 5. **ioPay Complexity**: Requiring users to select address formats adds unnecessary complexity. 33 | 34 | 6. **Inconsistent Address Display**: Seeing different address formats in explorers and tools degrades user experience. 35 | 36 | 7. **Complex Documentation**: Supporting both formats complicates guides and onboarding materials (both internal and external). 37 | 38 | ## Proposed Actions 39 | 40 | We propose that the IoTeX team takes the following actions to actively deprecate the use of the `io1` address format: 41 | 42 | 1. **Notify Existing Exchanges**: Request all exchanges that already support IOTX to update their withdrawal and deposit flows to use `0x...` addresses first when users select IoTeX as the destination chain. The `io1` option should be removed, or provided as an alternative only. 43 | 44 | 2. **Standardize New Exchanges**: Encourage new exchanges to adopt `0x...` addresses for deposits and withdrawals. 45 | 46 | 3. **Wallet Compatibility**: Advise new and existing wallets to treat IoTeX as an Ethereum-compatible chain from the outset. 47 | 48 | 49 | ## Impact 50 | 51 | Deprecating the `io1...` address format will streamline the user experience, reduce confusion, and lower the risk of errors. It aligns IoTeX with the broader blockchain ecosystem, making it more accessible to users familiar with Ethereum. While some legacy systems may require updates, the long-term benefits outweigh temporary inconveniences. 52 | 53 | **NOTE**: NO action is required for all `io1...` users, as these addresses are 100% interchangeable and share the exact same private key. If needed, the official address converter is available in the IoTeX Hub's tools tab, [here](https://hub.iotex.io/tools). Additionally, the `io1...` address format will remain available solely as an alternative for backward compatibility. 54 | 55 | ## Conclusion 56 | 57 | After careful evaluation, we propose deprecating the `io1...` address format in favor of the Ethereum-compatible `0x...` format in all IoTeX ecosystem tools and exchanges. This transition will enhance usability, promote adoption, and align IoTeX with industry standards. 58 | 59 | ## References 60 | 61 | Address Conversion Topic on the docs: [https://docs.iotex.io/builders/reference-docs/native-iotex-development/address-conversion](https://docs.iotex.io/the-iotex-stack/basic-concepts/address-conversion) 62 | -------------------------------------------------------------------------------- /iip-24.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 25 3 | Title: Raise Block Gas Limit to 50 Million 4 | Author: Coder Zhi (@CoderZhi), Dustin Xie (dustin.xie@iotex.io) 5 | Forum discussions: https://community.iotex.io/t/iip-24-raise-block-gas-limit-to-50m/11352 6 | Status: WIP 7 | Type: Standards Track 8 | Category: Core 9 | Created: 2024-01-23 10 | ``` 11 | 12 | ## Abstract 13 | This IIP proposes to raise the block gas limit of IoTeX blockchain to 50 million. 14 | 15 | ## Background 16 | The block gas limit is a crucial parameter for a blockchain network. It represents the maximum amount of gas, a unit of computational effort, that can be consumed in a single block. Gas is used to measure and allocate resources like computation and storage on the network. The block gas limit serves as a mechanism to control the overall capacity of a block, preventing it from becoming too large and ensuring the network's stability. 17 | 18 | Block gas limit directly impacts the blockchain's scalability and throughput. A higher gas limit allows more transactions and smart contract computations to be included in a single block, enhancing the network's throughput. However, setting the limit too high may lead to slower block time (too many txs in a block) and potential network congestion. Conversely, a lower gas limit can result in fewer transactions in each block and wasting the blockchain's capacity to handle a larger volume of transactions. Therefore, striking a balance in setting the block gas limit is crucial for maintaining a well-functioning and secure blockchain network. 19 | 20 | ## Motivation 21 | Currently, the IoTeX blockchain's gas limit is at 20 million. Given that the minimum gas for a standard transfer equals 10000, this means that the maximum number of transactions in a block is capped at 2000, which amounts to only 400TPS at 5-second block time. 22 | 23 | This TPS is not high enough to sustain use-cases where it is desired to accommodate a large number of transactions in a single block. For instance, periods of increased network activity, such as token sales, DeFi protocols experiencing high demand, special promotion or airdrop, complex smart contract calls requiring more gas to execute, etc. In particular, the recent inscription event has caused a large volume of transactions waiting in line to be executed and included into the IoTeX blockchain. A higher TPS would definitely help alleviate the situation. 24 | 25 | In all these scenarios, a higher gas limit is preferred to prevent network congestion and ensures timely execution of large amounts of transactions rushing into the blockchain. 26 | 27 | ## Specification 28 | The change will be introduced in the upcoming hard-fork. After the hard-fork block number, the block gas limit will be raised to 50 million. And with that, we'll have these new performance specs: 29 | ``` 30 | Max number of transactions in a block = 5000 31 | Max TPS = 1000 32 | ``` 33 | During the recent inscription event, our performance monitoring data show that most delegate nodes have a very low CPU and memory usage number of between 5-10% for a regular 8CPU and 16GB memory hardware configuration. So raising block gas limit to 50M would allow us to lift the IoTeX blockchain's processing capability to the next level, while not jeopardizing the entire network's stability. 34 | 35 | ## Rationale 36 | The change aims to boost the IoTeX network's processing capacity. It will be implemented in the upcoming hard-fork. 37 | 38 | ## Backwards Compatibility 39 | This feature will be enabled in the upcoming hard-fork, so backward compatibility is maintained. 40 | 41 | ## Test Cases 42 | To verify the IIP, tests on IoTeX Testnet with the new setup are necessary: 43 | 1. All nodes should have 8 CPUs and 32GB memory 44 | 2. Modify the block gas limit of all nodes on the Testnet to 50 million 45 | 3. Inject three different types of transactions: 46 | 47 | 3.1 Pure transfers without payload, testing the tps upper bound 48 | 49 | 3.2 Compute-heavy transactions, testing node processing capabilities 50 | 51 | 3.3 A mixture of transfers and transactions, simulating normal cases 52 | 53 | Expected results: 54 | 1. Block gas is nearly used up 55 | 2. No delegates miss any blocks 56 | 3. Avergage block mint time and average block validation time are both around 1s or slightly higher 57 | 58 | Concerns about storage growth due to the larger block size may arise, so a larger disk size is recommended if necessary. 59 | 60 | ## Implementation 61 | A new field will be introduced in the blockchain config, indicating the hard fork height and the new block gas limit value after this hard fork. All delegates should upgrade their nodes before the hard fork. 62 | 63 | ## Security Considerations 64 | This IIP will elevate the IoTeX network's processing capacity to maximum TPS=1000. As discussed above, that number is well in the reach of most delegate's hardware configuration. The entire network's stability is not affected by introducing this IIP. 65 | 66 | ## Copyright 67 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-52.md: -------------------------------------------------------------------------------- 1 | ## IIP 52: BLS Signature Aggregation for Block Signature Compression 2 | 3 | ``` 4 | IIP: 52 5 | Title: BLS Signature Aggregation for Block Signature Compression 6 | Author: Seedlet (zhi@iotex.io), Chen Chen (chenchen@iotex.io) 7 | Type: Core 8 | Category: Core 9 | ``` 10 | 11 | ## Simple Summary 12 | 13 | This proposal introduces Boneh–Lynn–Shacham (BLS) signature aggregation to compress the set of validator signatures required for block finality into a single aggregated signature, thereby reducing the size of the block footer and improving block propagation efficiency. 14 | 15 | ## Abstract 16 | 17 | Currently, to finalize a block, the IoTeX consensus protocol requires more than 2/3 of selected delegates to sign it. These signatures are all stored individually in the block footer. Since each signature is ~65 bytes, this causes the block footer alone to consume over 2 KB, given that 24 consensus delegates participated, leading to large block sizes and slower propagation. 18 | 19 | This proposal introduces the use of BLS signature aggregation, which allows all individual signatures to be compressed into a single 96-byte signature, with one accompanying bitmap or list of participating signer indices. 20 | 21 | ## Motivation 22 | 23 | With this proposal, we achieve the following goals: 24 | 25 | * Reduce block size, especially in environments with high delegate count. 26 | 27 | * Improve network throughput and block propagation latency. 28 | 29 | * Make room for more transactions per block without increasing total size. 30 | 31 | * Future-proof consensus scalability as delegate numbers grow. 32 | 33 | ## Specification 34 | 35 | The implementation of this proposal will be split into two phases: 36 | 37 | 1. Collect BLS public keys of delegates. Since the current crypto curve (Secp256k1) differs from BLS12-381, delegates must submit their BLS public keys: 38 | 39 | * A new transaction type will be introduced for submitting BLS public keys. 40 | 41 | * A new field will be added to delegate registration transaction. 42 | 43 | 2. Trigger the usage of BLS in consensus. The delegates who haven't submit their BLS public keys will be excluded from the active consensus delegate set. 44 | 45 | ## Rationale 46 | 47 | * BLS aggregation compresses O(n) signatures to O(1), enabling scalability. 48 | 49 | * Signature verification is fast and constant-time. 50 | 51 | * Widely used in other blockchain platforms (e.g., Ethereum 2.0, Dfinity, Chia) to solve the same problem. 52 | 53 | * IoTeX already uses elliptic curve cryptography, and integration of BLS is a natural extension. 54 | 55 | #### Performance Analysis 56 | 57 | * Storage Efficiency 58 | 59 | |Metric|ECDSA|BLS|Improvement| 60 | | --- | --- | --- | --- | 61 | |**Individual Signature**|65 bytes|96 bytes|-47.7%| 62 | |**Block Footer (24 delegates)**|2,328 bytes|100 bytes|**95.7% reduction**| 63 | |**Composition**|24 × (32B pubkey + 65B sig)|4B bitmap + 96B agg sig|Storage optimization| 64 | |**Scalability**|O(n) linear growth|O(1) constant size|Future-proof| 65 | |**Bandwidth per Block**|2.3 KB signature data|0.1 KB signature data|**95.7% savings**| 66 | 67 | * Block Size: 2,228 bytes saved per block (95.7% reduction) 68 | 69 | * Network Efficiency: Dramatically reduced bandwidth usage during block sync 70 | 71 | * Future Scalability: Size remains constant regardless of delegate count increase 72 | * Computational Performance 73 | 74 | * Individual Operation Benchmarks 75 | 76 | |Operation|ECDSA (secp256k1)|BLS12-381|Performance Ratio| 77 | | --- | --- | --- | --- | 78 | |Sign|0.047ms|0.31ms|~6x slower| 79 | |Verify|0.063ms|0.78ms|~12x slower| 80 | |Aggregate Sign|N/A|0.38ms|N/A| 81 | |Aggregate Verify|N/A|1.45ms|N/A| 82 | 83 | * Sign operation of BLS is 6 times slower than ECDSA, but the impact is minimal due to the small absolute value. 84 | 85 | * If the verifications of signatures are run in parallel, the overall computation time to produce a BLS will be 1.16ms (0.78ms verification time + 0.38ms signature aggregation time). 86 | 87 | * The aggregated signature verification speed is 12 times slower than ECDSA, but the impact is also not significant compared to the overall block verification time. 88 | 89 | ## Backwards Compatibility 90 | 91 | This is a consensus-level change and is not backwards compatible. Two hardforks will be required: 92 | 93 | * One for phase 1, BLS public key submission. 94 | 95 | * Another for phase 2, activating BLS verification in consensus. 96 | 97 | ## Implementation 98 | 99 | * Use the BLS12-381 curve, same as Ethereum 2.0. 100 | 101 | * Leverage the BLST library, github.com/supranational/blst. 102 | 103 | * Introduce: 104 | 105 | * New transaction type for delegates to submit BLS public key. 106 | 107 | * New field, BLS public key, in delegate registration transaction. 108 | 109 | * New fields, `aggregated signature` and `signer bitmap`, in block footer. 110 | * Update explorer and ioctl to decode and display BLS signature. 111 | 112 | ### Copyright 113 | 114 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 115 | -------------------------------------------------------------------------------- /iip-31.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 31 3 | Title: Bridge Solana to IoTeX via ioTube 4 | Author: Haixiang (haixiang@iotex.io), Leo (leo@iotex.io) 5 | Status: WIP 6 | Type: Standards Track 7 | Created: 2024-05-21 8 | ``` 9 | 10 | ## Abstract 11 | The proposal details the integration of Solana with the ioTube bridge, enhancing DEPIN interoperability. It specifies on-chain contracts for sending and receiving assets, the ioTube Message Protocol for event communication, and off-chain witness consensus using secp256k1 and ed25519 elliptic curves, optimizing cost and performance. 12 | 13 | ## Motivation 14 | 15 | After integrating into EVM and Bitcoin ecosystem, Solana ecosystem is the next milestone for ioTube bridge. Bridging Solana and IoTeX chains will enhance interoperability between two leading DEPIN ecosystems, enabling seamless transfer of assets, data, and services. Once this bridge is complete, Solana DePIN tokens will be able to be bridged to the IoTeX L1. This allows Solana DePINs to expand their reach and benefit from IoTeX's large, global community. As an example of this, IoTeX's Liquidity Hub on the mimo DEX has had great success creating new liquidity pools for DePIN tokens on other chains (Polygon, Ethereum) and we look forward to offering this benefit to Solana DePIN projects. Enhanced interoperability will attract a broader user base, driving adoption and network effects while promoting the overall growth of the DEPIN sector. Additionally, as one of the public goods of IoTeX ecosystem, ioTube bridge is evolving to create a more interconnected and impactful DEPIN ecosystem, aligning with our mission of "DePIN for Everyone." 16 | 17 | 18 | ## Specification 19 | 20 | ## Onchain Contracts 21 | 22 | ### Methods of Sending Assets 23 | These methods enable blockchain clients to bridge assets from the source chain to the destination chain. User assets are locked in a token safe within the contract by the bridge, which can only be withdrawn by burning the wrapped assets on the destination chain. 24 | 25 | - Method on Solana Chain: 26 | 27 | ```rust 28 | pub fn process_bridge(program_id: &Pubkey, accounts: &[AccountInfo], amount: u64, to: &[u8]) -> ProgramResult 29 | ``` 30 | 31 | - Method on IoTex Chain: 32 | 33 | ```solidity 34 | function depositTo(address _token, address _to, uint256 _amount) public whenNotPaused payable 35 | ``` 36 | 37 | ### Methods of Receiving Assets 38 | These methods allow off-chain relayers of the bridge to submit proofs, confirmed by witnesses (oracles) regarding events emitted on the source chain, to the contract on the destination chain. Proofs are submitted automatically by relayers. Once verified, bridged assets are issued to the user's wallet (assets will be sent to users' associated token account on Solana). 39 | 40 | - Method on Solana Chain: 41 | 42 | ```rust 43 | pub fn process_settle(program_id: &Pubkey, accounts: &[AccountInfo], amount: u64) -> ProgramResult 44 | ``` 45 | 46 | - Method on IoTex Chain: 47 | 48 | ```solidity 49 | function submit(address cashier, address tokenAddr, uint256 index, address from, address to, uint256 amount, bytes memory signatures) public whenNotPaused 50 | ``` 51 | 52 | ## ioTube Message Protocol 53 | The ioTube Message Protocol is adopted by on-chain contracts of ioTube bridge as the format of emitted events to ensure interoperability between the IoTeX chain, the Solana chain, and off-chain witnesses: 54 | 55 | ``` 56 | Receipt struct { 57 | token Address, 58 | id Number, 59 | sender Address, 60 | recipient Address, 61 | amount Number, 62 | fee Number, 63 | } 64 | ``` 65 | 66 | ## Offchain witnesses concensus 67 | Solana-IoTeX bridge, leveraged on the [ioTube Bridge architecture](https://docs.iotube.org/introduction/overview-and-architecture), operates on the existing witnesses network with Solana client support. Once two-thirds of witnesses sign the event, a consensus is reached, and the relayer submits the data and signatures to the contract. When bridging assets from Solana to IoTeX, witnesses use the `secp256k1` elliptic curve to sign the data, which can be verified in EVM smart contracts; in the opposite direction, the `ed25519` elliptic curve is used. 68 | 69 | 70 | ## Rationale 71 | 72 | ### Workflow 73 | 74 | ![whiteboard_exported_image](https://github.com/iotexproject/iips/assets/55118568/c7520d37-8bc6-4618-a9b3-263ac44f84e8) 75 | 76 | 77 | ### Ed25519 Elliptic Curve 78 | 79 | The address of a Solana account is a public key lies on the `ed25519` curve. Therefore, to be seamlessly managed in the Solana program of the bridge, each off-chain witness possesses an `ed25519` private key as their identity. Additionally, Ed25519 signatures can be natively verified by the [system program](https://docs.solanalabs.com/runtime/programs#ed25519-program) `Ed25519SigVerify111111111111111111111111111`, significantly reducing the bridge's operational costs. 80 | 81 | 82 | 83 | ## Backward Compatibility 84 | 85 | The change will ensure seamless integration with existing infrastructure, including UI/UX enhancements to include a Solana option and compatibility with the smart contracts on IoTeX. 86 | 87 | ## Security Considerations 88 | 89 | There is no security concern. 90 | 91 | ## Copyright 92 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-29.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 29 3 | Title: Bridge Bitcoin to IoTeX via ioTube 4 | Author: Haixiang (haixiang@iotex.io) 5 | Status: WIP 6 | Type: Standards Track 7 | Created: 2024-02-13 8 | ``` 9 | 10 | ## Abstract 11 | 12 | This IIP proposes a bridge to facilitate the transfer of Bitcoin assets to the IoTeX network, enhancing the network's value and interoperability. It utilizes a multi-signature wallet managed by off-chain witnesses for securing asset on the Bitcoin network. The designed transactions on Bitcoin ensure compatibility with existing IoTeX contracts. 13 | 14 | ## Motivation 15 | 16 | The motivation for this proposal is twofold. First, by bridging Bitcoin to IoTeX, we aim to significantly increase IoTeX's Total Value Locked (TVL) by tapping into the vast assets of the Bitcoin market. This initiative aims to enhance the appeal and functionality of the IoTeX ecosystem for IoTeX users, while also indirectly engaging Bitcoin users in the development of DEPIN projects and ecosystems. By doing so, it seeks to significantly increase liquidity across these projects. Establishing the IoTeX network as a fundamental hub for DEPIN project liquidity is identified as one of its key roles. Second, the unique challenges presented by Bitcoin's limited programmability and the lack of open-source bridging solutions necessitate the development of a custom solution. This effort will not only provide IoTeX with a direct link to Bitcoin market but also demonstrate our capability to innovate and expand the blockchain's functionality. 17 | 18 | 19 | ## Specification 20 | 21 | ### Legit BTC Transaction format 22 | 23 | #### From sender to mulsig wallet 24 | 25 | The `output` Field should be exquisitely constructed for assets bridged to IoTex via ioTube: 26 | 27 | 1. Output 1 28 | 29 | PkScript: A taproot Address held by multiple signers. 30 | 31 | Amount: the amount to be bridged from the user 32 | 33 | 2. Output 2 34 | 35 | PkScript: OP_RETURN + (BINARY DATA) 36 | 37 | Amount: 0 38 | 39 | - Notes: 40 | 41 | The ETH ADDR of receiver is encoded in the binary data: 42 | 43 | | | Content | Type | Data Length (in Bytes) | 44 | |-------------------|--------------------------------|-------------|------------------------| 45 | | Opcode | OP_DATA_35(0x23) | - | 1 | 46 | | Protocol Name | "iotube" | String | 6 | 47 | | Data byte | 1(0x01) | Uint8 | 1 | 48 | | Index of Transfer | index in LittleEndian | Uint32 | 4 | 49 | | Token Recipient | Address of wrapped btc mint to | ETH Address | 20 | 50 | | Index of Tip | index in LittleEndian | Uint32 | 4 | 51 | | Total | | | 36 | 52 | 53 | 54 | The expected length of PkScript is 37. 55 | 56 | 3. Output 3 57 | 58 | PkScript: the taproot Address same as output 1 59 | 60 | Amount: A tip to the bridge 61 | 62 | 4. Output 4 (Optional) 63 | 64 | Change back to the sender 65 | 66 | #### From mulsig wallet to BTC recipient 67 | 68 | It is a P2TR transaction from mulsig wallet to BTC recipient 69 | 70 | 71 | ## Rationale 72 | 73 | ### Workflow 74 | 75 | ![whiteboard_exported_image](https://github.com/iotexproject/iips/assets/55118568/da1c1a40-9897-4473-9392-a4fb0d903949) 76 | 77 | ### Signature Scheme 78 | 79 | MuSig2 is a multi-signature scheme that allows multiple signers to create a single aggregate public key and cooperatively create ordinary Schnorr signatures valid under the aggregate public key. Signing requires interaction between all signers involved in key aggregation. (MuSig2 is a n-of-n multi-signature scheme and not a t-of-n threshold-signature scheme.) 80 | 81 | More details could be found in [BIP 327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki) and [Musig2 paper](https://eprint.iacr.org/2020/1261.pdf) 82 | 83 | ### Bitcoin Script 84 | 85 | With the support of aggregated schnorr signature, Pay-to-Taproot (P2TR) script is used to transfer assets from custody wallet to bridged wallet. Other benefits P2TR scripts bring include cheaper output spending and security upgrade. 86 | 87 | 88 | ## Example 89 | 90 | Examples of transactions bridging Satoshi between the Bitcoin testnet and the IoTeX testnet are provided to illustrate the bridge's functionality: 91 | 92 | - 600 satoshis are bridged from bitcoin testnet to iotex testnet 93 | 94 | https://mempool.space/testnet/tx/8775c76728b87c4814f9e88f85bd5e84f5c5b2592720017869c73aee6682bbbb 95 | 96 | - 200 satoshis are bridged back to the wallet on bitcoin testnet 97 | 98 | https://mempool.space/testnet/tx/84105c89eb65f236984dcc4f9781304276099672155f1596b4c8004a12046b58 99 | 100 | ## Backward Compatibility 101 | 102 | The change will ensure seamless integration with existing infrastructure, including UI/UX enhancements to include a Bitcoin option and compatibility with the smart contracts on IoTeX. 103 | 104 | ## Security Considerations 105 | 106 | There is no security concern. 107 | 108 | ## Copyright 109 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-49.md: -------------------------------------------------------------------------------- 1 | # IIP-49: Enhancing Block Rewards Allocation with EIP-1559 Priority Fees 2 | 3 | **Title:** Enhancing Block Rewards Allocation with EIP-1559 Priority Fees 4 | **Author:** Dustin Xie 5 | **Last update:** 2025/4/3 6 | **Discussion Link:** TBD 7 | **Github Link:** TBD 8 | 9 | --- 10 | 11 | ## Abstract 12 | 13 | Starting from IoTeX v2.1.0, the blockchain has integrated EIP-1559 transactions, introducing priority fees that are awarded to block producers. Currently, block producers receive a fixed block reward of 8 IOTX plus any additional priority fees included in transactions. 14 | 15 | To improve the sustainability of the rewarding pool, this proposal modifies block reward allocation by incorporating priority fees into the fixed 8 IOTX reward mechanism. Specifically: 16 | 17 | 1. If the total priority fee is below 8 IOTX, the rewarding pool contributes the difference (8 - priority fee) to maintain an 8 IOTX total block reward. 18 | 2. If the priority fee exceeds 8 IOTX, the rewarding pool does not contribute more, and the block producer receives the full priority fee amount. 19 | 20 | This ensures that higher network activity reduces reliance on the rewarding pool, slowing its depletion over time. 21 | 22 | --- 23 | 24 | ## Motivation 25 | 26 | The IoTeX blockchain currently distributes a fixed 8 IOTX per block from the rewarding pool, regardless of network activity. However, the integration of EIP-1559 priority fees in recent v2.1.0 hard-fork introduces an opportunity to adjust block rewards dynamically, reducing unnecessary token emissions. 27 | 28 | By using priority fees as part of the block reward, we achieve the following benefits: 29 | 30 | - Extend the lifespan of the rewarding pool by reducing the amount withdrawn per block when network activity is high. 31 | - Encourage validator participation by ensuring block producers receive fair compensation, especially during periods of high transaction volume. 32 | - Maintain network security by preserving an incentive structure that rewards active validators. 33 | 34 | --- 35 | 36 | ## Specification 37 | 38 | ### Current Block Reward Mechanism 39 | 40 | - Block producers receive a fixed 8 IOTX reward from the rewarding pool. 41 | - Priority fees from EIP-1559 transactions are added on top of this fixed reward. 42 | - No adjustments are made based on network activity. 43 | 44 | ### Proposed Block Reward Mechanism 45 | 46 | 1. Total block reward remains capped at 8 IOTX, unless the priority fee exceeds 8 IOTX. 47 | 2. If the priority fee is below 8 IOTX, the rewarding pool contributes the difference (8 - priority fee) to make a total of 8 IOTX block reward. 48 | 3. If the priority fee is 8 IOTX or more, the rewarding pool does not contribute more, and the block producer receives the full priority fee amount instead. 49 | 50 | ### Example Scenarios 51 | 52 | | Priority Fee (IOTX) | Rewarding Pool Contribution (IOTX) | Total Block Reward (IOTX) | Notes | 53 | |---------------------|-------------------------------------|----------------------------|-----------------------------------------| 54 | | 0 | 8 | 8 | Full reward from pool | 55 | | 3 | 5 | 8 | Partial priority fee + pool top-up | 56 | | 7.5 | 0.5 | 8 | Minimal pool contribution | 57 | | 8 | 0 | 8 | All reward from priority fee | 58 | | 10 | 0 | 10 | Priority fee exceeds 8, no pool needed | 59 | 60 | --- 61 | 62 | ## Rationale 63 | 64 | - **Sustainability:** The rewarding pool depletes at a slower rate, ensuring long-term economic viability. 65 | - **Fair Compensation:** Block producers receive the same minimum reward (8 IOTX), but can earn more when network activity is high. 66 | - **Scalability:** As more transactions generate priority fees, the need for direct token emissions decreases. 67 | 68 | --- 69 | 70 | ## Implementation 71 | 72 | This will be implemented as a hard-fork, with changes activated at the next hard-fork height: 73 | 74 | - Modify the block reward calculation logic to adjust the rewarding pool allocation dynamically based on priority fees. 75 | - Update IoTeX consensus nodes to enforce the new reward distribution model. 76 | - Ensure backward compatibility with existing reward structures for a smooth transition. 77 | 78 | --- 79 | 80 | ## Backward Compatibility 81 | 82 | This proposal does not affect existing transactions or smart contracts. It solely modifies how block rewards are allocated starting at the next hard-fork height, ensuring backward-compatible integration into the current IoTeX economic model. 83 | 84 | --- 85 | 86 | ## Security Considerations 87 | 88 | - The proposal does not introduce new attack vectors or affect existing consensus mechanisms. 89 | - Block producers continue to receive fair rewards, maintaining network security. 90 | - As a result of this change, the rewarding pool will be depleting at a slower rate, ensuring long-term economic sustainability. 91 | 92 | --- 93 | 94 | ## Conclusion 95 | 96 | By incorporating priority fees into block rewards, this proposal enhances IoTeX’s economic sustainability while maintaining strong incentives for block producers. The rewarding pool depletes at a slower rate, allowing IoTeX to sustain validator rewards for a longer period, even as transaction volume grows. 97 | -------------------------------------------------------------------------------- /iip-28.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 28 3 | Title: Transfer Delegate Ownership 4 | Author: Simone Romano (simone@iotex.me), Dustin (dustin.xie@iotex.me), Chen Chen (chenchen@iotex.me) 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2024-06-01 9 | ``` 10 | 11 | ## Abstract 12 | 13 | This IIP introduces the "Transfer Delegate Ownership" feature to the IoTeX L1. The feature allows delegate owners to change a delegate's profile address to a new one. This offers several benefits, including the ability to transfer their delegate business to another entity, switch between wallet setups, and improve security by addressing potential account compromises. 14 | 15 | ## Motivation 16 | 17 | The motivation behind this feature is to offer increased flexibility and security to delegate owners of the IoTeX L1. Currently, there is no way to update a delegate's profile address once it is set. This limitation hinders adapting to changing circumstances, such as transferring a delegate to a new owner, switching between wallet setups (e.g., Ledger native app to Metamask), or addressing security concerns from a compromised profile account. 18 | 19 | ## Overview 20 | 21 | The "Transfer Delegate Ownership" feature will allow delegate owners to change the profile address associated with their delegate. This feature will provide the following benefits: 22 | 1. Delegate Ownership Transition: Delegate owners can easily transfer entire ownership of their delegate to another entity or individual by updating the profile address. 23 | 2. Wallet Setup Flexibility: Delegate owners who initially set up their profiles using specific wallet configurations, such as Ledger + ioPay desktop, can now transition to different setups, such as Metamask, or Metamask+Ledger. 24 | 3. Security Enhancement: In cases where a delegate owner suspects their profile address has been compromised, they can promptly change it to mitigate potential risks. 25 | 26 | ## Specification 27 | 28 | The ownership transfer will be implemented by sending a new type of transaction to the IoTeX L1. This will validate the transaction and apply the state change it indicates. For the delegate who intends to transfer ownership, they first construct a message that articulates their intention: 29 | 30 | ### Delegate ID 31 | We introduce a new field ID as the unique identifier for delegate. It is determined when the node is created (equal to the owner address) and remains unchanged thereafter. The voting address for the stake bucket needs to be set to the ID, rather than the owner. 32 | ``` 33 | type Delegate { 34 | Name string 35 | Owner address.Address 36 | Operator address.Address 37 | Rewarding address.Address 38 | // newly added fields 39 | ID address.Address 40 | } 41 | ``` 42 | 43 | ### Ownership Transfer Transaction 44 | We also introduce a new type of transaction that allows node owners to transfer ownership through this transaction. 45 | ``` 46 | type transferOwner struct { 47 | NewOwner address.Address // the new owner address 48 | } 49 | ``` 50 | 51 | ### Owner Limitation 52 | - Can only be registered once: Once an address has been registered, it cannot be used as a new owner for other nodes. 53 | - Can be transferred multiple times: If an address has not been registered, it can be transferred multiple times, but cannot simultaneously be the owner of multiple nodes. 54 | 55 | ### Self-Stake & Endorsement Inheritance 56 | - If the delegate is self-staked, after transferring ownership, the self-staked bucket will then convert to a regular bucket, and the delegate will no longer be self-staked. 57 | - If the delegate is endorsed, the endorsement remains valid after the ownership transferred. 58 | 59 | ### Votes counting 60 | Initially, we used the delegate's owner as the voting address, but now we have switched to using the ID as the voting address. This change maintains compatibility as the default value of ID is the owner. The reasons for this can be explained in the following two scenarios: 61 | - For existing nodes and stake buckets, this change does not affect the votes counting because the ID defaults to being equal to the owner address. 62 | - For nodes that have transferred ownership, since the ID remains unchanged and still equals the old owner, all previous bucket voting remains accurate. 63 | 64 | ## Rationale 65 | 66 | ### Difference between ID and Owner 67 | - The ID serves as the unique identifier for the delegate, it will never change, and is used to as identification of bucket voting. (This replaces the role previously held by the owner) 68 | - Owner now only denotes ownership, meaning only the owner has authority over delegate-related operations. It is modifiable. 69 | 70 | ### Why cann't the owner register multiple times although ownership transferred? 71 | This is to prevent user confusion. If allowing the same owner to re-register after a transfer, it could lead to a situation where the owner of one delegate is the ID of another delegate node, causing users to be confused about which delegate they are voting for. 72 | 73 | ### Impact 74 | The introduction of the "Transfer Delegate Ownership" feature will have a positive impact on the IoTeX community. It will empower delegate owners with greater control and flexibility over their delegate profiles, potentially encourage more participation in the network, and enhance the overall security of delegate operations. 75 | 76 | ## Backwards Compatibility 77 | We ensure backward compatibility at the protocol level by setting the default value of the delegate ID to be equal to the owner address. 78 | 79 | ## Security Considerations 80 | There is no security concern. 81 | 82 | ## Copyright 83 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 84 | -------------------------------------------------------------------------------- /iip-15.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 15 3 | Title: Sharing of Gas-fee with DApps (SGD) 4 | Author: iotex-core 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2023-03-01 9 | ``` 10 | 11 | ## Abstract 12 | This IIP proposes to share part of the transaction gas-fees with DApp developers to promote a vigorous cycle of token economics. 13 | 14 | ## Motivation 15 | All blockchain platforms thrive through the success of their DApp creators. We should reward high-quality creators on IoTeX in a sustainable way so as to bring more activities to our chain. 16 | Sharing of Gas-fee with DApps, or SGD for short, is an opt-in fee splitting model that revenue-share with the DApp developers a percentage of any transaction gas fee paid to the network when users interact with their dApps on IoTeX. 17 | To attract and retain quality DApps, and discourage lower quality reward seekers, the IoTeX Foundation will implement a review process for DApps applying to the revenue sharing program. The Foundation will approve DApps based on transaction volume, time deployed on chain and make a final determination. More details below. 18 | 19 | ## Flow 20 | 21 | 1. To opt into SGD, developers must first deploy their smart contracts 22 | 2. After that, the developers register the DApp contracts on the SGD registry portal by providing the DApp's contract address and the address to receive the reward. It will be a contract call (with the front-end hosted on [https://developers.iotex.io](https://developers.iotex.io), signed by the contracts' deployer address. 23 | 24 | ![flow](./assets/iip-15-flow.jpg) 25 | 26 | 3. When users started to use the DApp, gas-fee from those DApp activities accrues gradually and automatically in the SGD treasury every time a transaction is made, as shown in the illustration above. As a good starting point, we advocate that 30% of the gas-fee gets re-allocated to the SGD treasury, while the rest remains in PoS rewarding pool as usual. The actual ratio may be subject to later adjustment by governance voting process. 27 | 28 | 4. The DApp owner can withdraw this revenue from the SGD treasury by sending a claim action. The SGD treasury will check the SGD registry to verify the eligibility criteria, and issue the reward if criteria are met. 29 | 30 | ## Components 31 | 32 | ### SGD Treasury 33 | 34 | Treasury is a module in the IoTeX protocol stack that manages the SGD rewarding balance accounting and claiming. Each time an SGD contract is called, the shared gas-fee will be credited to corresponding owner's account. When DApp owner comes to claim the reward, it checks the SGD registry to verify the eligibility criteria, and issues the reward if criteria are met. 35 | 36 | ### SGD Registry 37 | 38 | The registry consists of 2 parts: a system contract and an indexer. 39 | The system contract is used by DApp owners to register the contract address and reward address (the address they want to receive the reward). After a DApp is deployed, the owner calls this contract to indicate they want to participate in the SGD program, and register the corresponding reward address. The registration will be reviewed and needs to be approved by the IoTeX foundation (see Eligibility Criteria below) 40 | The SGD indexer keeps track of the SGD contract address, its owner (who deployed the contract), and accumulated number of contract calls to the SGD contract. It provides the following functionalities: 41 | 42 | 1. When a new contract is deployed, the contract address and its owner will be recorded 43 | 2. It also keeps track of how many times a contract has been called. Whenever a contract call is made to a contract, it increments that number. 44 | 3. Given a contract address, it provides API to query the owner and how many times the contract has been called (something to be considered in the future) 45 | 46 | Data provided by SGD indexer will be used to determine whether a contract is eligible to receive SGD reward. See the section below. 47 | 48 | ### Eligibility Criteria 49 | 50 | Without standards or a comprehensive review process, revenue sharing of gas-fee could incentivize spam, clunky DApps, and other gas extraction loopholes. The IoTeX Foundation will review the DApp's registration request, rate its fitness to the program according to the time it has been deployed on the chain, its transaction volumes, and render a final decision as to approve the DApp or not. To kick-start the program, the initial conditions are set as follows. These may be subject to later adjustment by governance voting process. 51 | 52 | - Completed a total of 100,000 or more transactions on IoTeX L1 53 | - The DApp has been deployed and running normally for 1 month or above on the IoTeX blockchain 54 | - DApp application reviewed and approved by the IoTeX Foundation 55 | 56 | In case the DApp has incurred spam transactions or illegitimate activities (for example, but not limited to, fraud, rug-pull, attempt to attack user's token/fund, gas extraction, etc.), the IoTeX Foundation reserves the right to immediately dis-approve the involved DApp in the SGD program, and blacklist the involved owner/address in future programs. 57 | 58 | ## Rationale 59 | 60 | This feature implementation consists of the following parts: 61 | 1. SGD treasury to manage the gas-fee distribution, accounting, and claim process for SGD gas fee 62 | 2. SGD registry to handle the SGD contract approval, qualification, and share percentage calculation 63 | 64 | And it will be enabled in future hard-fork. 65 | 66 | ## Backwards Compatibility 67 | 68 | This feature will be enabled in the upcoming hard-fork, so backward compatibility is maintained. 69 | 70 | ## Security Considerations 71 | 72 | ## Copyright 73 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-12.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 12 3 | Title: Support staking transactions via JSON-RPC 4 | Author: Haixiang Liu(haixiang@iotex.io), Dustin Xie (dustin.xie@iotex.io) 5 | Status: Final 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2022-05-25 9 | ``` 10 | 11 | ## Abstract 12 | 13 | This proposal explains the mechanism of supporting staking transactions via JSON-RPC 14 | 15 | ## Motivation 16 | 17 | With the growth of eco-system of IoTeX, the demand for staking via `Ethereum-compatible way` is increasing, so we decided to support it in `web3.js` for our API node. Currently, staking-related features are only available in IoTeX `Antenna` SDK, who sends native staking transactions to the API nodes via gRPC protocol. However, transaction transmission via JRPC(ethereum-based) is incompatible with our staking transaction transmission via gRPC. This is because the data structure of native ethereum transaction only contains six data fields(`AccountNonce`, `Price`, `GasLimit`, `Recipient`, `Amount`, `Payload`), whereas our staking transactions include some extra data fields(e.g. `staking candidate`, `staking amount`, etc.). So it is hard to send our native staking transactions directly via JSON-RPC. 18 | 19 | ## Specification 20 | 21 | The discussion will be divided into two parts: 22 | 23 | 1. How are staking transactions sent to IoTeX blockchain via JSON-RPC? 24 | 25 | 2. How are staking transactions via JSON-RPC verified? 26 | 27 | ### Part I: Transaction Transmission 28 | 29 | #### Transaction Creation (Encode Staking Transaction) 30 | 31 | To send native staking transactions via JSON-RPC, RLP encoding is used for serializing staking transactions into binary data, which is packed into `Payload` field of native transaction `tx.payload = ABI.Pack(stakingAction)`. To differentiate special staking transactions from normal ethereum transactions, the special `Recipient` address `0x04C22AfaE6a03438b8FED74cb1Cf441168DF3F12` is reserved for this special treatment. To conclude, the modified transactions from staking transactions via JSON-RPC are different in three fields: 32 | 33 | ``` 34 | { 35 | Payload : ABI.Pack(stakingAction), 36 | Recipient : "0x04C22AfaE6a03438b8FED74cb1Cf441168DF3F12", 37 | Amount : 0, 38 | } 39 | ``` 40 | 41 | 42 | 43 | #### Transaction Forwarding (Decode Staking Transaction) 44 | 45 | IoTeX blockchain has its own JSON-RPC API service. When staking transactions are sent via `eth_sendRawTransaction` method, the API service will translate staking transactions in three steps: 46 | 47 | 1. Decoding raw transaction data 48 | 49 | The six data fields of the native transaction are extracted from the raw transaction 50 | 51 | 2. Check whether the recipient address is the special staking address `0x04C22AfaE6a03438b8FED74cb1Cf441168DF3F12` 52 | 53 | 3. Reconstruct native staking transactions by deserializing the data in `Payload` field with pre-defined `ABI` 54 | 55 | 56 | ```js 57 | // Example (pseudocode) 58 | // reconstruct a stake create transaction for binary data 59 | data := ABI.Unpack(rawData); 60 | CreateStake := CreateStake{ 61 | candidateName: data["candName"], 62 | stakedAmount: data["amount"], 63 | stakedDuration: data["duration"], 64 | autoStake: data["autoStake"], 65 | payload: data["data"], 66 | }; 67 | ``` 68 | 69 | 4. Send generated native staking transactions to the p2p network. 70 | 71 | ### Part II: Transaction Verification 72 | 73 | When IoTeX delegates receive the special staking transaction, It will use the signature in the transaction for verification. However, the hash of the staking transaction can't be directly used to verify the signature of the raw transaction. The staking transaction has to be encoded into the ethereum transaction using the same method mentioned in Part I. Then the hash calculated from the generated raw transaction can be used to verify the signature. 74 | 75 | ## Reference Implementation 76 | 77 | Since the `Recipient` address `0x04C22AfaE6a03438b8FED74cb1Cf441168DF3F12` is a virtual contract address, native staking actions aren’t supported when interacting from other contracts. However, Ethereum-compatible transactions to API nodes from clients can be translated into native staking actions under this proposal. 78 | 79 | Fristly, virtual contract setup: 80 | 81 | ```jsx 82 | 83 | const ethers = require('ethers'); 84 | 85 | // The Contract interface 86 | const abi = require("./iip-12-abi.json"); 87 | 88 | // Connect to the network 89 | const provider = new ethers.JsonRpcProvider('https://babel-api.mainnet.iotex.io'); 90 | 91 | // The virtual contract address for native staking 92 | let contractAddress = "0x04c22afae6a03438b8fed74cb1cf441168df3f12"; 93 | 94 | // A Signer from a private key 95 | let privateKey = ''; 96 | let wallet = new ethers.Wallet(privateKey, provider); 97 | 98 | // Contract Setup 99 | let contract = new ethers.Contract(contractAddress, abi, provider); 100 | ``` 101 | 102 | A list of examples to stake natively: 103 | 104 | - Creating a native staking bucket 105 | 106 | ```jsx 107 | 108 | async function createStake() { 109 | let tx = await contract.createStake( 110 | "", // Candidate's Name 111 | BigInt("100000000000000000000"), // Stake amount: Minimum 100 IOTX 112 | 100, // Number of days 113 | true, // Autostake 114 | [] // null 115 | ); 116 | console.log(tx.hash); 117 | } 118 | 119 | createStake(); 120 | ``` 121 | 122 | ## Copyright 123 | 124 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 125 | 126 | ## Appendix 127 | 128 | ABI (iip-12-abi.json) is provided under [assets folder](assets/iip-12-abi.json) -------------------------------------------------------------------------------- /iip-X.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 3 | Title: 4 | Author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> 5 | Discussions-to: 6 | Status: Draft 7 | Type: 8 | Category (*only required for Standard Track): 9 | Created: 10 | Requires (*optional): 11 | Replaces (*optional): 12 | ``` 13 | 14 | 15 | This is the suggested template for new IIPs. 16 | 17 | Note that an IIP number will be assigned by an editor. When opening a pull request to submit your IIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. 18 | 19 | The title should be 44 characters or less. 20 | 21 | ## Simple Summary 22 | 23 | If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the IIP. 24 | 25 | ## Abstract 26 | 27 | A short (~200 word) description of the technical issue being addressed. 28 | 29 | ## Motivation 30 | 31 | The motivation is critical for IIPs that want to change the IoTeX protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the IIP solves. IIP submissions without sufficient motivation may be rejected outright. 32 | 33 | ## Specification 34 | 35 | The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current IoTeX Network. 36 | 37 | ## Rationale 38 | 39 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> 40 | 41 | ## Backwards Compatibility 42 | 43 | All IIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The IIP must explain how the author proposes to deal with these incompatibilities. IIP submissions without a sufficient backwards compatibility treatise may be rejected outright. 44 | 45 | ## Test Cases 46 | 47 | Test cases for an implementation are mandatory for IIPs that are affecting consensus changes. Other IIPs can choose to include links to test cases if applicable. 48 | 49 | ## Implementation 50 | 51 | The implementations must be completed before any IIP is given status "Final", but it need not be completed before the IIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. 52 | 53 | ## Copyright 54 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # What is a IIP? 2 | 3 | IIP stands for IoTeX Improvement Proposal. An IIP is a design document providing information to the IoTeX community, or 4 | describing a new feature for IoTeX or its processes or environment. The IIP should provide a concise technical 5 | specification of the feature and a rationale for the feature. 6 | 7 | We intend IIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and 8 | for documenting the design decisions that have gone into IoTeX. The IIP author is responsible for building consensus 9 | within the community and documenting dissenting opinions. 10 | 11 | Because the IIPs are maintained as text files in a versioned repository, their revision history is the historical record 12 | of the feature proposal. 13 | 14 | # IIP Types 15 | 16 | There are three kinds of IIP: 17 | 18 | - A Standards Track IIP describes any change that affects most or all IoTeX implementations, such as a change to the 19 | network protocol, a change in block or transaction validity rules, or any change or addition that affects the 20 | interoperability of applications using IoTeX. 21 | 22 | - An Informational IIP describes an IoTeX design issue, or provides general guidelines or information to the IoTeX 23 | community, but does not propose a new feature. Informational IIPs do not necessarily represent an IoTeX community 24 | consensus or recommendation, so users and implementors are free to ignore Informational IIPs or follow their advice. 25 | 26 | - A Process IIP describes a process surrounding IoTeX, or proposes a change to (or an event in) a process. Process IIPs 27 | are like Standards Track IIPs but apply to areas other than the IoTeX protocol itself. They may propose an 28 | implementation, but not to IoTeX's codebase; they often require community consensus; unlike Informational IIPs, they are 29 | more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, 30 | changes to the decision-making process, and changes to the tools or environment used in IoTeX development. Any meta-IIP 31 | is also considered a Process IIP. 32 | 33 | # IoTeX Improvement Proposal (IIP) Lifecycle 34 | 35 | ## 1. Draft 36 | - An initial specification is written by the proposer. 37 | - At this stage, the IIP is informal and subject to major revisions. 38 | 39 | ## 2. Community Review 40 | - The proposal is shared in the **IoTeX Community Forum** for open discussion. 41 | - Feedback is collected from the community, developers, and stakeholders. 42 | - The author may revise the draft based on input. 43 | 44 | ## 3. Under Voting 45 | - Once matured, the IIP is submitted for **on-chain governance voting** via the **IoTeX Hub**. 46 | - Voting determines whether the IIP proceeds to implementation or is rejected. 47 | - **If passed** → moves to Implementation. 48 | - **If rejected** → moved to Archive. 49 | 50 | ## 4. Implementation 51 | - Technical work is carried out (usually in the next scheduled hardfork). 52 | - This includes development, testing, and integration of the proposal into **IoTeX L1 Core**. 53 | 54 | ## 5. Live 55 | - The IIP becomes active on mainnet and part of IoTeX’s protocol. 56 | - At this stage, the proposal is considered complete. 57 | 58 | ## 6. Archive 59 | - IIPs that are rejected, deprecated, or made obsolete are moved into the archive for historical reference. 60 | 61 | whiteboard_exported_image 62 | 63 | 64 | ## IIP Formats and Templates 65 | 66 | IIPs should be written in markdown format, and the file should be named `iip-X.md`, where `X` is IIP number. Image files 67 | should be included `assets/iip-X` folder. When linking to an image in the IIP, use relative links such as 68 | `assets/iip-X/image.png`. 69 | 70 | Each IIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers 71 | marked with `*` are optional and are described below. All other headers are required. 72 | 73 | ``` 74 | IIP: 75 | Title: 76 | Author: 77 | * Discussions-To: 78 | Status: 79 | Type: 80 | Created: 81 | * Replaces: 82 | * Superseded-By: 83 | * Resolution: 84 | ``` 85 | 86 | Refer to the [example](iip-X.md) for details. 87 | 88 | ## Process of creating a new IIP 89 | 90 | 1) Review the IIPs public repo 91 | This will help you ensure that your idea is unique and has not already been proposed or discussed. It will also give you an idea of the standard of other successful proposals. 92 | 93 | 2) Determine the next IIP number: To avoid conflicts, find the current latest IIP and use the next number for your proposal (don't forget to check any PRs with pending proposals). 94 | 95 | 3) Draft your proposal: Try using the same format as the existing IIP documents you find the repository to draft yours. When in doubt, feel free to reach out to any IoTeX team member on Discord, on X, Telegram, or on the community forum. Not sure where to look? 96 | Start here: https://iotex.io 97 | 98 | 4) Submit for discussion: Once your proposal is ready, post it to the IoTeX Community Forum for discussion under the Governance Proposals category: https://community.iotex.io/c/governance-proposals 99 | 100 | 5) Voting and implementation: Based on the feedback received, you may need to make revisions to your proposal. Once the IIP is finalized, it will go through community voting on the IoTeX Governance Hub at: https://hub.iotex.io/governance 101 | 102 | 6) Implementation: Once the voting is passed, it will be implemented into the relevant IoTeX ecosystem protocol. 103 | 104 | 105 | 106 | ## Acknowledgement 107 | 108 | Thanks for those who contribute to [BIPs](https://github.com/bitcoin/bips), [EIPs](https://github.com/ethereum/EIPs) 109 | and [EEPs](https://eeps.io/), where we have learned and borrowed clauses heavily. 110 | 111 | ## Changelog 112 | 113 | 2019-05-20: Drafted the initial version of IIP guideline. 114 | 115 | 2019-06-11: Added the IIP sample file. 116 | 117 | 2025-09-09: Updated the IIP lifecycle section. 118 | -------------------------------------------------------------------------------- /iip-20.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 20 3 | Title: XRC-20 Token Standard 4 | Author: Zhijie Shen (zhijie@iotex.io) 5 | Status: Final 6 | Type: Standards Track 7 | Created: 2019-05-20 8 | ``` 9 | 10 | ## Simple Summary 11 | 12 | A standard interface for tokens. IoTeX blockchain uses EVM to execute smart contract, so that the interface (named XRC-20) 13 | is fully compatible with [ERC-20](https://github.com/ethereum/EIPs/blob/f98a60e1b1590c9cfa0bfe66c4e6a674e54cd386/EIPS/eip-20.md). 14 | 15 | 16 | 17 | ## Abstract 18 | 19 | The following standard allows for the implementation of a standard API for tokens within smart contracts. 20 | This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party. 21 | 22 | 23 | ## Motivation 24 | 25 | A standard interface allows any tokens on IoTeX to be re-used by other applications: from wallets to decentralized exchanges. 26 | 27 | 28 | ## Specification 29 | 30 | ## Token 31 | ### Methods 32 | 33 | **NOTES**: 34 | - The following specifications use syntax from Solidity `0.4.17` (or above) 35 | - Callers MUST handle `false` from `returns (bool success)`. Callers MUST NOT assume that `false` is never returned! 36 | 37 | 38 | #### name 39 | 40 | Returns the name of the token - e.g. `"MyToken"`. 41 | 42 | OPTIONAL - This method can be used to improve usability, 43 | but interfaces and other contracts MUST NOT expect these values to be present. 44 | 45 | 46 | ``` js 47 | function name() public view returns (string) 48 | ``` 49 | 50 | 51 | #### symbol 52 | 53 | Returns the symbol of the token. E.g. "HIX". 54 | 55 | OPTIONAL - This method can be used to improve usability, 56 | but interfaces and other contracts MUST NOT expect these values to be present. 57 | 58 | ``` js 59 | function symbol() public view returns (string) 60 | ``` 61 | 62 | 63 | 64 | #### decimals 65 | 66 | Returns the number of decimals the token uses - e.g. `8`, means to divide the token amount by `100000000` to get its user representation. 67 | 68 | OPTIONAL - This method can be used to improve usability, 69 | but interfaces and other contracts MUST NOT expect these values to be present. 70 | 71 | ``` js 72 | function decimals() public view returns (uint8) 73 | ``` 74 | 75 | 76 | #### totalSupply 77 | 78 | Returns the total token supply. 79 | 80 | ``` js 81 | function totalSupply() public view returns (uint256) 82 | ``` 83 | 84 | 85 | 86 | #### balanceOf 87 | 88 | Returns the account balance of another account with address `_owner`. 89 | 90 | ``` js 91 | function balanceOf(address _owner) public view returns (uint256 balance) 92 | ``` 93 | 94 | 95 | 96 | #### transfer 97 | 98 | Transfers `_value` amount of tokens to address `_to`, and MUST fire the `Transfer` event. 99 | The function SHOULD `throw` if the message caller's account balance does not have enough tokens to spend. 100 | 101 | *Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. 102 | 103 | ``` js 104 | function transfer(address _to, uint256 _value) public returns (bool success) 105 | ``` 106 | 107 | 108 | 109 | #### transferFrom 110 | 111 | Transfers `_value` amount of tokens from address `_from` to address `_to`, and MUST fire the `Transfer` event. 112 | 113 | The `transferFrom` method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. 114 | This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. 115 | The function SHOULD `throw` unless the `_from` account has deliberately authorized the sender of the message via some mechanism. 116 | 117 | *Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. 118 | 119 | ``` js 120 | function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) 121 | ``` 122 | 123 | 124 | 125 | #### approve 126 | 127 | Allows `_spender` to withdraw from your account multiple times, up to the `_value` amount. If this function is called again it overwrites the current allowance with `_value`. 128 | 129 | **NOTE**: To prevent attack vectors like the one [described here](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/) and discussed [here](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), 130 | clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to `0` before setting it to another value for the same spender. 131 | THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before 132 | 133 | ``` js 134 | function approve(address _spender, uint256 _value) public returns (bool success) 135 | ``` 136 | 137 | 138 | #### allowance 139 | 140 | Returns the amount which `_spender` is still allowed to withdraw from `_owner`. 141 | 142 | ``` js 143 | function allowance(address _owner, address _spender) public view returns (uint256 remaining) 144 | ``` 145 | 146 | 147 | 148 | ### Events 149 | 150 | 151 | #### Transfer 152 | 153 | MUST trigger when tokens are transferred, including zero value transfers. 154 | 155 | A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to `0x0` when tokens are created. 156 | 157 | ``` js 158 | event Transfer(address indexed _from, address indexed _to, uint256 _value) 159 | ``` 160 | 161 | 162 | 163 | #### Approval 164 | 165 | MUST trigger on any successful call to `approve(address _spender, uint256 _value)`. 166 | 167 | ``` js 168 | event Approval(address indexed _owner, address indexed _spender, uint256 _value) 169 | ``` 170 | 171 | 172 | 173 | ## Implementation 174 | 175 | There are already plenty of ERC20-compliant tokens deployed on the Ethereum network, and there are XRC20-compliant tokens 176 | under development on the IoTeX network. 177 | Different implementations have been written by various teams that have different trade-offs: from gas saving to improved security. 178 | 179 | #### Example implementations are available at 180 | - [OpenZeppelin implementation](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/9b3710465583284b8c4c5d2245749246bb2e0094/contracts/token/ERC20/ERC20.sol) 181 | - [ConsenSys implementation](https://github.com/ConsenSys/Tokens/blob/fdf687c69d998266a95f15216b1955a4965a0a6d/contracts/eip20/EIP20.sol) 182 | 183 | 184 | ## History 185 | 186 | Historical links related to this standard: 187 | 188 | - Original proposal from Vitalik Buterin: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs/499c882f3ec123537fc2fccd57eaa29e6032fe4a 189 | - Reddit discussion: https://www.reddit.com/r/ethereum/comments/3n8fkn/lets_talk_about_the_coin_standard/ 190 | - Original Issue #20: https://github.com/ethereum/EIPs/issues/20 191 | 192 | 193 | ## Acknowledgement 194 | 195 | This document is derived from [EIP-20](https://github.com/ethereum/EIPs/blob/f98a60e1b1590c9cfa0bfe66c4e6a674e54cd386/EIPS/eip-20.md). 196 | Many thanks to the authors who contributed to the original document. 197 | 198 | 199 | ## Copyright 200 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /iip-48.md: -------------------------------------------------------------------------------- 1 | ``` 2 | - Title: "IIP-48: CIOTX – A Unified Cross-Chain Token Standard for the IoTeX Network" 3 | - Author: Qevan Guo, Chen Chen, Seedlet 4 | - Status: Draft 5 | - Type: Standards Track 6 | - Category: Token / Governance 7 | - Created: 2025-02-12 8 | - Updated: 2025-06-05 9 | ``` 10 | 11 | --- 12 | 13 | ## **Abstract** 14 | 15 | The IoTeX ecosystem currently features multiple representations of the IOTX token, leading to user confusion and integration complexity. This proposal aims to unify IOTX into a single, canonical token across major Layer 1 / Layer 2 blockchains, including Ethereum mainnet, Base and Solana, to name a few. 16 | 17 | This proposal formalizes **CIOTX** as the standard cross-chain representation of IOTX. CIOTX has been in use across multiple chains and functions effectively as a unified token, differing primarily in name. It is already deployed via trusted bridging infrastructure such as ioTube and Wormhole. 18 | 19 | IIP-48 will serve as **Phase 1** of the unification. A future IIP will introduce **Phase 2** which will involve the introduction of a new unified token to consolidate all IOTX variants across chains. 20 | 21 | --- 22 | 23 | ## **Motivation** 24 | 25 | Multiple versions of the IOTX token currently exist within the ecosystem: 26 | 27 | * **Native IOTX**: The native token on IoTeX L1, required to pay gas for mainnet transactions, widely traded on major exchanges (Binance, KuCoin, Gate, MEXC, etc.). 28 | 29 | * **WIOTX**: The wrapped IOTX token (XRC20 format) used for DeFi and dApps on the IoTeX L1 blockchain. 30 | 31 | * **ERC20 IOTX**: The legacy ERC20 IOTX token on the Ethereum blockchain, listed on Coinbase & Gemini exchanges. While 87% of the total supply has been burned during mainnet launch, it remains 1:1 convertible to native IOTX, but price discrepancies arise due to its limited availability on Ethereum. 32 | 33 | * **CIOTX (Crosschain IOTX)**: A bridge-based version of IOTX deployed on multiple chains (Polygon, BSC, Ethereum) for cross-chain functionality. 34 | 35 | This fragmented structure creates market inefficiencies, complicates liquidity distribution, and increases the technical burden for developers and users. A unified token standard will enhance ecosystem clarity, improve liquidity, and streamline user experience. 36 | 37 | --- 38 | 39 | ## **Token Unification Strategy** 40 | 41 | ##### **A. Formal Adoption of CIOTX as the Cross-Chain Token Standard** 42 | 43 | CIOTX has been actively used to enable cross-chain IOTX transfers across ecosystems like Ethereum, BSC, Polygon, and Solana. This proposal formalizes CIOTX as the **canonical cross-chain representation** of IOTX. 44 | 45 | ##### **B.** **dApp** **and Exchange Coordination** 46 | 47 | **Action:** Coordinate with major exchanges, wallet providers, indexers, and dApp developers to adopt CIOTX as the primary multichain representation of IOTX. **Rationale:** Standardizing CIOTX across platforms ensures a unified user experience and reduces the complexity of managing multiple IOTX variants. 48 | 49 | ##### **C. Expand and Rebalance CIOTX Liquidity** 50 | 51 | **Action:** Collaborate with liquidity providers, DeFi protocols, and bridge operators to expand and rebalance CIOTX liquidity on supported chains, including Solana (Raydium), Base (Uniswap), and Polygon (Quickswap). **Rationale:** Consolidated liquidity around CIOTX improves price discovery, reduces slippage, and promotes seamless multichain DeFi participation. 52 | 53 | ##### **D. Legacy ERC20 IOTX Token (Phase 2 Outlook)** 54 | 55 | **Action:** While ERC20 IOTX remains widely held (e.g., on Coinbase), its long-term future should be discussed with the community and exchange partners. **Rationale:** ERC20 IOTX lacks a consistent 1:1 peg to native IOTX, leading to pricing discrepancies and market confusion. A potential retirement or migration path may be proposed in a future phase, pending consensus. 56 | 57 | td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;} 58 | 59 | |Chain|Token|DEX|Bridge|Explorer| 60 | | --- | --- | --- | --- | --- | 61 | |Ethereum|CIOTX|Uniswap|ioTube|https://etherscan.io/token/0x9F90B457Dea25eF802E38D470ddA7343691D8FE1| 62 | |Polygon|CIOTX|Quickswap|ioTube|https://polygonscan.com/token/0x300211Def2a644b036A9bdd3e58159bb2074d388| 63 | |Solana|CIOTX|Raydium|Wormhole|https://solscan.io/token/QUUzqeiXHxjs9Yxm33tvugvUsKr5T8vjeyV4XhVsAfZ| 64 | |BSC|CIOTX|PancakeSwap|ioTube|https://bscscan.com/token/0x9678E42ceBEb63F23197D726B29b1CB20d0064E5| 65 | |Base (proposed)|CIOTX|Uniswap|Superbridge|–| 66 | |Unichain (proposed)|CIOTX|TBD|Superbridge|–| 67 | 68 | --- 69 | 70 | ## **Design Principles** 71 | 72 | Our approach prioritizes the use of **official and native bridges** for each target chain, as they are generally the most trusted, sustainable, and well-integrated within their ecosystems: 73 | 74 | * **Wormhole** for bridging to **Solana** 75 | 76 | * **Superbridge** (the standard for L2 rollups) for **Base** and **Unichain** 77 | 78 | * **ioTube** for bridging from/to **IoTeX** 79 | 80 | * **Binance CEX** as a bridge to **BSC** (Binance Smart Chain) 81 | 82 | These choices aim to maximize compatibility with existing dApps while ensuring long-term reliability and user trust. 83 | 84 | ![whiteboard_exported_image (2)](https://github.com/user-attachments/assets/dbf9c875-f53d-4d59-b6f5-286f7acfdaf5) 85 | 86 | 87 | 88 | --- 89 | 90 | # User Experience and Security Considerations 91 | 92 | This proposal prioritizes both user safety and simplicity. By leveraging the existing CIOTX architecture, users and developers benefit from a streamlined experience without introducing unnecessary migration steps or token confusion. 93 | 94 | #### **User Experience** 95 | 96 | * **No Migration Required**: Users are not required to swap tokens or move funds. CIOTX is already active on multiple chains, and its role is being formalized—not replaced. 97 | 98 | * **Improved Discoverability**: A unified token standard enables easier tracking on portfolio tools, DEX aggregators, and market data platforms. 99 | 100 | * **DeFi Compatibility**: Standardizing on CIOTX simplifies onboarding for users participating in DeFi protocols across Solana (Raydium), Base (Uniswap), Polygon (Quickswap), and more. 101 | 102 | #### **Security** 103 | 104 | * **Audits**: All smart contracts used in new CIOTX deployments (e.g., on Base, Unichain) will undergo comprehensive audits from reputable security firms before launch. 105 | 106 | * **Bridge Reliability**: CIOTX is only deployed through trusted, ecosystem-native bridges: 107 | 108 | * **Wormhole** (Solana) 109 | 110 | * **Superbridge** (L2s like Base and Unichain) 111 | 112 | * **ioTube** (Ethereum, BSC, Polygon) 113 | 114 | --- 115 | 116 | ## **Conclusion** 117 | 118 | Adopting **CIOTX** as the unified cross-chain representation of IOTX is a practical step toward reducing fragmentation, improving liquidity, and simplifying the user experience. 119 | 120 | By building on existing infrastructure and coordinating with exchanges, dApps, and bridge providers, we can strengthen IoTeX’s multichain presence with minimal disruption. 121 | 122 | Future decisions regarding other token variants, such as ERC20 IOTX, will be guided by community discussion and adoption trends. 123 | 124 | --- 125 | 126 | ## **Copyright** 127 | 128 | This document and its contents are made available under the CC0 public domain dedication. 129 | -------------------------------------------------------------------------------- /iip-22.md: -------------------------------------------------------------------------------- 1 | ``` 2 | IIP: 22 3 | Title: IoTeX Domain Name Service 4 | Author: Leo (leo@iotex.io) 5 | Status: WIP 6 | Type: Standards Track 7 | Category: Core 8 | Created: 2023-05-30 9 | ``` 10 | 11 | ## Abstract 12 | 13 | This draft IIP describes the details of the IoTeX Name Service (INS), which is similar to the ENS (Ethereum Name Service). The INS aims to be a protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This enables users to register and manage human-readable domain names for their IoTeX addresses, smart contracts, decentralized websites, and other IoTeX-based resources. INS will simplify the user experience by replacing long and complex IoTeX addresses with easy-to-remember names. 14 | 15 | If cryptocurrencies become mainstream, there will be a substantial market for Web3 domains. As "everyone" eventually adopts a Web3 wallet, human-readable digital wallet addresses will be as commonplace as email addresses. 16 | 17 | This proposal suggests using .io as the IoTeX L1 network's TLD. 18 | 19 | ## Motivation 20 | 21 | INS can offer many benefits for IoTeX blockchains: 22 | 23 | 1. Simplified Address System and enhanced user experience: INS replaces complex and lengthy cryptocurrency addresses with human-readable domain names, making it easier for users to interact with blockchain addresses and decentralized applications. 24 | 25 | 2. Interoperability: INS provides a unified namespace across multiple decentralized applications and blockchain platforms. Users can use the same INS domain name for various services, eliminating the need to remember different addresses for different applications. 26 | 27 | 3. Branding and Identity: INS supports various top-level domains (TLDs) beyond the traditional ".io" extension. This enables organizations and communities to establish their unique identities on blockchain, promoting branding and fostering a sense of trust and recognition. 28 | 29 | 4. Decentralization and Security: INS operates on the IoTeX blockchain, leveraging the decentralized nature of blockchain technology. This ensures that domain ownership and control are in the hands of the users themselves, reducing the risk of censorship or manipulation. 30 | 31 | 5. Integration with Existing Systems: INS can be integrated into popular wallets, exchanges, and decentralized applications, allowing seamless use of domain names across various platforms and services. 32 | 33 | 6. User Empowerment: INS gives users ownership and control over their domain names and associated cryptocurrency addresses. Users have the flexibility to update or transfer their domains as needed, providing a sense of empowerment and autonomy. 34 | 35 | 7. Improved Discoverability: INS facilitates the discovery of decentralized services and applications by providing human-readable domain names. Users can easily search and navigate the blockchain ecosystem, promoting the adoption and usage of decentralized platforms. 36 | 37 | 8. Future-Proofing: INS is designed to be compatible with evolving blockchain technologies and standards. It can adapt to changes and upgrades in the IoTeX network, ensuring its longevity and relevance in the ever-changing blockchain landscape. 38 | 39 | 9. Community and Innovation: INS fosters a community-driven ecosystem where developers, organizations, and individuals can collaborate, build upon, and innovate using the INS infrastructure. This drives creativity and the development of new decentralized applications and services. 40 | Based on the multiple advantages of INS mentioned above, it is an imminent task to deploy a mature, flexible, and stable domain name system on the IoTeX network. 41 | 42 | ## Specification 43 | 44 | ### Overview 45 | 46 | The INS system comprises four main parts: 47 | - The INS registry 48 | - Resolvers 49 | - Registrars 50 | - Name Wrapper 51 | 52 | The registry is a single contract that serves as the core infrastructure of the IoTeX Name Service. It functions as a decentralized database that maintains the mapping between domain names and their corresponding IoTeX addresses or resources. The Registry is implemented as a smart contract on the IoTeX blockchain, ensuring security, immutability, and censorship resistance. It acts as a single source of truth for all registered INS names and is responsible for handling the resolution of these names to their respective resources. 53 | 54 | Resolvers are smart contracts associated with individual INS names. They play a crucial role in enabling INS names to resolve to specific resources such as IoTeX addresses, decentralized websites, or content hashes. Resolvers allow users to configure and update the settings associated with their INS names, providing flexibility and adaptability. By interacting with the Resolver contract, users can define various records, such as address records (for IoTeX addresses), content records (for decentralized websites), and text records (for arbitrary metadata). These records allow users to attach additional information to their INS names and enable decentralized applications to utilize INS in a more versatile manner. 55 | 56 | Registrars act as intermediaries between users and the INS Registry. They facilitate the process of registering and managing INS names by allowing users to reserve, release, and transfer names securely. Registrars typically implement additional rules, policies, and pricing structures that govern the registration of names within their specific TLD (Top-Level Domain). Each TLD on INS has its own registrar, which defines the requirements for registering names under that TLD. Registrars play a vital role in ensuring the availability and integrity of the INS namespace by enforcing the registration rules and policies in a fair and transparent manner. 57 | 58 | Name Wrapper is a smart contract that will allow issuing subdomains (such as sub.domain.io) as separate Non-Fungible Tokens (NFTs). It is already possible to make and use subdomains, but they are not created as separate NFTs and can not be transferred between wallets, rented, or sold. On top of that, it will be possible to customize subdomains by revoking sets of permissions (burning fuses) to change the degree of ownership. 59 | 60 | Together, the INS Registry, Resolvers, Registrars, and Name Wrapper form a robust infrastructure that powers the IoTeX Name Service ecosystem. INS provides a decentralized and user-friendly approach to interacting with blockchain resources by offering human-readable names instead of long and complex addresses. Whether it's simplifying transactions, enhancing user experiences, or supporting the growth of decentralized applications, INS plays a vital role in making the IoTeX ecosystem more accessible and intuitive for users worldwide. 61 | 62 | ### Name syntax 63 | 64 | INS names must conform to the following syntax: 65 | 66 | ``` 67 | ::=