The Launchpad voting module of Ferc20 V3 is an important and innovative function. Many people still do not understand the details and have misunderstandings about it. Therefore, this article is written to explain it.

There are several misunderstandings and questions that are frequently asked:

1. Launchpad is a business of centralized exchanges, so why is a decentralized launch platform implementing such a feature?

2. One of the functions of Launchpad is to prevent malicious token duplication by removing tokens with malicious intent in the background. Why is it so complicated?

3. Is it necessary to go through Launchpad voting in order to deploy a token?

4. The process seems too complex, and it is still not clear.

If you also have these questions, this article will help you.

Ferc20 is a fully decentralized platform based on blockchain and smart contract technology. This makes it impossible to implement various management methods commonly used in centralized platforms.

The implementation of Launchpad voting serves several purposes:

Launchpad voting is a community governance mechanism aimed at involving community members in decision-making and managing the platform's development. Through voting, community members can express their opinions and preferences, providing input and decision-making basis for important platform decisions and feature improvements.

Launchpad voting plays a role in preventing malicious behavior during token deployment and platform management. Through the voting mechanism, the community can review and supervise the deployment and actions of tokens, preventing the occurrence of maliciously duplicated tokens and ensuring the security and trustworthiness of the platform.

It is well known that on blockchain networks like Ethereum, tokens with the same name (but different addresses) can be deployed without any restrictions.

However, in this case, if a user wants to deploy a token with a name that has already been used, they need to go through a community voting process. If the vote is successful, the applicant will have the right to deploy a token with the same name again. At the same time, this newly deployed token will be displayed with a "blue label" and a community rating to distinguish it from other tokens with the same name that have already been deployed.

Tokens with a "blue label" will not be able to be redeployed.

Also, by Launchpad voting and obtaining support from the $ferc community, the token will receive a "blue label," which prevents others from deploying tokens with the same name. This approach protects names that have established branding and recognition. It allows for the "locking" of the name before a deployment plan is finalized, preventing others from using it.

The Launchpad voting mechanism makes the platform's decision-making process more transparent and open. Community members can access information about each voting issue, including the content, participants, and results, thereby increasing trust and participation in platform governance.

Launchpad voting provides an opportunity for platform innovation. Community members can propose new features or improvement suggestions through voting, thereby driving the development and evolution of the platform.

In summary, the implementation of Launchpad voting facilitates community governance, prevents malicious behavior, enhances transparency, and encourages innovation, thereby promoting the development and healthy operation of the platform.

Although both are called Launchpad, they are fundamentally different.

The Launchpad of Ferc20 V3 is a voting system designed to obtain consensus from the Ferc community for projects. However, even without community consensus, projects can still be deployed as it is completely permissionless.

This is different from the Launchpad of centralized exchanges(CEX) and IEO, where projects cannot be listed without approval from the platform operator.

• Voting base: The current voting base varies on different chains:

  • Ethereum: 1.5 million votes

  • Arbitrum: 300,000 votes

  • Optimism: 150,000 votes

  • BSC: 150,000 votes

  • Polygon: 150,000 votes

• The passing rate is set at 30%.

The voting base and passing rate on different chains may be adjusted. The adjustments will be made through DAO voting, and further governance details will be announced later.

Note: The native $ferc token exists only on Ethereum with a total supply of 10 million. $ferc tokens on other chains are obtained by bridging from Ethereum to the target chain. After bridging, $ferc tokens can be staked to obtain votes, and the staking can be released at any time.

You can use the Nerve cross-chain bridge at: https://bridge.nerve.network.

• Ethereum: 0x2eCBa91da63C29EA80Fbe7b52632CA2d1F8e5Be0

• Arbitrum: 0xC365B8Cbde40cB902CaE1BDDf425a4c9E1f60d3f

• Optimism: 0xb055ffca6ec2849a5700fa851b28ff636c20b6e0

• BSC: 0xC365B8Cbde40cB902CaE1BDDf425a4c9E1f60d3f

• Polygon: 0xC365B8Cbde40cB902CaE1BDDf425a4c9E1f60d3f

Any account initiating a vote is required to stake a certain amount of $ferc (tentatively set at 1000, subject to change through community voting). This staking does not incur any loss, and regardless of the success or failure of the vote, the staked amount will be fully refunded to the applicant.

Before voting, participants need to stake $ferc and receive voting power in a 1:1 ratio based on the staked amount. Please refer to the diagram below:

Regarding the process of staking $ferc to obtain voting power, please note the following:

• Two transactions need to be completed during the staking process:

  • The first transaction is the authorization (Approve). For security purposes, please do not authorize an amount exceeding what you have staked. Never grant unlimited authorization.

  • The second transaction is the staking operation.

• You can redeem your staked $ferc at any time and receive it back in a 1:1 ratio.

After completing the staking process, you will see the following information:

