# Swarm Network The Swarm Network is a group of persons (Members) joining to support the development of a digital infrastructure designed to foster the emerging digital securities economy. ### **Protocol, smart contracts, and UI:** **SRC20:** The framework of the Swarm protocol. It gives token issuers the tools to perform regulatory compliant security token issuances. **Swarm Powered Fundraise (SPF):** Powerful tools to perform regulatory compliant fundraises for security tokens. **mySwarm.app:** UI built on SPF contracts to start and run Security Token Offerings. You can also manage your security tokens by burning, minting, moving, issuing dividends, and more. ![](/files/-M6dergsXJTmj-Ax8tPY) # Network Governance This documentation summarizes the practical usage of Swarm governance. based on the authoritative network-approved Swarm Network Constitution. **Want to vote on proposals?** Go straight to the [Voting app on Snapshot](https://snapshot.page/#/swarmnetwork.eth). **Just want to jump in and create a proposal?** Go straight to the [Quick Start](/swarm-network/network-governance/getting-started) guide. ![](/files/-M7IcC2dfi9braWrNZBF) Note: This guide is a summary. Read the official Swarm Network Constitution on [GitHub](https://github.com/swarmfund/networkgovernance/tree/master/swarm_network_constitution). # Getting started Governance of the Swarm Network by its Members is an important function. Here is a quick-start guide to getting a governance action to vote. 1. **Talk about it**. Present your idea and put it out to the community for discussion and to get feedback on it. [Discourse ](https://community.swarm.fund)is a good forum for serious discussion of a proposal, though [Telegram](https://t.me/swarmfund), [Reddit](https://reddit.com/r/swarm/), and the [Issues](https://github.com/swarmfund/networkgovernance/issues) tab in GitHub are also good venues to share your idea and get initial feedback. 2. **Iterate**. Based on feedback, develop your idea until you feel it is solid enough to formulate into a coherent proposal, with clearly presented benefits and budget implications. 3. **Finalise your idea**. While you’re getting feedback from Members, or when you’re ready, start formally documenting your idea. You can use a [template](https://github.com/swarmfund/networkgovernance/tree/master/templates) as a guide for how to structure your proposal. 4. **Submit a draft proposal**: Only Swarm Members may submit a proposal for balloting. To enter the Swarm Network Voting Queue, submit your proposal to Github and stake a minimum of two hundred and fifty (250) SWM tokens. Instructions for submitting a draft proposal are [here](/swarm-network/network-governance/actions/proposal-process). 5. **Get support**: Other Members can stake against your proposal. Every two months, the top five most supported ballots, by stake, are selected to be voted on. Go out there and campaign. 6. **Vote!**: Read up on all upcoming ballots, talk to their sponsors, and don’t forget to vote. Every SWM token holder can vote on every ballot. # The Swarm Network The Swarm Network is a group of persons (Members) joining to support the development of a digital infrastructure designed to foster the emerging digital securities economy. ## General Purpose The Swarm Network aims to build and maintain an open infrastructure for digital securities and a financial marketplace that is globally accessible, free and trustworthy for its participants. The Swarm Network supports base layer research, development and education to bring decentralized, open-source protocols and tools to the world of finance, empowering developers to produce next generation decentralized financial services applications. ## Specific Purposes To equitably balance the respective interests of all participants and, to this end, define and refine platform policies accordingly. To act as a decentralized governance body to manage the lawful development and maintenance of the platform compliant with its purposes. To build tools and infrastructure that support adherence to applicable laws and regulations with respect to the issuance of digital securities on the platform as well as trading such digital securities on third-party or decentralized exchanges. # Powers The Swarm Network has the following powers: * raise funds and apply for, invite, obtain, collect and receive contributions (including in-kind contributions of tangible or intangible property), grants, subscriptions, fees and otherwise; * engage any person or organization to assist in the attainment of the purposes; * define and administer Platform rules and policies; and * do all such other lawful things as shall further attainment of the purposes including prohibiting the use of the platform by any person to ensure adherence to its purposes. # Governance **Rights**: The Swarm Network is governed by its Members and the Swarm Council. **Purpose of Governance Actions**: The will of the Swarm Network shall be prosecuted through the execution of Governance Actions. **Members with special responsibilities:** The Members may decide, via Governance Action, to delegate certain governance-related functions to subgroups of Members (“Designated Members”) temporarily or permanently. ## \*\*\*\* # Members A Member of the Swarm Network is a person that: * is a legally competent person of at least 18 years of age, * who lawfully owns SWM tokens, and * has a registered and validated identity on the Platform (“Swarm Investor Pass”). Currently, validation must be performed by any of these qualification providers: * [SumSub](https://sumsub.com/) # Swarm Council ## Duties The Swarm Council is an elected body of five natural persons who are Members. Its duties are to initiate sensible governance action proposals, ensure that all governance actions ballots are compliant with the purposes of the Swarm Network, administer funding for governance actions, and help prevent use of the Swarm platform for illicit purposes. ## Current members * Richard Steward * Zachary K. Perryman * Alex Cornwell * Felix Carl Wiegandt * John Gallagher * Daniel Faria [![](https://github.com/swarmfund/swarm-network-www/tree/5b22e05998d5339333c46bf266b09372a0960907/Network-Governance/.gitbook/assets/iconfinder_square-linkedin_317725.png)](https://www.linkedin.com/in/alexncornwell) The Swarm Council may expand to a maximum of nine Members, with the addition of two new Members upon each expansion. Expansion decisions shall be made by a governance action ballot or by unanimous vote of the Swarm Council. ## Appointment Each Member of the Swarm Council shall be elected via an Approval Ballot. Any Member may nominate another Member to fill a vacant seat on the Swarm Council via a GAB (“Nomination GAB”), subject to the eligibility requirements set forth in the Swarm Network Constitution. Currently, only Members are eligible to serve on the Swarm Council, and must hold at least 50,000 SWM tokens for the duration of their tenure to maintain eligibility. ## Past council members * Aravinda Babu (resigned 5/5/20)[![](https://github.com/swarmfund/swarm-network-www/tree/5b22e05998d5339333c46bf266b09372a0960907/Network-Governance/.gitbook/assets/iconfinder_square-linkedin_317725.png)](https://www.linkedin.com/in/linuxchip/) * Sam Stone (resigned 5/5/20) [![](https://github.com/swarmfund/swarm-network-www/tree/5b22e05998d5339333c46bf266b09372a0960907/Network-Governance/.gitbook/assets/iconfinder_square-linkedin_317725.png)](https://www.linkedin.com/in/stonysam/) * Philipp Pieper (term ended 12/25/19) [![](https://github.com/swarmfund/swarm-network-www/tree/5b22e05998d5339333c46bf266b09372a0960907/Network-Governance/.gitbook/assets/iconfinder_square-linkedin_317725%20\(1\).png)](https://www.linkedin.com/in/philipppieper/) * Timo Lehes (term ended 2/25/20) [![](https://github.com/swarmfund/swarm-network-www/tree/5b22e05998d5339333c46bf266b09372a0960907/Network-Governance/.gitbook/assets/iconfinder_square-linkedin_317725%20\(1\).png)](https://www.linkedin.com/in/timolehes/) # Treasury ## Funds The Swarm Network treasury consist of the following wallets: * General treasury: [0x689A20DAA8B813A73f86717b572e8FA3a42398d6](https://etherscan.io/address/0x689A20DAA8B813A73f86717b572e8FA3a42398d6) * Reserve for block rewards: [0x11DB72F40e88899af7D3270A6206287003dda5Fb](https://etherscan.io/address/0x11db72f40e88899af7d3270a6206287003dda5fb) ## Allowable expenditures Any amounts held or obtained by the Swarm Network shall only be used to advance the Purposes of the Swarm Network. # Initiating Governance Actions Governance Actions direct the Swarm Council, Members, Designated Members, Participants or other third parties to perform certain tasks or activities for the benefit of the Swarm Network. Governance Actions shall be decided by referendum. Approved actions are reviewed by the Swarm Council, which puts in place any procedures, or takes the necessary actions to execute them. No Governance Action shall violate the Purposes of the Swarm Network or the laws of any applicable jurisdiction. Governance Actions approved by Swarm Members in a referendum are placed in the [Governance Actions](https://github.com/swarmfund/networkgovernance/tree/master/Governance%20Actions) repository for archival purposes. # Introduction Governance action proposals, and how to submit one. * Swarm Network Governance consists of three components: Proposals, Ballots and Actions. * Any member can initiate a proposal. * To promote a proposal to a ballot and be eligible to enter the voting queue, the ballot sponsor must deposit a stake of SWM tokens. Other Members can co-sponsor the ballot by staking additional SWM, which gives the ballot a higher priority. # Proposals Governance Actions start as ideas that originate in the Swarm community, eventually developing into a crystallized proposal. A Governance Action Proposal is an idea that has been discussed to the point where a Member feels it beneficial to formalize and submit it to the voting queue to be voted on by the community of Members. Forums where governance actions may be discussed include, but are not limited to, the following: * [Discourse ](https://community.swarm.fund)(Recommended) * [Telegram](https://t.me/swarmfund) * [Reddit](https://reddit.com/r/swarm/) * [Issues](https://github.com/swarmfund/networkgovernance/issues) tab in Swarm's GitHub ## Initiating a proposal Any Member can initiate a “Governance Action Proposal” or “GAP”. The ballot proposal process is described in detail [here](/swarm-network/network-governance/actions/ballots). A GAP may also be initiated through a majority vote of the Swarm Council. A GAP may also be initiated as part of the enactment and execution of a prior Governance Action. A GAP should describe to Members how the action benefits the Swarm Network and why they should vote for it. It should also provide a detailed description of the action, any relevant supporting documentation, and may include a request for a budget. There are four themes that a GAP may be categorized into: 1. Network Constitution: proposals suggesting changes to the Swarm Network Constitution, 2. Network Policy: proposals for changes to core network policies such as staking requirements, rewards, etc, 3. Proclamation: proposals for making a public statement on behalf of the Swarm Network, 4. General: all other governance action proposals. Proposal templates may be viewed on [GitHub](https://github.com/swarmfund/networkgovernance/tree/master/templates). ## Requirements A proposal must: * concisely and cogently describe the Governance Action; * describe the purpose and rationale for the Governance Action and its intended outcomes; * identify the specific uses for which Swarm Treasury funds may be expended to support the Governance Action; * be written in English; and * specify the Voting Period If a Governance Action requires the expenditure of Swarm Treasury funds the proposal must, in addition: articulate and establish an accountability framework that measures the performance of the Governance Action; provide an auditing procedure to account for expenditures; and provide a method for reporting the audit and performance results to the Swarm Network and the Swarm Council. ## Pre-Clearance A Member may petition the Swarm Council for confirmation that a GAP, if balloted, would meet the procedural and substantive requirements described above. Pre-Clearance shall be granted if the Swarm Council finds through an affirmative vote that the requirements are satisfied. # Ballot Types A GAB must consist of one of the three types of supported ballots: ## Up/Down Ballots: Up/Down Ballots contain a single option to be voted on by the Members. Voting options include "Adopt,” "Reject,” and “Pass.” An Up/Down ballot is adopted when: * A quorum is reached, and * the Adopt votes outnumber the Reject votes at the end of the Voting Period. ## Multi-Option Ballots: Multi-Option Ballots contain multiple options to be voted on by the Members, including "Adopt Option 1,” …, "Adopt Option n,” …., “Reject” and “Pass." A Member can only select one of the voting options on the ballot. A vote for Reject is a vote against all options on the ballot. A vote for Pass is a vote to abstain from adopting any of the options and rejecting any of the options. Option X is approved when: (a) a quorum is reached, and (b) the votes for “Adopt Option X” outnumber the votes for “Reject " at the end of the Voting Period. ## Approval Ballots: Approval Ballots contain multiple options to be voted on by the Members, including "Adopt Option 1,” …, "Adopt Option n,” …., “Reject” and “Pass." Unlike a Multi-Option Ballot, a Member can allocate her votes to one or multiple voting options on the ballot. A vote for Reject is a vote against all options. A vote for Pass means to abstain from voting with respect to adopting or rejecting all of the options. Option X is approved when: (a) a quorum is reached, and (b) the votes for “Adopt Option X” outnumber the votes for “Reject" at the end of the Voting Period. Approval Ballots can also define that a certain number of options receiving the most votes will be adopted, whereby if the Adopt votes for those certain options outnumber the votes for “Reject” at the end of the Voting Period, those options will be adopted (assuming the quorum requirement is met) # Submitting a GAP How to submit a governance action proposal for balloting. When you're ready, use the following procedures to submit your draft proposal by creating a pull request in GitHub. 1. Use a template to ensure your proposal includes all the required information. * [ ] Click the [template](https://github.com/swarmfund/networkgovernance/tree/master/templates) that relates to the proposal you are submitting, * [ ] To copy the template, click **Raw**, then copy the contents of the template to use in your proposal in the next step. 2. Submit your draft proposal: * [ ] In the [GAPs](https://github.com/swarmfund/networkgovernance/tree/master/GAPs) repository, **create a new file**. * [ ] Name your proposal with a temporary name in the following format: **GAP\_\[CURRENT\_EPOCH\_TIME]\_\[NAME].md** For example: **GAP\_1565084743\_SAMPLENAME.md** Epoch Time may be obtained from [https://www.epochconverter.com](https://www.epochconverter.com/) * [ ] Paste the contents of the template from Step 1 into your file and complete all the information. * [ ] Select the option to "**Create a new branch for this commit and start a pull request.**" * [ ] Click "**Propose new file**" to review your submission, add any comments or notes, and click "**Create pull request**" to continue. 3. Stake 250 SWM to make your proposal eligible for balloting. * [ ] An editor will reply to your request, providing an address to stake at least 250 SWM. * [ ] Deposit your stake and provide the TransactionID for verification. Eligible proposals will be merged and be visible in the [GAPs](https://github.com/swarmfund/networkgovernance/tree/master/GAPs) repository. * [ ] Any Swarm Member may improve the likelihood of the GAP being balloted by staking an additional amount of SWM, in increments of at least 250. # Governance Action Voting Process ## Introduction * Every two months, the five most supported ballots are voted on by eligible members in a referendum. * Each SWM token grants its holder the right to cast one vote in any referendum. * Liquid Democracy: Votes can be delegated to others. * Winning ballots become actions to be executed by the Swarm Council. ## **Voting Calendar Schedule** At a fixed interval of two months (the “Voting Interval”) the GABs in the Voting Queue with the five greatest GAB stakes are elevated for a referendum (SNC, Article VII, B(3)). Assuming a default voting period of seven days, here’s the schedule of upcoming votes for 2020: | Deadline for new GAPs | Voting Period | | --------------------- | -------------- | | February 7 | February 10-16 | | April 3 | April 6-12 | | June 5 | June 8 - 14 | | August 7 | August 10-16 | | October 9 | October 12-18 | | December 4 | December 7-13 | # Ballots **Sponsoring:** To enter the Swarm Network Voting Queue, a GAP needs to be balloted. Any Member may sponsor a ballot by staking a minimum of **two hundred and fifty (250) SWM** tokens, becoming the “Ballot Sponsor.” GAPs that have been balloted are “Governance Action Ballots” or “GABs.” Any Member may petition the Swarm Council to sponsor a GAP. **Seconding:** While a GAB is in the voting queue any Member may second the GAB any number of times by adding additional deposits of SWM tokens. A member that seconds a GAB is a “Ballot Supporter.” **Elevation:** Every two months the GABs in the voting queue with the five greatest GAB stakes are elevated for a referendum. The Swarm Council determines, by a majority vote, if any elevated GABs present conflicting actions. In this case, only the GAB with the greatest GAB stake shall be elevated to a referendum. GABs have three voting intervals (six months) to be elevated to a referendum, at which time they are removed from the voting queue. **What happens to stakes:** SWM tokens that have been staked to a GAB by sponsors and supporters constitute the “GAB stake.” Stakes associated with winning GABs are locked for **fifteen (15) days** after their vote, and then returned to the Ballot Sponsors and Ballot Supporters. The stakes of any failed GABs are forfeited to the Swarm Treasury. # Retrieving the text of previous ballots **How do I retrieve the text of previous ballots?** At [https://voting.swarmnetwork.org](https://voting.swarmnetwork.org/?enableDumpMasternodeDetails=true) you will find the [{ballot-address}](https://archive.secure.vote/0x%7BTXID%7D.json) smart contract for each ballot when clicking the “i" icon of each ballot. ![](/files/-M6oPHeU6fFqRhd0QaPn) ![](/files/-M6oPKHz_-O4KgzHYCDg) Go to the "Events” tab in etherscan with [https://etherscan.io/address/](https://etherscan.io/address/%7Baddress%7D#events)[{ballot-address}](https://archive.secure.vote/0x%7BTXID%7D.json)#events , then scroll down to the earliest transaction of the contract. Click the Txn Hash to see more details about the transaction. ![](/files/-M6oPN47a5aiYnpxeL55) The first event has details about the ballot instantiation. *Click to see More*. One of the data (typically the last one) will be the only one to have a 32 bytes [{TXID}](https://archive.secure.vote/0x%7BTXID%7D.json). It should be labelled *specHash*. ![](/files/-M6oPOyHSta67BVDihTX) Copy the hash and then go to [https://archive.secure.vote/0x{TXID}.json](https://archive.secure.vote/0x%7BTXID%7D.json)\ That will get you the “BallotSpec”, which you can download and open it with a text editor to see the details # Voting ## Public Display of Ballots Governance Action Ballots will be displayed and will be open for voting for seven days at or another public channel designated by the Swarm Council. ## Voting Rights Each SWM token grants its holder the right to cast one vote in any referendum. Members, only, are allowed to take part in the Governance Action Voting Process. ## Voting Protocol * Members may vote on a GAB at any time during the voting period. * Members are free to change their votes whenever they want during the voting period. * A Member may delegate their voting rights to any other Member. ## Default Masternode Delegation In order to encourage an engaged community, and to better facilitate thoughtful consideration of Governance Action Ballots (GABs) by the community, the Swarm Network applies a Default Masternode Delegation for non-voting tokens. If a Member does not vote in a referendum on a GAB, the voting rights associated with her SWM tokens are reallocated pro rata and according to the relative amounts of SWM held in their wallets, to the Members owning active masternodes that have voted on the GAB. How to calculate voting results including Default Masternode Delegation: 1. Retrieve all the voting events from the ballot’s smart contracts; to identify the corresponding smart contract click on “i” of each ballot in the [voting app](https://voting.swarm.fund/) 2. Retrieve the SWM balances for all the voted wallets 3. Retrieve the active masternode wallets from and identify those wallets who voted within the ballot 4. Prorate the results from those masternodes who voted across the SWM in circulation, which was not voted with within the ballot 5. Add the prorated results to directly casted votes and calculate the result now including default master node delegation # SWM Token The SWM token is the essential element which powers the SWARM ecosystem. | Info & Metrics | | | --------------------------------- | ---------------------------------------------------------------------------------------- | | **Blockchain** | Ethereum | | **Total Supply** | 100,000,000 SWM | | **Total Staking Rewards** | 10,000,000 SWM | | **Etherscan** | [Token Tracker](https://etherscan.io/address/0x3505f494c3f0fed0b594e01fa41dd3967645ca39) | | **SWM Contract Address** | 0x3505f494c3f0fed0b594e01fa41dd3967645ca39 | | **xDai SWM Contract Address** | 0xaB57C72BFe106E6D4f8D82BC8CAD9614cdd890Fa | | **SWM Treasury Contract Address** | 0x689a20daa8b813a73f86717b572e8fa3a42398d6 | | **SWM Rewards Contract Address** | 0x11db72f40e88899af7d3270a6206287003dda5fb | | **Where to buy SWM** | | ## SWM Utility **Governance: Participate in network votes for the treasury, council members, fees, rewards, and more.** **Stake SWM Uniswap LP Tokens: Provide liquidity for the Swarm Network ecosystem and earn the highest rewards.** **Stake SWM: Stake your SWM tokens to participate in network governance and earn rewards.** **SWM fee table for issuers, 80% distributed to SWM Stakers, 20% goes to Treasury:** | Tokenized Asset Value (USD) | Up to $500k | $500k-$1M | $1M-$5M | $5M-$15M | $15M-$50M | $50M-$100M | $100M-$150M | $150M+ | | ------------------------------------ | ----------- | --------- | ------- | -------- | --------- | ---------- | ----------- | ------ | | Fee (Calculated in USD, paid in SWM) | $2,500 | 0.50% | 0.45% | 0.40% | 0.25% | 0.20% | 0.15% | 0.10% | ## Tokenomics: ![](/files/-MWyegtKfDdgxfBcWCkP) ## Get SWM on Uniswap: [HERE](https://info.uniswap.org/pair/0xe0b1433e0174b47e8879ee387f1069a0dbf94137) # SWM Staking Stake your SWM tokens to participate in network governance and earn rewards. ## Pool 1 vs. Pool 2 There are two staking pools available. You can choose to stake your SWM by locking it away and enabling your participation in network governance while earning rewards, or you can provide liquidity to SWM on Uniswap and stake your LP token while also participating in network governance and earning rewards. 10 million initial SWM token reward pool was established 1 September 2018. Initial pool was 2.5 million, reducing by 25% each year, for 100 years. Rewards are distributed on the first of every month. **Pool 1, SWM Pool Rewards: 1x Rewards** **Pool 2, SWM/ETH Pool Rewards: 4x Rewards** **80% of fees paid in SWM are distributed to P1 and P2** ## Tokenomics: ![minting fees flow to the Rewards Wallet and then to stakers](/files/-MXOyxaub1ls-zcV6hcs) ## How to stake SWM: Visit Connect your metamask, Approve SWM or SWM/ETH LP, whichever you prefer, then deposit. If you choose SWM/ETH LP, to provide liquidity, go to For any other questions, please come to Telegram for help: # SRC20 Note: This page describes an older version of the smart contract suite. We will update it soon! ## Introduction [SRC20](https://www.swarm.fund/src20) token framework of the Swarm protocol. It gives token issuers the tools to perform regulatory compliant security token issuances. [This blog post](https://medium.com/swarmfund/smart-contracts-upgrade-bd0da3b736ea) describes the overall goals and benefits. As the SRC20 is open source, it allows token issuers and service providers alike to freely use this protocol stack and build custom solutions and services on top of it. ## Smart Contract Index The following four contracts are created in relation to a specific SRC20 token and interact with one another and other global SRC20 smart contracts. ![](/files/-M7EUR2JTT7JRq2TydEC) ### Smart contracts specific to each SRC20 For each new SRC20 token, one of each of these smart contracts is newly created. | Contract Name | Description | Example | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | `Transfer Rules` | Manages whitelists and greylists for holders of a specific SRC20 token. | [Link](https://ropsten.etherscan.io/address/0xad872227FBCEE4271a2F89C4c9B7df0cc86E0e71#code) | | `Featured` | This contract defines the supported token contract features for a specific SRC20 token (e.g. account or contract freezing, additional minting or burning tokens) and allows to check the state of the token contract (e.g if it is currently paused for transfers). | [Link](https://ropsten.etherscan.io/address/0x31830850853A9fa8cb7CC7Fbf5bD5f807B8B5B8e#code) | | `Roles` | This contract defines the owner of the token contract and all assigned roles. Manages the addresses that can perform restricted actions for a specific SRC20 token as defined by the contract owner. SRC20 tokens can have four types of roles: `Owner`, `Authority`, `Manager` and `Delegate`. | [Link](https://ropsten.etherscan.io/address/0x32da71b47888a8c900761dff4fecd37c2e2da654#code) | ### Smart contracts available across all SRC20 Each of the following (pre-existing) smart contracts exist across the SRC20 network and each SRC20 token interacts and registers with them. | Contract Name | Description | Example | | ---------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | `SRC20 Registry` | Registry of all SRC20 tokens created and 'hodler' of the associated SWM stakes | [Link](https://ropsten.etherscan.io/address/0xf37fdada55b07838cb865d9f2a9d449109eb9521#code) | | `Asset Registry` | Registry of asset data for all SRC20 tokens (meta data, esp. NAV) | [Link](https://ropsten.etherscan.io/address/0x54f9b26edc46bd4beaf70ab2771b7ec178241932#code) | | `Minter` | Manages the minting of SRC20 and corresponding SWM stakes of additional tokens added to an existing SRC20 | [Link](https://ropsten.etherscan.io/address/0xe0e57388e696c4db04643147070532111b21b8e8#code) | ### Deployment Sequence As the SRC20 smart contracts need to reference each other, there is a specific deployment order for creating a new SRC20 token. * **Deploy Smart Contracts** * **Step 1:** Deploy a new SRC20 Transfer Rules Smart Contract * **Step 2:** Deploy a new SRC20 Featured Smart Contract * **Step 3:** Deploy a new SRC20 Roles Smart Contract * **Create and Register Token:** Sign a transaction to build and deploy your token exactly as per the configured specifications and register with the global SRC20 contracts * SRC20 Factory Smart Contract * Asset Registry Smart Contract * SRC20 Registry Smart Contract * **Mint SRC20 Tokens** * **Step 4:** Authorize withdrawal of the SWM stake to enable minting of tokens * **Step 5:** Mint the tokens by initiating withdrawal of the SWM stake and minting of SRC20 tokens; Deploys a new SRC20 Featured Smart Contract; in the set-up of this deployment the contracts from the previous steps need to be referenced **Note:** [Swarm.app](https://swarm.app/) is a dapp, which allows you to easily configure your SRC20 token set-up and in the final step the contracts are deployed accordingly and in the correct sequence # SRC20 Token Contract * **Smart Contract:** SRC20 specific * **Created:** Final Step in SRC20 deployment (see [Swarm Tokenization App](https://swarm.app/)) * **Purpose:** Creates and configures a specific SRC20 token * **Example:** [NUVO on Ropsten](https://ropsten.etherscan.io/token/0xAe3CB523328ae4A8E5aFa6E1b856c7F6C67a7d28) ## Feature Description **Read Functions** | Function | Description | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `_allowances()` | See Allowances below | | `name()` | Name of this SRC20 token as set by the issuer | | `totalSupply()` | Current SRC20 supply (in Wei) | | `decimals()` | Number of decimal places this SRC20 token is defined to | | `_maxTotalSupply()` | Maximum supply of this SRC20 tokens that can be minted (in Wei) | | `_totalSupply()` | Same as totalSupply | | `_restrictions()` | Address of the Transfer Restriction contract governing transfers for this SRC20 *(not yet implemented; this function is for future reference)* | | `_balances()` | Returns the token balance for this SRC20 of a specific address | | `balanceOf()` | Returns the token balance for this SRC20 of a specific address | | `_roles()` | Address of the Roles smart contract governing roles for this SRC20 | | `owner()` | Returns the address of the contract owner | | `isOwner()` | Returns *true* if the caller is the current contract owner address of this SRC20 | | `symbol()` | Ticker code or symbol of this SRC20 token | | `getTransferNonce()` | Returns the next nonce expected by transfer functions. Nonce is incremented after each successful transfer | | `_assetRegistry()` | Address of the `AssetRegistry` contract which holds the off-chain properties of all assets tokenized by SRC20 tokens. | | `_features()` | Address of the TokenFeatures smart contract for this SRC20 token | | `allowance()` | Returns the number of tokens a spender address has been allowed to spend on behalf of and from the owner address. It means another address (spender) can be allowed to spend SRC20 residing in the function caller's address | | `_rules()` | Address of the `Transfer Rules` contract for this SRC20 token | | `getTransferNonce()` | Returns next nonce expected by transfer functions for a certain address | **Write Functions** | Function | Description | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `transferTokenForced()` | Transfers tokens from one address to another. This call only requires that `_from_ address` has sufficient tokens; other checks are skipped. Only token issuers can call this function and it requires the `ForceTransfer` feature to be enabled | | `approve()` | Approve the `_spender address_` to spend the specified amount of tokens on behalf of the function caller’s address | | `bulkTransfer()` | Perform multiple token transfers from the token owner's address. The tokens must already be minted. Can only be executed by a delegate 1. Token issuer must first specify a delegate (owner is not a delegate by default) to use this function 2. Token issuer must call `approve()` function to allow delegate to spend | | `burnAccount()` | Burns an amount of tokens from a specified address. Tokens are sent to the zero address, Only token issuers can call this function | | `transferFrom` \[from, to, value] | Internal function used by the `Transfer Rules` contract of this SRC20 to check if a transfer requires an authorization | | `transferToken()` | Transfer token to specified address. Caller needs to provide an authorization signature obtained from MAP API, signed by an authority accepted by the token issuer. *Used by the* `_transfer_` *function after* `_transfer validity_` *is acquired* | | `increaseAllowance()` | Increase the number of SRC20 tokens, by a *value*, that an already permitted spender address can spend on behalf of the function caller | | `mint()` | Can only be called by `Minter` Contract and mints additional tokens for this SRC20. Requires a SWM stake to be made simultaneously within `stakeAndMint()` function in the `Minter` contract | | `updateRestrictionsAndRules()` | Updates the addresses of the Restrictions contract and/or rules `Transfer Rules` contract for this SRC20 token. You can update either one or both, but will be required to enter the one that is not updated alongside the other one. | | `renounceOwnership()` | Contract owner can renounce ownership of this contract. All functions that can only be called by the owner will subsequently no longer be available | | `encodedBulkTransfer()` | Only a delegate can call this function. Performs multiple transfers of this SRC20 from the token owner's address. The tokens must already be minted and in the owners address. If this function is called by someone other than the owner (must be a delegate defined in the `Roles` contract of this SRC20, the owner has to call `approve()` first to set up the delegate's allowance. Data needs to be packed correctly before calling this function | | `burn()` | Can only be called by Owner. Burns an amount of tokens from a specified *address.* *Value* describes the amount in Wei | | `decreaseAllowance()` | Reduces by an amount*,* the number of SRC20 tokens that can be spent by a `_spender address_` from the `caller’s address`. `_Value_` describes the amount in Wei | | `transfer()` | Transfer of an amount of this SRC20 tokens from the a sender address to a recipient’s address respecting the `Transfer Rules` contract | | `transferTokenFrom()` | Transfers an amount of SRC20 token to specified address. Caller needs to provide an authorization signature obtained from MAP API, signed by an authority accepted by the token issuer. *Used by the* `transfer()` *function when authorization is requested* | | `executeTransfer()` | Called by the `Transfer Rules` contract of this SRC20 | | `transferOwnership()` | Transfers ownership of this contract to another address. Can only be called by the contract owner. | **Events** | Event | Description | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | `OwnershipTransferred()` | Event created by contract when initial ownership is created or when the ownership is transferred | | `ManagementTransferred()` | Event created by contract when initial ownership is created or when the ownership is transferred | | `RestrictionsAndRulesUpdated()` | Event created by contract when the restrictions and rules contracts is updated | | `Transfer()` | Event created by contract when a transfer occurs for this SRC20 respecting the `Transfer Rules` (white/greylists) | | `Approval()` | Event created by contract when when a spender has received approval to spend on behalf of another holder of SRC20 tokens | # Transfer Rules Contract * **Smart Contract:** SRC20 specific * **Created:** Step 1 in SRC20 deployment (see [Swarm Tokenization App](https://swarm.app/)) * **Purpose:** Manages whitelists and greylists that permits addresses to hold a specific SRC20 token * **Example:** [NUVO on Ropsten](https://ropsten.etherscan.io/address/0xad872227FBCEE4271a2F89C4c9B7df0cc86E0e71#code) ## Feature Description **Glossary** | Item | Description | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Whitelist | List of addresses able to hold and transfer the specific SRC20 token referring to this `Transfer Rules` contract without requiring approval by the token issuer or an authority | | Greylist | List of addresses able to hold and transfer SRC20 token referring to this `Transfer Rules` contract only with approval by an Authority, as set within the `Rules` contract. If a transfer of tokens is attempted where at least one of the addresses is on the greylist, a request for approval is created in the `Transfer Rules` contract of the corresponding SRC20, for the token issuer to approve/reject. | **Read Functions** | Function | Description | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `_whitelisted()` | Returns if an address is whitelisted | | `_reqNumber()` | Returns the index of the most recent greylist transfer request | | `_transferReq()` | Returns the details of a specific greylist transfer request. Returns the from address, to address and the value to be transferred. *Note: To view the details of `_reqNumber “1”` use `_transferReq “0”` and so on.* | | `_greyList()` | Returns if an address is greylisted | | `_src20()` | Displays the address of the corresponding `SRC20 Token` contract (after it is created) | | `owner()` | Displays the address of the contract owner | | `isGreyListed()` | Returns if an address is greylisted | **Write Functions** | Function | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `bulkUnGreyListAccount()` | Function to remove multiple addresses from the whitelist. Each account must be separated by a comma (e.g. \[0x00, 0x00, 0x00]). Can only be called by an Authority, as set within the `Rules` contract | | `doTransfer()` | Internal function when setting up a transfer. It is executed when transferring SRC20 tokens that checks if the transfer can successfully execute respecting transfer restrictions. If both addresses are on the whitelist, the transfer can go through. If either address is in the greylist, it creates a transfer authorization request. | | `authorize()` | Internal function callable from another contract to check if a specific transfer of this SRC20 requires authorization. It returns true if an `address from` is either in the whitelist or greylist AND if the `address to` is also either in the whitelist or greylist | | `cancelTransferRequest()` | Cancels a specific transfer request. Can only be called by initiator of transfer request | | `bulkUnWhitelistAccount()` | Owner can call this function to remove multiple addresses from the whitelist. Each account must be separated by a comma (e.g. \[0x00, 0x00, 0x00]) Can only be called by an Authority, as set within the `Rules` contract | | `whitelistAccount()` | Adds a single address to the whitelist. Can only be called by the contract owner | | `renounceOwnership()` | Contract owner can renounce ownership of this contract | | `bulkWhitelistAccount()` | Adds multiple addresses to the whitelist. Each account must be separated by a comma (e.g. \[0x00, 0x00, 0x00]). Can only be called by the contract owner | | `unGreyListAccount()` | Removes a single address from the greylist. Can only be called by the contract owner | | `transferApproval()` | For token issuer to approve pending transfers. Note, to approve `transferReq` “3” , enter `reqNumber` “2” | | `bulkGreyListAccount()` | Adds multiple addresses to the greylist. Each account must be separated by a comma (e.g. \[0x00, 0x00, 0x00)]. Can only be called by the contract owner | | `GreyListAccount()` | Adds a single address to the greylist. Can only be called by the contract owner | | `unWhiteListAccount()` | Removes a single address from the whitelist. Can only be called by the contract owner | | `transferOwnership()` | Transfers ownership of this contract to another address. Can only be called by the contract owner | | `setSRC()` | Registers this `Transfer Rules` contract with a specific `SRC20 Token` contract for which these rules apply. The `Transfer Rules` contract is deployed in advance of the `SRC20 Token` contract and therefore requires this reference set once after its creation. Can only be set once and is disabled after the creation of this contract. Calling it subsequently will return an error | # Featured Contract * **Smart Contract:** SRC20 specific * **Created:** Step 2 in SRC20 deployment (see [Swarm Tokenization App](https://swarm.app/)) * **Purpose:** Manages additional token contract features for a specific SCR20 token contract, and checks the state of the SRC20 token contract (e.g. whether it is currently paused for transfers) * **Example:** [NUVO on Ropsten](https://ropsten.etherscan.io/address/0x31830850853A9fa8cb7CC7Fbf5bD5f807B8B5B8e#code) ## Feature Description **Read Functions** | Function | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `isTokenPaused()` | Displays *true*/*false* based on whether the SRC20 token contract is paused | | `pausable()` | Displays the index of this feature, for checking if enabled. *Index = 2* | | `paused()` | Displays *true*/*false* based on whether the SRC20 token contract is paused | | `isEnabled()` | Returns *true*/*false* based on whether a specific SRC20 token feature is enabled. Requires the user to enter the index of the feature. | | `accountBurning()` | Displays the index of this feature, for checking if enabled. *Index = 4* | | `accountFreezing()` | Displays the index of this feature, for checking if enabled. *Index = 8* | | `_enabledFeatures()` | Internal function | | `owner()` | Returns the address of the contract owner | | `isOwner()` | Returns *true* if the caller is the contract owner | | `forceTransfer()` | Displays the index of this feature, for checking if enabled. *Index = 1* | | `checkTransfer()` | Call to check if a transfer of SRC20 tokens between two addresses will pass under any restrictions set by this `Features` contract. Transfer rules need to be checked separately in the `Transfer Rules` contract of this SRC20 | | `isAccountFrozen()` | Returns *true*/*false* whether a specified account holding these SRC20 tokens is frozen, meaning it is disabled from being able to make transfers of any of this SRC20 token | **Write Functions** | Function | Description | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pauseToken()` | Pauses the SRC20 token. No transfers of any kind can take place while being paused. Can only be called by the contract owner if `Pausable()` functionality is enabled | | `renounceOwnership()` | Leaves this `Token Features` contract without an owner. Can only be called by the contract owner. Subsequently, it will no longer be possible to call functions with `onlyOwner` modifiers, thereby removing any functionality that is only available to the contract owner | | `unfreezeAccount()` | Unfreezes a specific address, enabling it to initiate transfers. Can only be called by the contract owner if `AccountFreezing()` functionality is enabled | | `unPauseToken()` | Reverses the pausing of a token and transfers for this SRC20 token will resume being possible. Can only be called by the contract owner if `Pausable()` functionality is enabled. | | `freezeAccount()` | Freezes a specific address, disabling it from being able to initiate transfers of this SRC20 token. Can only be called by the contract owner if `AccountFreezing()` functionality is enabled | | `transferOwnership()` | Transfers ownership of this `Token Features` contract to a new contract owner. Can only be called by the contract owner | # Roles Contract * **Smart Contract:** SRC20 specific * **Created:** Step 3 in SRC20 deployment (see [Swarm Tokenization App](https://swarm.app/)) * **Purpose:** Manages the addresses that can perform restricted actions for an SRC20 as defined by the contract owner. SRC20 tokens can have four types of roles: Owner, Authority, Manager and Delegate * **Example:** [NUVO on Ropsten](https://ropsten.etherscan.io/address/0x32da71b47888a8c900761dff4fecd37c2e2da654#code) ## Feature Description **Glossary** | Item | Description | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Owner | Owner is the owner of the `Roles` smart contract | | Delegate | Address responsible for updating the KYA document, Net Asset Value, transfer restrictions and rules and perform bulk transfers that bypass whitelist and greylist. There can be multiple authorities granted | | Authority | Address authorized to maintain the white and greylists (add/remove) for a specific SRC20 token, as well as authorize transfers subject to a greylist | | Manager | There is one manager, which is a smart contract responsible for minting or burning tokens. It is initially set to be the `SRC20 Registry` contract where you can increase or decrease the supply of the corresponting SRC20 | **Read Functions** | Function | Description | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `isDelegate()` | Returns *true*/*false* whether an address is a Delegate for this contract | | `isAuthority()` | Returns *true*/*false* whether an address is an Authority for this contract | | `manager()` | Returns the address of the Manager contract. This is normally the address of the `SRC20Registry` contract, where staking and minting is executed | | `owner()` | Returns the address of the contract owner | | `isOwner()` | Returns *true* if the caller is the current owner | | `isManager()` | Returns *true* if the caller is the current Manager | **Write Functions** | Function | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `renounceManagement()` | Relinquish the ability to manage this contract. *Attention:* *If a manager renounces management there is no possible way to mint or burn SRC20 tokens anymore* | | `addAuthority()` | Adds an address authorized to maintain the white and greylists (add/remove) for a specific SRC20 token, as well as authorize transfers subject to a greylist. Can only be called by the owner | | `removeDelegate()` | Remove an address from being able to perform delegate functions. Can only be called by the owner | | `renounceOwnership()` | Can only be called by the owner and it sets the owner address to `0x0` | | `removeAuthority()` | Removes an address authorized to maintain the white and greylists (add/remove) for a specific SRC20 token, as well as authorize transfers subject to a greylist. Can only be called by the owner | | `transferManagement()` | A manager can transfer their role to a new address | | `addDelegate()` | Add an address that is able to perform delegate only functions. Can only be called by the owner | | `transferOwnership()` | An owner can transfer their role to a new address or to a multisig wallet or to a multisig wallet | # SRC20 Registry Contract * **Smart Contract:** globally across all SRC20 * **Created:** pre-exists / created only once * **Purpose:** Registry of all SRC20 tokens created and the associated SWM stakes * **Example:** [On Ropsten](https://ropsten.etherscan.io/address/0xf37fdada55b07838cb865d9f2a9d449109eb9521#code) ## Feature Description **Glossary** | Item | Description | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | (SWM) Stake | On Swarm token issuers are required to stake an amount of SWM token to trigger the minting and distribution of SRC20 tokens; the required stake amounts follow a [staking rate card](https://docs.swarm.fund/SWM_Issuance_Staking_Rate_Card.png) which has been adopted as a network policy by the Swarm Network | **Read Functions** | Function | Description | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `swmNeeded()` returns `(uint256)` | Returns the SWM stake amount needed to mint an additional amount of specific SRC20 tokens; this function translates the Net Asset Value into USD denominated staking amounts based on the network policy and then uses the referenced SWMPriceOracle to translate them into SWM values based on current prices | | `contains()` returns `(bool)` | Returns *true* when a SRC20 token address is successfully registered with this `SRC20 Registry` contract | | `getStake()` returns `(uint256)` | Returns the amount of SWM staked for a specific SRC20 | | `owner()` returns `(address)` | Returns the address of the contract owner | | `isOwner()` returns `(bool)` | Returns *true* if the caller is the contract owner | | `calcTokens()` | External function allowing users to check the corresponding amount of SRC20 tokens that can be minted for a SWM stake value; responds in SRC20 in Wei (e.g. 1 = 1 additional SRC20); This differs from the `calcStake()` function in the `Minter` contract which is for staking/minting a brand new token. This function instead is for calculating the additional incremental stake on an existing SRC20 token | | `getMinter()` returns `(address)` | Returns address of the `Minter` contract for a specific SRC20 | | `getTokenOwner()` returns `(address)` | Returns the address of the owner (and staker) of a specific SRC20 | **Write Functions** | Function | Description | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `remove()` returns `(bool)` | Removes specific SRC20 from the `SRC20 Registry`; can only be executed by the contract owner; returns *true* on success | | `addFactory()` returns `(bool)` | Adds new factory to the `SRC20 Registry` contract address that can register a specific SRC20 token; returns *true* on success | | `removeMinter()` returns `(bool)` | This proxy function removes a contract from the list of authorized minters; use the address of the `Minter` contract to remove; returns *true* on success | | `removeFactory()` returns `(bool)` | This proxy function removes a `SRC20Factory` contract that can register a specific SRC20 token; use the address of the `SRC20Factory`contract to remove; returns *true* on success | | `renounceManagement()` returns `(bool)` | Allows the manager to renounce management for a specific SRC20 token address; returns *true* on success | | `getSrc20toSwmRatio()` returns `Amount()` | External function for calculating how much SWM tokens are needed to be staked in order to get 1 SRC20 token | | `increaseSupply()`returns `(bool)` | This function the token issuer can call in order to increase his SRC20 supply and stake his tokens; enter parameters with `src20` (address of src20 token contract), `swmAccount` (address from which stake tokens are going to be deducted), and `srcValue` (Value of desired SRC20 token supply increase in unit256/Wei); returns *true* on success | | `renounceOwnership()` | Contract owner can renounce ownership of the contract | | `transferManagement()`returns `(bool)` | Allows the manager to transfer management for a specific SRC20 token address to a new address; returns *true* on success | | `addMinter()` | This proxy function adds a contract to the list of authorized minters | | `mintSupply()` returns `(bool)` | Mints additional supply of a specific SRC20 token based on SWM token stake; can be used for initial supply and subsequent minting of new SRC20 tokens; When used, Manager will update SWM/SRC20 values in this call and use it for token owner's `increaseSupply()` / `decreaseSupply()` calls, minting/burning SRC20 based on current SWM/SRC20 ratio. Only owner (Swarm network controlled address) of this contract can invoke this method; returns *true* on success | | `put()` | Adds a SRC20 token to the `SRC20 Registry`; only factories can add; returns *true* on success | | `decreaseSupply()` returns `(bool)` | This function the token issuer can call in order to decrease his SRC20 supply and receive his SWM stake; enter parameters with `src20` (Address of src20 token contract), `swmAccount` (address to which SWM stake tokens will be returned), and `srcValue` (Value of desired SRC20 token supply decrease in unit256/Wei); returns *true* on success | | `transferOwnership()` | Transfers ownership of this contract to another address. Can only be called by the contract owner | # Asset Registry Contract * **Smart Contract:** globally across all SRC20 * **Created:** pre-exists / created only once * **Purpose:** Registry of asset data for all SRC20 tokens (meta data, esp. NAV) * **Example:** [On Ropsten](https://ropsten.etherscan.io/address/0x54f9b26edc46bd4beaf70ab2771b7ec178241932#code) ## Feature Description **Glossary** | Item | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | KYA (Know Your Asset) | The intent of KYA is to create cryptographically-proven single-source-of-truth for metadata of a specific SRC20 and the asset it represents; token issuers can add and update dozens of parameters and attributes of their project, store them on a website (URL) or IPFS file; this allows investors to have unfettered access to a full history of data change over the life-cycle of the token | | NAV (NetAssetValue) | NAV describes the value of the asset which is tokenized by a specific SRC20; it’s a common value in capital markets to describe the value of an asset and is based on underlying reports and assessments about the asset; as NAV represents the value of assets on the Swarm network it is used as the key value to determine the required SWM staking amounts for each SRC20 token | **Read Functions** | Function | Description | | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `getNetAssetValueUSD()` | Returns the currently registered NAV for a specific SRC20 | | `_src20Factory()` returns `(address)` | Returns the address of the `SRC20 Factory` contract | | `owner()` returns `(address)` | Returns the address of the SRC20 Factory contract | | `isOwner()` returns `(bool)` | Returns *true* if the caller is the contract owner | | `assetList()` returns `kyaHash(bytes32), kyaUrl(string), netAssetValueUSD(uint256)` | Returns all KYA data (NAV, KYA hash, KYA URL) registered in this contract for a specific SRC20 | | `getKYA()` returns `(bytes32), (string)` | Returns the KYA data (KYA hash, KYA URL) registered in this contract for a specific SRC20 | **Write Functions** | Function | Description | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | `addAsset()` | Creates a new record for of KYA data (NAV, KYA hash, KYA URL) for a specific SRC20 in this contract | | `renounceOwnership()` | Contract owner can renounce ownership of the contract | | `updateNetAssetValueUSD()` | Updates the NAV value for a specific SRC20 | | `TransferOwnership()` returns `newOwner(address)` | Transfers ownership of this contract to another address | | `udateKYA()` | Updates the KYA data (KYA hash, KYA URL) registered in this contract for a specific SRC20 | # Minter Contract * **Smart Contract:** globally across all SRC20 * **Created:** pre-exists / created once * **Purpose:** manages the minting of SRC20 and corresponding SWM stakes of additional tokens added to an existing SRC20 * **Example:** [On Ropsten](https://ropsten.etherscan.io/address/0xe0e57388e696c4db04643147070532111b21b8e8#code) ## Feature Description **Read Functions** | Function | Description | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `calcStake()` | Returns the SWM stake amount needed to mint an additional amount of specific SRC20 tokens; this function translates the Net Asset Value into USD denominated staking amounts based on the network policy and then uses the referenced SWMPriceOracle to translate them into SWM values based on current prices | | `_SWMPriceOracle()` returns `(address)` | Displays the address for the price oracle contract used to determine the SWM price | | `_registry()` returns `(address)` | Displays the `SRC20 Registry` contract used in this contract | | `_asset()` returns `(address)` | Displays the `Asset Registry` contract used in this contract | **Write Functions** | Function | Description | | ---------------- | ----------- | | `stakeAndMint()` | | Calling this function withdraws the previously authorized number of SWM tokens required for staking from the caller’s address, and then mints `numSRC20Tokens` of `src20` tokens in the caller’s address.; returns **True** on success | # SRC20Factory Contract * **Smart Contract:** globally across all SRC20 * **Created:** pre-exists / created once * **Purpose:** Manages the minting of SRC20 and corresponding SWM stakes of additional tokens added to an existing SRC20 * **Example:** [On Ropsten](https://ropsten.etherscan.io/address/0xe0e57388e696c4db04643147070532111b21b8e8#code) ## Feature Description **Read Functions** | Function | Description | | -------- | ----------- | | none | | **Write Functions** | Function | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `create()` | Creates new SRC20 contract using all the named parameters. Expects token properties and desired capabilities of the token. Only SRC20Factory owner can call this function. Emits SRC20Created event with address of new token. | # Swarm Powered Fundraise Note: This page describes an older version of the smart contract suite. We will update it soon! ![](/files/-M8LkLtfGioRCtaAQ4dL) ## Introduction The SwarmPoweredFundraise (SPF) is a significant addition to the open Swarm protocol and provides powerful tools to perform regulatory compliant fundraises for security tokens. The requirement is that the token for which the fundraise occurs is operated on the [SRC20](https://www.swarm.fund/src20) standard. An SFP is like a module that can be used for each distinct fundraise for an SRC20 token. Like SRC20, the SPF stack is open source, so the Swarm network welcomes token issuers and service providers freely use, extend and customize. ## Smart Contract Index The following four contracts are created in relation to a specific SRC20 token and interact with one another and other global SRC20 smart contracts. ![](/files/-M72rxlDUerjoJ4ut9bC) ### Smart contracts specific to each SwarmPoweredFundraise For each new SRC20 token, one of each of these smart contracts is newly created. | Contract Name | Description | Example | | ------------------------ | ------------------------------------------------------------------------------------ | ------- | | Currency Registry | Registers all currencies that will be accepted in a specific Swarm Powered Fundraise | TBD | | Affiliate Manager | Registers affiliates and their commissions for a SwarmPoweredFundraise | TBD | | Swarm Powered Fundraise | Operates the actual SwarmPoweredFundraise; finalizes via stakeToMint | TBD | | Contributor Restrictions | Manages whitelist and restrictions for each contributor in a Swarm Powered Fundraise | TBD | ### Smart contracts available across all SwarmPoweredFundraises Each of the following (pre-existing) smart contracts exist across the SRC20 network and each SRC20 token interacts and registers with them. | Contract Name | Description | Example | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | Uniswap Proxy | Proxy Contract that makes ongoing calls to the different Uniswap exchanges to obtain the prices of accepted currencies used in Swarm Powered Fundraises | TBD | | Issuer Stake Offer Pool (ISOP) | Allows SWM token holders to offer their tokens OTC for issuance stake; NOT YET FORMALLY RELEASED AND FUNCTIONAL | TBD | ### Deployment Sequence 1. Deploy It needs SWM token address during deployment 2. Deploy It needs SRC20Registry deployment address during deployment; after `SRC20Factory` is deployed, go to deployed `SRC20Registry` contract and add this `SRC20Factory` deployment address in `addFactory()` function 3. Deploy It needs `SRC20Factory` deployment address during deployment 4. Deploy It needs SWM price in the form of two variables like numerator and denominator 5. Deploy It needs the following parameters: 1/ `SRC20Registry address`, 2/ `AssetRegistry` address and 3/ `SWMPriceOracle` address. After `GetRateMinter` is deployed, goto deployed `SRC20Registry` contract and add this `GetRateMinter` address in `addMinter()` function 6. Deploy It needs owner address, most of the time it will be issuer wallet address 7. Deploy It needs the following parameters: 1/ `owner address`, 2/ `SRC20Registry address` and 3/ `TransferRules address` 8. Deploy It requires the following parameters: 1/ `owner address` and 2/ any number greater than 0 to enable features 9. Go to `SRC20Factory` deployed contract, generate new SRC20 token using `create()` function 10. Deploy 11. Deploy Register whatever currencies you want to accept for this fundraise using `addCurrency()` function; most of the time it will be ZERO address for ETH, DAI address, USDC address and WBTC address. Register your base currency you want to use for this fundraise using `setBaseCurrency()` function. 12. Deploy This requires several parameters: like `label`, `SRC20 address`, `CurrencyRegistry address`, `startDate`, `endDate`, `softcap` and `hardcap` 13. Deploy 14. Deploy It requires the following parameters: 1/ `SwarmPoweredFundraise address` and 2/ `number of contributors` want to allow for this fundraise 15. Go to `SwarmPoweredFundraise` deployed contract and complete the remaining setup using `setupContract()` function. `setupContract` requires many parameters like `SRC20 token price`, `minimum amount of contribution`, `maximum amount of contribution`, `AffiliateManager address`, `ContributorRestrictions address`, `GetRateMinter address` and `lock` or `unlock` contributions 16. Go to `SRC20` deployed contract and set `SwarmPoweredFundraise` address using `setFundRaiseAddr()` function 17. Go to `ContributorRestrictions` deployed contract and whitelist all your contributors using `whitelistAccount()` function. After this contributors can contribute to fundraise. 18. Once fundraise is completed, issuer can call `stakeAndMint()`. This function will do the following in one process: 1/ staking his equivalent SWM tokens, 2/ minting SRC20 tokens and 3/ withdrawing total contributor funds to contract owner # Uniswap Proxy Contract \- BETA - * **Smart Contract:** globally across all Swarm Powered Fundraises * **Created:** pre-exists / created only once and then referenced in each Swarm Powered Fundraise contract * **Purpose:** Proxy Contract that makes ongoing calls to the different Uniswap exchanges to obtain the prices of accepted currencies used in Swarm Powered Fundraises * **Example:** TBD ## Feature Description ### Read Functions | Function | Description | | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `getRate(address, address, uint256, uint256)` returns `(uint256, uint256)` | Returns the exchange rate between first and second address. The first parameter is the token address of the currency to be exchanged from, the second parameter is the address of the currency to be exchanged to, the third parameter is the value in Wei to be exchanged and the fourth parameter is the decimal places; e.g. to get the rate of 1 ETH in DAI `getRate(“0x0000000000000000000000000000000000000000”,”0x2a1530C4C41db0B0b2bB646CB5Eb1A67b7158667”,1000000000000000000,0)` | | `isOwner()` returns `(bool)` | Returns true if the caller is the current contract owner address of this contract | | `owner()` returns `(address)` | Returns the address of the owner of this contract | ### Write Functions | Function | Description | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `addOrUpdateExchange(address, address)` | Adds an exchange pair between two currencies to the proxy. The first parameter is the token address and the second parameter is the Uniswap exchange address; e.g. to set up DAI stable coin the following should be called `addOrUpdateExchange("0x6B175474E89094C44Da98b954EedeAC495271d0F”,”0x6B175474E89094C44Da98b954EedeAC495271d0F")` | | `renounceOwnership()` | Contract owner can renounce ownership of this contract. | | `transferOwnership()` | An owner can transfer their role to a new address or to a multisig wallet | # Currency Registry Contract \- BETA - * **Smart Contract:** specific to a Swarm Powered Fundraise for a specific SRC20 * **Created:** review the [SPF Deployment Sequence](https://www.swarmnetwork.org/swarm-protocol/spf#deployment-sequence); then referenced in the Swarm Powered Fundraise contract * **Purpose:** Registers all currencies that will be accepted in a specific Swarm Powered Fundraise * **Example:** TBD ## Feature Description ### Read Functions | Function | Description | | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `currenciesList[address]` returns `(struct)` | An array of CurrencyStats Objects. These objects have the following structure: `struct CurrencyStats {address erc20address; address exchangeProxy; uint256 finalExchangeRate; uint256 totalBufferedAmount; uint256 totalQualifiedAmount;}` | | `getAcceptedCurrencies()` returns `(address[])` | Returns an array of the accepted currencies in a Swarm Powered Fundraise | | `currencyIndex[address]` returns `(uint256)` | A mapping of accepted currency addresses to integers; To obtain the index of DAI in the contract use `currencyIndex(“0x6B175474E89094C44Da98b954EedeAC495271d0F”)` | | `lockedExchangeRate(address)` returns `(uint256)` | Returns the value of the locked exchange rate of the currency in the first parameter | | `isAccepted(address)` returns `(bool)` | Returns if a specific currency is accepted in a Swarm Powered Fundraise; To check if the fundraise accepts DAI use `isAccepted(“0x6B175474E89094C44Da98b954EedeAC495271d0F”)` | | `getBaseCurrency()` returns `(address)` | Returns the base currency in which a Swarm Powered Fundraise is denominated | | `toUSD(uint256, address)` returns `(uint256)` | Converts the amount given as the first parameter into USD. The second parameter is the address of the currency to be converted to USD. | | `toBCY(uint256, address)` returns `(uint256)` | Converts the amount given as the first parameter into the Base Currency. The second parameter is the address of the currency to be converted to Base Currency | | `getRate(address, address, uint256, uint256)` returns `(uint256, uint256)` | Returns the exchange rate between the first and the second address. The first parameter is the token address of the currency to be exchanged from, the second parameter is the address of the currency to be exchanged to, the third parameter is the value in Wei to be exchanged and the fourth parameter is the decimal places. E.g. to get the rate of 1 ETH in DAI use `getRate(“0x0000000000000000000000000000000000000000”,"0x2a1530C4C41db0B0b2bB646CB5Eb1A67b7158667”,1000000000000000000,0)` | | `isOwner()` returns `(bool)` | Returns true if the calling address is the contract owner | | `owner()` returns `(address)` | Returns the address of the contract owner | ### Write Functions | Function | Description | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `addCurrency(address, address)` returns `(bool)` | Adds a currency to the list of currencies accepted in a Swarm Powered Fundraise. The first parameter is the token address and the second parameter is the address of the exchange proxy contract | | `lockExchangeRates()` | Locks the exchange rates of currencies accepted in a Swarm Powered Fundraise to the Base Currency | | `setBaseCurrency(address)` | Sets a base currency from the list of currencies accepted in a Swarm Powered Fundraise; the parameter is the address of the base currency to be set | | `setUSDERC20(address)` returns `(bool)` | Sets the currency address that will be used as the default USD dollar oracle address for a Swarm Powered Fundraise. Usually set to USDC; e.g. to set to USDC use `setUSDERC20(“0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48”)` | | `renounceOwnership()` | Contract owner can renounce ownership of this Currency Registry contract | | `transferOwnership()` | Transfers ownership of this Currency Registry contract to another address | # Affiliate Manager Contract \- BETA - * **Smart Contract:** specific to a Swarm Powered Fundraise for a specific SRC20 * **Created:** review the [SPF Deployment Sequence](https://www.swarmnetwork.org/swarm-protocol/spf#deployment-sequence); then referenced in the Swarm Powered Fundraise contract * **Purpose:** Registers all currencies that will be accepted in a specific Swarm Powered Fundraise * **Example:** TBD ## Feature Description ### Read Functions | Function | Description | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | `affiliateLinks(address)` returns `(string)` | Returns the affiliate link of an affiliate address | | `affiliates(address)` returns `(struct)` | Returns the Affiliate object from the affiliate address: `struct Affiliate {string affiliateLink;string affiliateLink;uint256 percentage;}` | | `getAffiliate(string)` returns `(address, uint256)` | Returns the address and percentage amount of an affiliate. It takes the affiliate link as a parameter | | `isOwner()` returns `(bool)` | Returns true if the calling address is the contract owner | | `owner()` returns `(address)` | Returns the address of the owner of the contract | ### Write Functions | Function | Description | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `removeAffiliate(address)` returns `(bool)` | Removes an affiliate from the list of affiliates accepted in a Swarm Powered Fundraise; the parameter is the address of the affiliate wallet | | `setupAffiliate(address, string, uint256)` returns `(bool)` | Setup a new affiliate; the first parameter is the address of the affiliate’s wallet, the second is the affiliate link and the third is the participation percentage amount that determines participation of the affiliate whenever a contribution references the affiliate link | | `renounceOwnership()` | Contract owner can renounce ownership of the contract | | `transferOwnership()` | Transfers ownership of this Affiliate Manager contract to a new contract owner | # Swarm Powered Fundraise Contract \- BETA - * **Smart Contract:** specific to a Swarm Powered Fundraise for a specific SRC20 * **Created:** review the [SPF Deployment Sequence](https://www.swarmnetwork.org/swarm-protocol/spf#deployment-sequence); this contract references all other previously deployed contracts related to this fundraise * **Purpose:** Operates the actual SwarmPoweredFundraise; finalizes via stakeToMint * **Example:** TBD ## Feature Description ### Read Functions | Function | Description | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `label()` returns `(string)` | The label of the current fundraise | | `startDate()` returns `(uint256)` | Start date of the fundraise in UNIX time | | `endDate()` returns `(uint256)` | End date of the fundraise in UNIX time | | `minAmountBCY()` returns `(uint256)` | Minimum amount accepted as contribution in base currency | | `maxAmountBCY()` returns `(uint256)` | Maximum amount accepted as contribution in base currency | | `expirationTime()` returns `(uint256)` | Time required for the issuer to stake and mint security tokens after the fundraise has been successfully completed. If the expiration time is reached, all contributors are able to get a refund | | `src20()` returns `(address)` | The SRC20 token that is being offered as a security | | `minter()` returns `(address)` | The contract that is responsible for minting the security tokens after the stake has been made | | `affiliateManager()` returns `(address)` | The contract address of the Affiliate Manager contract which is responsible for managing affiliate addresses, links and commissions | | `contributorRestrictions()` returns `(address)` | The contract address of the Contributor Restrictions contract which is responsible for handling contributor restrictions | | `currencyRegistry()` returns `(address)` | The contract address of the Currency Registry which is responsible for managing accepted currencies in the fundraise | | `offchainContributionsAllowed()` returns `(bool)` | Returns true if off-chain contributions are allowed. If off chain contributions are allowed the token manager can manually input contributions into the contract | | `softCapBCY()` returns `(uint256)` | The soft cap amount in base currency | | `hardCapBCY()` returns `(uint256)` | The hard cap amount in base currency | | `SRC20tokenPriceBCY()` returns `(uint256)` | The price of each SRC20 token being sold in base currency. If this is set to 0 the value will be calculated based off of tokens to mint | | `SRC20tokensToMint()` returns `(uint256)` | The amount of SRC20 tokens that are for sale and will be minted. It will be 0 if the fundraising is based off of a token price | | `fundraiseAmountBCY()` returns `(uint256)` | The amount raised in base currency | | `numberOfContributors()` returns `(uint256)` | The total number of unique addresses that have contributed to the fundraise | | `totalIssuerWithdrawalsBCY()` returns `(uint256)` | The total amount the issuer can withdraw in base currency | | `issuerWallet()` returns `(address)` | Returns the address of the wallet which will receive the raised funds | | `isFinished()` returns `(bool)` | Returns true if the fundraising has been cancelled or successfully finished< | | `setupCompleted()` returns `(bool)` | Returns true if the fundraising set up is complete | | `contributionsLocked()` returns `(bool)` | Returns true if contributions are locked. This means contributors are not able to obtain a refund | | `contributionsList[address]` returns `(array)` | Each contributor address holds an array of a Contribution structure like this `struct Contribution {address currency;uint256 amount;uint256 sequence;ContributionStatus status;}` | | `bufferedContributions[address][address]` returns `(uint256)` | These are contributions that have yet to be counted as valid; the first parameter is the contributor and the second is the currency address in this format `bufferedContributions[contributor_address][currency_address]= amount contributed` | | `bufferedSums[address]` returns `(uint256)` | Total sum of pending contributions per currency address | | `qualifiedContributions[address][address]` returns `(uint256)` | These are contributions that have been qualified and count in the fundraise. The first parameter is the contributor and the second is the currency address | | `qualifiedSums[address]` returns `(uint256)` | Total sum of qualified contributions per currency address | | `historicalBalance[address]` returns `(array)` | An array of Balance structures per currency address. `struct Balance {uint256 sequence;uint256 balance;}` | ### Write Functions | Function | Description | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `setupContract(uint256, uint256, address, address, bool)` | This function finishes setting up the contract once it has been deployed. The parameters are the following: 1/ Minimum contribution amount accepted in base currency; 2/ Maximum contribution amount accepted in base currency; 3/ Affiliate Manager contract address; 4/ Contributor Restrictions contract address; 5/ A boolean that sets if the contributions are locked | | `cancelFundraise() returns (bool)` | It cancels the fundraise; this function can only be called by the contract owner (token issuer) | | `getContributionsBCY(address, bool)` returns `(uint256)` | Returns the contributor’s sum of contributions in base currency; the contributor’s address is the first parameter and the second parameter is a boolean for qualified contributions (*true*) or pending contributions (*false*) | | `addOffchainContribution(address, address, uint256)` returns `(bool)` | If off-chain contributions are allowed the token issuer can add contributions manually so the contract can later mint and distribute tokens for manual contributions; this feature requires trust on the part of the token issuer | | `contribute(address, uint256, string)` returns `(bool)` | Allow contributions of ERC20 tokens that are registered in the `Currency Registry` contract. The first parameter is the address of the ERC20, the second is the amount in Wei and the third is the affiliate link if there is one; e.g. to contribute 100 DAI with affiliate link name affiliate use `contribute("0x6b175474e89094c44da98b954eedeac495271d0f",100000000000000000000,"affiliate")` | | `getRefund()` returns `(bool)` | Allow a user to get ERC20 and ETH refunds if the fundraise has passed expiration time or has been cancelled | | `acceptContributor(address)` returns `(bool)` | Function that can only be called by the Contributor Restriction smart contract after a user has been whitelisted by the issuer | | `removeContributor(address)` returns `(bool)` | Function that can only be called by the Contributor Restriction smart contract after a user's address has been unwhitelisted by the token issuer | | `stakeAndMint(address, uint256)` returns `(bool)` | Allow token issuer to stake SWM tokens in order to mint SRC20 tokens. The token issuer can either use `ISOP` or stake directly if they have the required SWM. The `stakeAndMint()` function will also conclude the fundraise by internally calling the function `finishFundraise()`. When `stakeAndMint()` finalizes the fundraise, that the people whitelisted for a fundraise are automatically added to the SRC20 Transfer Rules via `bulkWhitelistAccount()`. Otherwise `stakeAndMint()` could run into problems because the holders are not able to hold the newly minted SRC20 tokens | | `claimTokens()` returns `(uint256)` | Allow contributors to claim their portion of SRC20 tokens after the fundraising is successfully over | # Contributor Restrictions Contract \- BETA - * **Smart Contract:** specific to a Swarm Powered Fundraise for a specific SRC20 * **Created:** review the [SPF Deployment Sequence](https://www.swarmnetwork.org/swarm-protocol/spf#deployment-sequence); then referenced in the Swarm Powered Fundraise contract * **Purpose:** Manages whitelist and restrictions for each contributor in a Swarm Powered Fundraise * **Example:** TBD ## Feature Description ### Read Functions | Function | Description | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `fundraise()` returns `(address)` | Returns the address of the Swarm Powered Fundraise contract that this Contributor Restrictions contract applies to | | `maxContributors()` returns `(uint256)` | Returns the maximum number of contributors that can participate in a Swarm Powered Fundraise | | `isAllowed(account)` returns `(bool)` | Checks if an account is on the whitelist of a Swarm Powered Fundraise and the contributor list has not reached the maximum number of contributors | | `checkRestrictions(address)` returns `(bool)` | Checks if an account is on the whitelist and is not above the maximum number of contributors | ### Write Functions | Function | Description | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `whitelistAccount(address)` | Adds an address to the whitelist of a Swarm Powered Fundraise and accepts any pending contribution | | `unWhitelistAccount(address)` | Removes an address from the whitelist of a Swarm Powered Fundraise and removes any qualified contributions by the address | | `bulkWhitelistAccount(address[])` | Whitelists an array of addresses for a Swarm Powered Fundraise | | `bulkUnWhitelistAccount(address[])` | Removes an array of addresses from the whitelist of a Swarm Powered Fundraise | # mySwarm.app Currently in audit. Coming soon! mySwarm.app is a UI built on SPF contracts, issued on SRC20 protocol. **Create a regulatory compliant token.** **Run a fundraise and gather investor contributions.** **Distribute your tokens to investors after the fundraise.** **Manage your tokens, distribute dividends, and more.** ![](/files/-MWxxn2XHJG-1BhUd7Q7) # kovan.mySwarm.app (test version, please use this) A Kovan test version of mySwarm.app is available at **kovan.mySwarm.app** To change to Kovan Network using Metamask, open the app and select the dropdown like this below and you will see Kovan network: ![](/files/-MZDX1dh3UWDAfqjZcvk) You'll need Kovan ETH, SWM, and USDC. **For Kovan test $SWM and $USDC** please come to our telegram and make a request: **For Kovan $ETH** please visit and log in with your GitHub account: **Make sure you add these contracts to metamask for Kovan so they show up in your wallet:** Kovan SWM: 0x46874bfc5ed8d1c238f615bb95c13b99994aa578 Kovan USDC: 0xf2ed3ca62b1d4dd57ad46184634f6b1f8be85ee3 Kovan ETH should already populate If you have any questions at all please come to Telegram and ask! # Mumbai Testnet swm: 0x3505f494c3f0fed0b594e01fa41dd3967645ca39 swmPriceOracle: 0x18F98d695aaEed2f2705512D885b0D4FA6B33062 src20Registry: 0x29D3FF558b35CF404F37817f6B9586Ea3fC44559 tokenMinter: 0x68C3ddF1a019f462B6162d3201D9bC5462197F6c usdc: 0xa2e45Ad7431CB8599e71857085737869eacbf842 disperse: 0x262A2618785705253585CD16D47ECE69bA0bb8Bc fundraiserManager: 0x73dC2C71f1344F5B2bFDc16A1d803A272BB4dCC1 # Legacy Masternode Reward Collection We've discontinued the Masternode reward program. Here's what you need to know: Gas prices were too high to continue Masternode reward distribution. We've moved the legacy reward claim to the xDai network. All rewards prior to July, 2020 are on Ethereum Mainnet. All rewards after July, 2020 are on xDai network. We've built a UI to claim **all** rewards from Ethereum Mainnet and xDai: [**https://collect.myswarm.app/**](https://collect.myswarm.app/) **Tip:** If you are claiming rewards from multiple masternodes on xDai, combine them into a single wallet while on xDai so you only have to pay Gas fees to bridge back to Ethereum Mainnet one time. # VerifiedExistence ![](/files/-M9sdwm5Wl21z8hvzUFk) ## Intro This [smart contract](https://github.com/swarmfund/swarm-open-tools/tree/master/VerifiedExistence) is meant to: **Create proofs of the existence of a Hash (representing some document or text), thus verify their existence** * Owner (and whitelisted others) can create new `proofs`, like verified time-based document watermarks on the blockchain * Contract creates `proofs` as NFT/ERC721, which can be sent to a recipient address * Whitelisted others can add confirmations for `proofs` * **Roles:** * `default_admin`: contract deployer set as default, can be transferred; is allowed to grant/revoke all roles (admins + whitelists) * `proof_whitelisted`: add/delete proofs; admins are not automatically whitelisted, so that needs to be added if desired * `confirm_whitelisted`: add/delete confirmations of proofs * **Note:** Recipient wallets need to be able to handle ER721. For safety reasons, it is not possible to send a token to a contract that does not explicitly support it. ## tl/dr instructions * Tools: * Deploy contract via [Remix](https://remix.ethereum.org/) * Use contract interaction via [Etherscan](https://etherscan.io) * Create doc/string hashes using [Hash Calculator](https://www.pelock.com/products/hash-calculator) * `proofs` * whitelist deployment address plus any group of addresses with `grantRole()` as `Proof_Whitelisted` using `0xf555e1ec80c58c7664dc73d872d3ef6e07bdd9c5ba6b3bf7a91ffaa413b8dac5` * create new proof with `addProof()` using `proofHash` (hash of a document, file, string, etc.), `string` (any description of the hash) and the `address` where the `proofHash` shall be sent to * (If you hold the `proof` in your address) you can delete it by using `deleteProof()` * `confirmation of proofs` * whitelist any group of addresses with `grantRole()` as `Confirm_Whitelisted` with `0x53eebd7fe83ace838d6b0a9d4f111237deb02359c62b25f1025613d537b2379b` * create new `confirmation of a proof` with `addConfirmation()` using `tokenId` * Review `proof` data * Query either using `getProofData()` and/or `getProofIdByHash() to get`proofHash, timestamp, description\` ## Notable Functions **Read Functions** | Function | Description | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `getProofIdByHash()` | query with `proofHash` and get `tokenId` | | `getProofData()` | query with `tokenId` and get `proofHash, timestamp, description` | | `getProofConfirmationCount()` | query with `tokenId` and get `confirmation count` | | `getProofIdByHash()` | query with `proofHash` and get `tokenId` | | `isConfirmedBy()` | check whether a specific `address` confirmed a `proof` / `tokenId` | | `balanceOf()` | number of tokens the `address` owns | | `ownerOf()` | get the `address` who owns a `tokenId` | | `safeTransferFrom()` | transfer Proofs `address from`, `address to`, `tokenId` | | `tokenOfOwnerByIndex()` | `address owner`, `index (uint256)` // index is a 1..n numbering of proofs owned by the address. Use this to get all `proofs` owned by an address, in combination with `balanceOf` to get the count | | `totalSupply()` | get the current supply of `proofs` in existence; burnt/deleted not included | **Write Functions** | Function | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `addProof()` | write `proofHash (0x{hash})` (hash of a document, file, string, etc.), `string` (any description of the hash; length only affects gas), `address` (where the NFT/ERC721 is being sent to); contract returns `tokenId`; Fails if hash already exists; Requires being whitelisted; creates an ERC721 and a custom event | | `deleteProof()` | write `tokenId`, deletes proof/token; only the address holding a proof token can burn it, not any `default_admin` or `proof_whitelisted` | | `addConfirmation()` | write `tokenId` add confirmation of the data; requires being whitelisted; creates an event | | `transferFrom()` | `address from`, `address to`, `tokenId` // do not use, unsafe | | `approve()` | `address to`, `tokenId`) // give “address to" the right to transfer ownership of a proof the contract owns | | `setApprovalForAll()` | `address operator`, `bool _approved` // gives "address to" the right to transfer ownership of all proofs the sender owns | | `grantRole()` | `hash of role`, `addresses ["0x...", "0x..."]` to grant certain role to certain address; hashes of the roles are const in the contract: `Default_Admin_Role` with`0x0000000000000000000000000000000000000000000000000000000000000000`, `Proof_Whitelisted` with `0xf555e1ec80c58c7664dc73d872d3ef6e07bdd9c5ba6b3bf7a91ffaa413b8dac5`, `Confirm_Whitelisted` with `0x53eebd7fe83ace838d6b0a9d4f111237deb02359c62b25f1025613d537b2379b` | | `batchGrantRole()` | `hash of role`, `addresses [0x..., 0x...]` to grant certain role to multiple addresses | | `revokeRole()` | same as `grantRole` only reverse | ## Swarm - Example Use Cases ### Core initial use case The Swarm Council can publish protocols of decisions taken on GitHub and verify the Hash via VerifiedExistence: * [Dedicated contract](https://etherscan.io/address/0xdc95ed11e88d44f4e6ece3c959034646e7917b15#code) for `VerifiedExistence` for Swarm Network * Contract owner and `proof_whitelisted` is multisig with council members (tbd) * Council published documents with hashes; * Create Proof (Hash + meta data) and proof NFT / ERC721 is sent to dedicated wallet (e.g. Gnosis Safe, which allows ERC721 to be kept as “Collectibles”) * Example: Swarm Council Votes (SCVs) * listed in this [repo](https://github.com/swarmfund/swarm-network-governance/tree/master/SCVs); text between \ and \ tags is hashed * create `proofs` using hash and title; send it to a Swarm Council wallet; e.g [`proof (SCV_1587031154_Decision regarding_April_Voting_Period.md)`](https://etherscan.io/tx/0xf9363a3dc08a1927cdbe5e90c83c96bfd80012296bdad6821193a15a4f08460e) ### Other potential use cases: **Proof of Masternode** * Smart contract, which tracks verified Masternodes, could be added to `proof_whitelisted` of a contract put in place by council * A smart contract / person / process could keep track of active masternodes and create/delete corresponding `proofs` and send `proof` NFTs to masternode wallets * Masternode distributions could be using NFTs held as basis for reward distribution * Masternodes could be confirming various actions of the Council contract **Masternodes could be added as confirm\_whitelisted** * Can then add supporting votes (confirmations) to certain actions # Market Access Protocol A New Industry Standard for Trading Security Tokens​ ## Introducting MAP SWARM has developed a regulatory compliant framework that facilitates the digitization of assets and investment opportunities. In order to automate, manage, and simplify the transactions and agreements between parties, Market Access Protocol is built to function as a compliance layer which allows for the transfer of digital value and shared ownership of assets to be more easily realized. SWARM invites the security token community to collaborate, grow the market, and establish the ecosystem by leveraging our open protocol. ![](/files/-MG4U9gAOHLIzVtrITdX) ## Principals In order to develop a thriving, sustainable ecosystem supporting security token usage, distribution, and transferability, SWARM has identified and incorporated the following core principles: #### **Built-In Compliance: Play by the Rules** MAP ensures that all requisite parameters are met before a security token transaction can be processed, thereby providing regulatory compliance and proof thereof. These considerations may include token restrictions and requirements, geographically based jurisdictions, KYC/AML qualifications, accredited investor laws, etc. The successful completion of a transaction implies its validity due to the previously required compliance checks, making it easy for token issuers to report compliance and show audit trail. #### **Privacy: Own your personal data** MAP can instantly surface whether or not an individual’s wallet is compliant with the requirements for any security token transfer. MAP does not connect any personally identifying details to any wallet. Investor identity is secure - and individuals have control over who can access their data. #### **Incentives: Get rewarded to participate** Qualification providers and all operators within the ecosystem have significant incentives to actively engage. Incentives ensure long-term viability of MAP. #### **Ease of Use: Anyone can join** All parties can easily integrate with the framework and satisfy their interests. Market access qualifications are available to the right parties at the right time, anywhere they wish to transact. MAP is openable to any other token infrastructure to be used as a rule set for transfers performed on other blockchains. MAP is entirely blockchain agnostic, and can support transfer restrictions and compliance across DLTs. ## Get started: # FAQ ## What is Swarm Network? Swarm is a non-profit foundation dedicated to building an open infrastructure for the new, emerging digital securities economy. Our efforts are focused around building tools to support the digitization of assets or other things of value, to ensure compliance mechanisms are established, and to make the interfaces and infrastructure for doing so accessible and open to all. We also aim to reduce friction and lower barriers with regard to access to financial opportunities in a global perspective. We approach this from both a technology perspective as well as taking an active interest in helping to drive standards to establish a reliable framework for the industry to grow. ## What problem is Swarm Network solving? Swarm solves the problem of the lack of liquidity present in traditional asset ownership, allowing for fractional ownership opportunities of any asset. Tokenization creates opportunities for asset owners to realize capital from new sources, and for individuals and institutions to invest in, own and govern previously unattainable assets. Additionally, Swarm is addressing the compliance element through its MAP solution, which is vital to industry development across jurisdictions to realize broader, easier participation alongside improved liquidity. ## What solutions does Swarm Network provide? Swarm is producing a suite of tools and infrastructure components to help create a thriving digital securities ecosystem. Our efforts fall into 3 primary pillars: Tokenization, Compliance, and Governance. Inside each of these areas, we’ve developed and continue to iterate on tools that allow individuals, businesses, and the blockchain industry to both participate in and build upon. Swarm’s open-source toolkit is technology agnostic and supports: * creation and issuance of tokens as digital assets * token compliance with securities regulation in any jurisdiction * token sales for cryptocurrency and fiat * token transfer rules and restrictions * inheritable investor qualification * tools for token management and governance ## Does Swarm Network provide legal or marketing services? No, but we do partner with credible legal advisors and marketing agencies to meet the needs of token issuers using our technology. ## Does Swarm Network have a token? Yes, SWM is the Swarm utility token. 1. SWM is used to establish stake-weighted voting rights on issues regarding the activities and regulations of the Swarm Foundation, a non-profit organization which administers the SWM token. 2. SWM is staked by token issuers against SRC20 token Digital Security Offerings issued through the Swarm infrastructure. The stake amount is determined as a % of the funds raised or of the asset value. 3. SWM is staked by Masternode operators who wish to build and support Swarm’s decentralized infrastructure. . 4. SWM is used to pay rewards to token issuers and masternode operators who are staking the token. ## Which blockchain is Swarm Network built on? For the duration of 2018, the Swarm blockchain was built on a custom fork of Stellar. Swarm has since extended the Swarm Protocol into other chains, starting with Ethereum. The infrastructure has now become blockchain agnostic. This means Swarm will support issuance on any blockchain that supports multi-signature transactions. ## What stage is your product in? Alpha, beta, in development? Swarm's invest beta platform was launched in January 2018 and can be found here: . In 2019, Swarm released open infrastructure that provides a complete set of tools to support token issuers, found at [https://swarm.app](https://invest.swarm.fund). This includes Tokenization, Fundraising, Compliance and Governance APIs which will be free to use. Initially they will support ERC20 and Swarm SRC20 issuances. In 2020, The Swarm Network ecosystem continues to be very active with developers working on the suite of open source smart contracts. Soon there will be new a release with more features. ## How long has Swarm Network been around? The current iteration of Swarm was started in 2017. It is independent and disconnected from earlier iterations, the very first of which was referred to as a “crypto equity” platform in 2014. ## Are there any fees charged by Swarm Network? There are no issuance, listing, management or any ongoing fees charged by Swarm. The only requirement is that after successfully raising funds, you stake an amount of SWM tokens - in the range of 0.3-1.0% of assets under administration raised. These are staked for duration of the security tokens existing. When these are burned, redeemed or otherwise returned, the stake is fully returned to the issuer. By eliminating upfront fees, we are making it easier for you to focus your budgets on legal, marketing, and the other costs necessary to bring a security token to market. We’re also making it easier for service providers to offer value on top of Swarm’s open infrastructure. ## How much budget do I need to prepare to issue and run an STO on your platform? Using our infrastructure is free. The only requirement is that you would be required to stake an amount of SWM tokens which is a proportion of the funds you raise. This stake is only required after fundraising and triggers the release of funds to you and the release of tokens to investors. The stake itself is locked for the life of the investment opportunity. Separately to this, you would need to account for a budget to handle legal, marketing and other costs. However, our infrastructure is free to use. ## What is Market Access Protocol (MAP)? Swarm has developed a regulatory compliant framework that facilitates the digitization of assets and investment opportunities. In order to automate, manage, and simplify the transactions and agreements between parties, Market Access Protocol is built to function as a compliance layer which allows for the transfer of digital value and shared ownership of assets to be more easily realized. ## How does MAP ensure an investor is qualified at a moment of purchasing security tokens? Market Access protocol (MAP) is Swarm’s investor compliance ecosystem, built and maintained by a decentralized network of nodes. It is a protocol that defines how applications (blockchain or non-blockchain) interact with people in a regulatory compliant manner, and results in a distributed ledger that stores investor qualification data, respecting user privacy. Compliance requirements are referenced in the token contract as well as the KYA (Know Your Asset) details, and are checked by MAP for every transfer of tokens. MAP is also aware of wallet certifications and only wallets that meet these requirements are able to participate in a token sale or buy tokens in secondary markets. ## What exactly is the SRC20 standard? SRC-20 is a standard that extends Ethereum’s ERC20 fundamental token standard to support regulatory compliant transfers. Tokens that support the SRC-20 standard can represent fractional ownership in assets and are often termed security tokens or digital securities. The SRC-20 standard allows token issuers to define the rules and restrictions that must be satisfied in order to facilitate a regulatory compliant transaction. Rules include checking for investor compliance (specific to applicable jurisdictions), ensuring cap table and holding limits are enforced, provisions for a right of first refusal, time-based restrictions, and any other programmable rule that can be processed by a smart contract. ## What are SRC20 security tokens? SRC20 security tokens: \ 1\. represent ownership of part of an object or “asset”, \ 2\. allow holders to manage that asset through voting, \ 3\. secure a right to any revenue streams from the asset, \ 4\. are tradable in a regulatory compliant manner. ## How is SRC20 different from ERC20? SRC20 token contracts extend ERC20 in that they have a few extra features: 1. Ability to have an owner (usually token issuer). 2. Ability for the owner to freeze transactions, mint more tokens or destroy tokens. 3. Require an authority to allow for token transfers after it checks for transfer restrictions. 4. Holds token fundamentals which is an IPFS document reference containing all token relevant data. ## How does Swarm Network work with regulators, governments, and jurisdictions to ensure KYC/AML and other restrictions are met? First and foremost, Swarm is not a principal and is a technology & tools provider to support the token issuers in their needs. It is the token issuer's responsibility to know and abide to regulations in the specific jurisdiction they want to operate. After understanding the regulatory requirements, the token issuer sets those requirements in the token contract. Using Swarm’s Market Access Protocol tool, token issuers are able to connect with any 3rd-party qualification service providers and make their investor pools available for KYC/AML and other verifications. Swarm does work directly with different financial regulators in different jurisdictions to both build compliance with current legislation, and help influence the direction of upcoming amendments and new regulations. We are using this research in building the tools to enable token issuers to configure their compliance needs using our tokenization infrastructure, and then enforce it using our compliance tools. ## Does Swarm Network have any partnerships with legal service providers? We have several counselors and other legal partners in different jurisdictions. We have partnerships with various STO consultants that can provide legal services in specific jurisdictions. ## How do I run a Masternode? Please check out our [Swarm Masternodes](https://www.swarmmasternodes.com/) page and also review our masternode [FAQs](https://www.swarmmasternodes.com/faq).