For Issuance
Interaction and Management of TOKEN Issuance by Contractors
Issuer's Raising refers to the CC0 (Community Consensus Offering) issuance conducted by a decentralized blockchain project, with the specific operator referred to as the Contractor. A complete Raising process includes: Project Onboarding: Registering the project and integrating it onto the blockchain. On-Chain Integration: Making the project a part of the blockchain protocol. Executor Role: The Contractor takes on the role of Executor. Creation of Distribution and Checks: The Executor creates the necessary distribution mechanisms and checks to achieve the CC0 issuance goals. Fund Management: Managing the allocated funds according to the project's requirements and protocols.
4.1 Project Onboarding
Submit JSON data in the specified format to GitHub for PR submission, as detailed in the README. Once submitted successfully, the project will be displayed in the DATA module. Apart from the TargetID, other project information can be modified and resubmitted according to the project's development. The SYNBO protocol will retain historical versions and support access to any historical modification records for each financing round.
Please submit the project using GitHub's "pull requests" and create a new project folder within the "projects" folder. The folder's name should match the project name exactly, for example, "synboProtocol," and ensure the name is unique.
Then, you will need to add the project basic information file, project details file, AMA proposal file, and qualified terms file (if applicable) to this folder.
Basic Information
Naming convention: Use camel case, name it after the project name, and the file extension should be .json.
Example: synboProtocol.json
File content: Please follow the document fields and submit according to the format.
Required
Details File
Naming convention: The file name should start with info_, followed by the project name, and the file extension should be .md.
Example: info_synboProtocol.md
File content: A detailed project overview provided through visual and text documents. The content may include but is not limited to:
Project Overview: A detailed description of the project's background, goals, and features.
Team Information: Introduce team members and their backgrounds.
Token Economy: Describe the token issuance mechanism, allocation plan, and purpose.
Roadmap: The future development plan and timeline of the project.
Historical Fundraising Information: Include information on financing rounds, amounts, and investors.
AMA Proposal File
Naming convention: The file name should start with ama_, followed by the project name, and the file extension should be .md.
Example: ama_synboProtocol.md
File content: Present details on the current fundraising environment, needs, and usage targets in a Q&A format.
Terms File
Naming convention: The file name should start with terms_, followed by the project name, and the file extension should be .md.
Example: terms_synboProtocol.md
File content: If your project has undergone any compliance reviews, audits, etc., it can be presented here, especially for RWA-related projects. (Optional)
The documents support Markdown syntax, so please ensure proper formatting. Once merged, the information will be displayed in the Data List module.
Please feel free to eference Instructions for the Required .JSON Format and Content Submission， please read carefully:
TargetID: Automatically generated
Name: Accurate project name
Logo: In SVG file format, provided as an array if there are multiple logos
Profile: Brief description within 250 characters
Ecology-icon: Ecology icons, provided as an array of ecology targets, typically public chain icons
Tags: Tags, provided as an array of the project’s ecological labels
Fundraising History
Historical Fundraising Amount: 1.0M
Historical Investors: SYNBO protocol, ** capital
Current Fundraising Plan: Pre-A
Token Lists
Token Name 1
Where: The blockchain where the asset is located
Token Address: ERC20 address
Token Type: Asset type, such as ERC20, 721, NATIVE, etc.
Info: Description of usage, etc.
Token Name 2 (if multiple tokens)
Where: The blockchain where the asset is located
Token Address: ERC20 address
Token Type: Asset type, such as ERC20, 721, NATIVE, etc.
Info: Description of usage, etc.
Community Information：Website / Docs / Github / Twitter /Discord / Telegram /Medium / Email / More.
4.2 Project On-Chain Integration
After the project information is included in the DATA List, anyone can register the project's TargetID on the target public blockchain supported by the SYNBO protocol. The SYNBO protocol will generate a specific NFT for the current ID. This NFT serves only as an identity marker for the project on the target blockchain and does not hold additional significance at this stage.
4.3 Contractor
Any user can add a project to their management page by searching for the project's NFT on the blockchain. They can then bind the NFT's identity through an on-chain declaration to become a Contractor. It is important to note that anyone can become a Contractor, so the Contractor does not necessarily represent the project party. To reduce interference and prevent misuse, becoming a Contractor requires paying a certain fee and having sufficient POWER in their account.
Contractors have the right to create distributions and issue checks, which is permissionless. However, there is a safeguard against impersonation, as creating a check requires a financing cost of 1% to 2%. Additionally, for a check to successfully enter the consensus decision phase, it must verify that the escrowed assets match the TOKEN address in the TargetID and complete the contract escrow for the consensus issuance goal TOKEN; otherwise, the Contractor's actions will be meaningless.
4.4 Raising
The Synbo protocol provides decentralized consensus matching and CCO (Community Consensus Offering) services for blockchain consensus systems without permission. Therefore, any blockchain project is welcome to use the Synbo protocol for CCO issuance, successfully obtain funding and consensus, and advance the development of the project to the next level.
4.4.1 Creating Distributions and Managing Assets
Any Contractor can create distributions independently, and the protocol allows a single TargetID to have multiple distribution instances simultaneously, though only one Cheque can be valid at a time. Parameters and rules for creating a distribution are as follows:
Binding Distribution Asset Token: The Token must be registered in the DATA List library.
Setting Total Distribution Quantity and Maximum Bidding Amount per User: The Contractor must set the total distribution quantity and adjust the maximum bidding amount per user to ensure that Tokens are distributed to different user addresses effectively and maintain fairness in execution.
Setting Distribution Participation Limits: Choose between “Free” or “Only Checked”, which will affect the financing cost.
Setting Cooling Period: During the cooling period, the project can implement additional operational measures to improve the success rate of the distribution. The maximum cooling period can be set to 0, 3, or 7 days.
Premium and Discount Rates: These are Alpha incentives set by the project to attract more Alpha Brokers to act as agents for the distribution. The premium rate ranges from 0% to 30% (to protect Investors), and the discount rate ranges from 100% to 0% (100% for airdrop scenarios).
Setting Release Rules: Include lock-up period, initial release ratio, and linear release period to meet the market-making needs of different batches and stages, which will impact Investor enthusiasm.
Bidding Mode during Distribution: The distribution of assets uses a bidding mode, with prices based on boundary curves formed by distribution progress and time progress. The premium and discount rate components provide Alpha incentive space for Alpha Brokers.
User Constraints: After obtaining project Tokens, users are constrained by the release rules. Regardless of whether the full release has occurred, users can vote on the current cheque’s withdrawal proposal based on their weight to protect their rights. Voting weight = MIN(account balance + current locked amount, total voucher quantity). A rejection rate of ≥34% of the current completed issuance amount is required, ensuring that rights are not lost even if the distribution is incomplete.
Proposal Submission: Contractors can only initiate withdrawal proposals after the distribution has officially started.
4.4.2 Creating a Cheque
Any Contractor can create a Cheque, but the protocol contract stipulates that only one valid Cheque can exist per TargetID at any given time. Each Cheque can only be bound to one Distribution instance and cannot be modified. The Cheque is the core module for users to participate in consensus.
Parameters and rules for creating a Cheque are as follows:
Binding Distribution Instance: Before starting the consensus decision, the Distribution must complete the self-custody of the TOKEN.
Setting Financing Amount: The financing amount determines the quantity and the cost of the financing. In the Distribution, the cost rate is either 1% or 2%, with a minimum cost of 0.1 ETH and a minimum financing amount limit of 0.1 ETH.
Setting Consensus Participation Limits: You can choose between “Free” or “Only Exports”. "Only Exports" is more likely to attract professional Brokers and achieve better consensus curation for project distribution.
Maximum Cumulative Position Participation Amount: The success threshold for consensus decision-making is 40% of the total financing amount, so the maximum leverage ratio for Alpha Brokers is 2.5. The maximum cumulative position participation amount is the cap for consensus positions. The more positions a project has, the lower the Alpha incentive ratio for the agents.
4.4.3 Redemption Custody
Contractors can redeem custody under the following circumstances:
Consensus Decision Failure:
Distribution Failure 1: If the virtual auction price falls below the discount price, the distribution can be actively halted, and the uninitiated staging phase can be directly redeemed. For initiated stages, Alpha Brokers will cover the costs.
Distribution Failure 2: If the distribution has not been actively halted and remains incomplete after 90 days, it will be passively terminated. The uninitiated staging phase can be directly redeemed, while the initiated stages will be covered by Alpha Brokers.
4.4.4 Termination of Distribution
The Contractor can actively terminate the distribution under the following condition: when the auction price ( P_2 ) falls below the discount price.
Here, ( P_1 ) and ( P_2 ) represent real-time prices along the boundary curve formed by distribution progress and time progress. Within the boundary range, ( P_1 = P_2 ). When ( P_1 < P_2 ), it indicates that the market is very active, and ( P_1 ) has reached the maximum premium. Conversely, when ( P_1 > P_2 ), it means that ( P_1 ) has reached the minimum discount, and ( P_2 ) is below the discount price. In such cases, the Contractor can actively terminate the distribution, moving the financing to the dividend and liquidation stage.
4.4.5 Withdrawal Proposal
When the project enters the formal distribution phase, the Contractor can start creating withdrawal proposals, which involve using the rights obtained through the Cheque to withdraw funds from the fund pool.
Proposal Design Rules:
Proposal Quantity Limit: The Contractor can create up to ( n ) withdrawal proposals for a single cheque.
Review Period: Each proposal has a review period of 7 to 14 days.
Rejection Mechanism and Threshold: The proposal review process uses a rejection mechanism. If the rejection rate of the proposal reaches 34% or higher from the auction certificate holders, the proposal will be deemed unsuccessful.
Last updated