Click on "Vote" button and in the pop-up window, enter the number of votes you want to allocate to this application. Confirm and complete the interaction with the contract.

Regarding voting, please note the following:

• You can allocate votes to different projects.

• If you want to add votes to a specific application, you must first withdraw the previously cast votes and then vote again.

If the vote does not receive the support of the $ferc community within the voting validity period (set by the applicant but not exceeding 10 days), anyone can deploy using the name of that application after the voting expires.

Note: Tokens deployed in this way do not have the "blue checkmark" verification.

In this case, anyone can deploy using the name of that application.

Note: Tokens deployed in this way do not have the "blue checkmark" verification.

• Scenario 1: Voters can voluntarily revoke their votes at any time.

• Scenario 2: If the vote does not pass or if the vote passes but the tokens are not deployed within the deployment validity period, the votes will be collectively revoked in the following cases:

  • A. If someone successfully deploys tokens using the same name, the deployer will pay the gas fees to revoke those votes and return the application deposit to the applicant.

  • B. A "Close Vote" button will appear in the voting window, and anyone can close the vote, revoke all the votes, and return the application deposit to the applicant. However, the operator will have to pay the gas fees to revoke those votes.

• Scenario 3: If neither anyone deploys tokens using the same name nor anyone closes the vote voluntarily, the vote will remain active until one of the above two cases occurs. In this scenario, the voter must revoke their own vote. Additionally, the 1000 $ferc staked by the original applicant cannot be refunded until someone (including the applicant themselves) voluntarily closes the vote.

• Scenario 4: If the deployer wishes to conduct airdrops or other activities to voters through a whitelist, they must inform the voters that they should not revoke their votes until the statistics are complete. Once a vote is revoked, it cannot be counted.

As long as the name is not on the reserved name list and it is not a "blue checkmark" token name, it can be deployed.

Ferc20 V3 is a permissionless non-ownable platform.

The advantage is simplicity, as tokens can be directly deployed.

The disadvantage is the possibility of encountering tokens with the same name and marked as "blue checkmark." If a token with a certain brand is deployed first, it may face disputes of counterfeiting.

No, they cannot.

The "blue checkmark" is written into the token contract and recorded on the blockchain during token deployment. Since the token contract is a non-ownable smart contract, no attributes can be modified after deployment. If it were possible to change it to a "blue checkmark" after deployment, the token contract would no longer be a non-ownable contract. Since both cannot be achieved simultaneously, the more important aspect is chosen while the less important aspect is abandoned.

The Launchpad voting module of Ferc20 V3 is an important and innovative function. Many people still do not understand the details and have misunderstandings about it. Therefore, this article is written to explain it.

There are several misunderstandings and questions that are frequently asked:

1. Launchpad is a business of centralized exchanges, so why is a decentralized launch platform implementing such a feature?

2. One of the functions of Launchpad is to prevent malicious token duplication by removing tokens with malicious intent in the background. Why is it so complicated?

3. Is it necessary to go through Launchpad voting in order to deploy a token?

4. The process seems too complex, and it is still not clear.

If you also have these questions, this article will help you.

Ferc20 is a fully decentralized platform based on blockchain and smart contract technology. This makes it impossible to implement various management methods commonly used in centralized platforms.

The implementation of Launchpad voting serves several purposes:

Launchpad voting is a community governance mechanism aimed at involving community members in decision-making and managing the platform's development. Through voting, community members can express their opinions and preferences, providing input and decision-making basis for important platform decisions and feature improvements.

Launchpad voting plays a role in preventing malicious behavior during token deployment and platform management. Through the voting mechanism, the community can review and supervise the deployment and actions of tokens, preventing the occurrence of maliciously duplicated tokens and ensuring the security and trustworthiness of the platform.

It is well known that on blockchain networks like Ethereum, tokens with the same name (but different addresses) can be deployed without any restrictions.

However, in this case, if a user wants to deploy a token with a name that has already been used, they need to go through a community voting process. If the vote is successful, the applicant will have the right to deploy a token with the same name again. At the same time, this newly deployed token will be displayed with a "blue label" and a community rating to distinguish it from other tokens with the same name that have already been deployed.

Tokens with a "blue label" will not be able to be redeployed.

Also, by Launchpad voting and obtaining support from the $ferc community, the token will receive a "blue label," which prevents others from deploying tokens with the same name. This approach protects names that have established branding and recognition. It allows for the "locking" of the name before a deployment plan is finalized, preventing others from using it.

The Launchpad voting mechanism makes the platform's decision-making process more transparent and open. Community members can access information about each voting issue, including the content, participants, and results, thereby increasing trust and participation in platform governance.

Launchpad voting provides an opportunity for platform innovation. Community members can propose new features or improvement suggestions through voting, thereby driving the development and evolution of the platform.

In summary, the implementation of Launchpad voting facilitates community governance, prevents malicious behavior, enhances transparency, and encourages innovation, thereby promoting the development and healthy operation of the platform.

Although both are called Launchpad, they are fundamentally different.

The Launchpad of Ferc20 V3 is a voting system designed to obtain consensus from the Ferc community for projects. However, even without community consensus, projects can still be deployed as it is completely permissionless.

This is different from the Launchpad of centralized exchanges(CEX) and IEO, where projects cannot be listed without approval from the platform operator.

• Voting base: The current voting base varies on different chains:

  • Ethereum: 1.5 million votes

  • Arbitrum: 300,000 votes

  • Optimism: 150,000 votes

  • BSC: 150,000 votes

  • Polygon: 150,000 votes

• The passing rate is set at 30%.

The voting base and passing rate on different chains may be adjusted. The adjustments will be made through DAO voting, and further governance details will be announced later.

Note: The native $ferc token exists only on Ethereum with a total supply of 10 million. $ferc tokens on other chains are obtained by bridging from Ethereum to the target chain. After bridging, $ferc tokens can be staked to obtain votes, and the staking can be released at any time.

You can use the Nerve cross-chain bridge at: https://bridge.nerve.network.

• Ethereum: 0x2eCBa91da63C29EA80Fbe7b52632CA2d1F8e5Be0

• Arbitrum: 0xC365B8Cbde40cB902CaE1BDDf425a4c9E1f60d3f

• Optimism: 0xb055ffca6ec2849a5700fa851b28ff636c20b6e0

• BSC: 0xC365B8Cbde40cB902CaE1BDDf425a4c9E1f60d3f

• Polygon: 0xC365B8Cbde40cB902CaE1BDDf425a4c9E1f60d3f

Any account initiating a vote is required to stake a certain amount of $ferc (tentatively set at 1000, subject to change through community voting). This staking does not incur any loss, and regardless of the success or failure of the vote, the staked amount will be fully refunded to the applicant.

Before voting, participants need to stake $ferc and receive voting power in a 1:1 ratio based on the staked amount. Please refer to the diagram below:

Regarding the process of staking $ferc to obtain voting power, please note the following:

• Two transactions need to be completed during the staking process:

  • The first transaction is the authorization (Approve). For security purposes, please do not authorize an amount exceeding what you have staked. Never grant unlimited authorization.

  • The second transaction is the staking operation.

• You can redeem your staked $ferc at any time and receive it back in a 1:1 ratio.

After completing the staking process, you will see the following information:

Click on "Vote" button and in the pop-up window, enter the number of votes you want to allocate to this application. Confirm and complete the interaction with the contract.

Regarding voting, please note the following:

• You can allocate votes to different projects.

• If you want to add votes to a specific application, you must first withdraw the previously cast votes and then vote again.

If the vote does not receive the support of the $ferc community within the voting validity period (set by the applicant but not exceeding 10 days), anyone can deploy using the name of that application after the voting expires.

Note: Tokens deployed in this way do not have the "blue checkmark" verification.

In this case, anyone can deploy using the name of that application.

Note: Tokens deployed in this way do not have the "blue checkmark" verification.

• Scenario 1: Voters can voluntarily revoke their votes at any time.

• Scenario 2: If the vote does not pass or if the vote passes but the tokens are not deployed within the deployment validity period, the votes will be collectively revoked in the following cases:

  • A. If someone successfully deploys tokens using the same name, the deployer will pay the gas fees to revoke those votes and return the application deposit to the applicant.

  • B. A "Close Vote" button will appear in the voting window, and anyone can close the vote, revoke all the votes, and return the application deposit to the applicant. However, the operator will have to pay the gas fees to revoke those votes.

• Scenario 3: If neither anyone deploys tokens using the same name nor anyone closes the vote voluntarily, the vote will remain active until one of the above two cases occurs. In this scenario, the voter must revoke their own vote. Additionally, the 1000 $ferc staked by the original applicant cannot be refunded until someone (including the applicant themselves) voluntarily closes the vote.

• Scenario 4: If the deployer wishes to conduct airdrops or other activities to voters through a whitelist, they must inform the voters that they should not revoke their votes until the statistics are complete. Once a vote is revoked, it cannot be counted.

As long as the name is not on the reserved name list and it is not a "blue checkmark" token name, it can be deployed.

Ferc20 V3 is a permissionless non-ownable platform.

The advantage is simplicity, as tokens can be directly deployed.

The disadvantage is the possibility of encountering tokens with the same name and marked as "blue checkmark." If a token with a certain brand is deployed first, it may face disputes of counterfeiting.

No, they cannot.

The "blue checkmark" is written into the token contract and recorded on the blockchain during token deployment. Since the token contract is a non-ownable smart contract, no attributes can be modified after deployment. If it were possible to change it to a "blue checkmark" after deployment, the token contract would no longer be a non-ownable contract. Since both cannot be achieved simultaneously, the more important aspect is chosen while the less important aspect is abandoned.