|
| 1 | + |
| 2 | +# White_Label_Wallet |
| 3 | + |
| 4 | +## About |
| 5 | +The White-Label-Wallet is a general-purpose crowdfunding blueprint. The blueprint allows users to pool their resources together into a treasury. Non-fungible badges are utilized to keep track of pertinent user information such as username, contact and pro-rata share of the treasury assets. |
| 6 | + |
| 7 | +The objective of this project was to create a simple wallet for several purposes that allow ownership of vaults to be represented by NFTs but also be capable of fractionalizing ownership of NFTs, real estate, physical property, and traditional tokens. Bash scripts are used to automate resim commands and RTMs. |
| 8 | + |
| 9 | +#### How to Run |
| 10 | +While in the 'shares' directory, run the command: `bash ./manis/global.sh` |
| 11 | +This is the generic bash script that cycles through all methods for testing everything. The following shows three customized scenarios with a bash script for each that accomplishes the objectives of each scenario. |
| 12 | + |
| 13 | +## Core Concepts |
| 14 | + |
| 15 | + |
| 16 | + |
| 17 | +On a high level, there are three main parts: |
| 18 | + |
| 19 | +**1. Shareholders (Users)** |
| 20 | + |
| 21 | +**2. Treasury (Blueprint/Component)** |
| 22 | + |
| 23 | +**3. Pooling, Distributing and Claiming Funds.** |
| 24 | + |
| 25 | + |
| 26 | +### Shareholders |
| 27 | + |
| 28 | + |
| 29 | + |
| 30 | +The shareholders are the parties that have a claim on the treasury's assets. Each shareholder receives a non-fungible owner_badge that gives them the authority to use the component's methods. In addition, a shareholder's owner_badge will contain non_fungible_data such as their username, contact, and percent_ownership_of_treasury. |
| 31 | + |
| 32 | +### Treasury |
| 33 | + |
| 34 | + |
| 35 | + |
| 36 | +The treasury is the shared wallet that allows users to crowdsource funds. The component is made up of a series of shared vaults, each representing a token and their corresponding resource_addresses. In order to keep track of the shareholders (users), an owner_record vector is used within the treasury to record each owner corresponding to their unique non_fungible_id. In addition, in order to keep track of everyone's pro-rata share, the funds_owed vector is used. |
| 37 | + |
| 38 | +### Pooling, Distributing and Claiming Funds |
| 39 | +The main function of the White-Label-Wallet is to crowdsource funds from shareholders in order to purchase assets and share in the potential future cashflows. Three primary methods are used to facilitate this process. |
| 40 | + |
| 41 | +**1. Pool_Escrow_Funds:** Shareholder's pledge and deposit their assets to the treasury. |
| 42 | + |
| 43 | + |
| 44 | + |
| 45 | +**2. Distribute_Treasury_Funds:** The treasury logs shareholder data into the funds_owed vector. |
| 46 | + |
| 47 | + |
| 48 | + |
| 49 | +**3. Claim_Treasury_Funds:** Shareholders withdraw their share of the treasury's assets. |
| 50 | + |
| 51 | + |
| 52 | + |
| 53 | + |
| 54 | +## Method Definitions |
| 55 | +**pool_escrow_funds:** Collects and deposits the funds from all users based on their percent_ownership_of_treasury (Outlined in the owner_badge non_fungible_data) into the treasury. |
| 56 | + |
| 57 | +**distribute_treasury_funds:** Allocates the pro-rata claims on treasury funds into the funds_owed vector. |
| 58 | + |
| 59 | +**claim_treasury_funds:** Withdraws the pro-rata share of treasury funds into the owner's account. |
| 60 | + |
| 61 | +**update_owner_user_name:** Updates the owner's username within the owner_badge's non_fungible_data. |
| 62 | + |
| 63 | +**update_owner_contact:** Updates the owner's contact information within the owner_badge's non_fungible_data. |
| 64 | + |
| 65 | +**merge_ownership:** Takes an owner_badge and merges its percent_ownership_of_treasury with that of a second owner_badge (burning the first in the process). |
| 66 | + |
| 67 | +**split_ownership:** Takes an owner_badge and splits its percent_ownership_of_treasury with a newly minted owner_badge. |
| 68 | + |
| 69 | +**deposit_to_treasury:** Allows any user with an owner_badge or depositor_badge to send resources to the treasury. |
| 70 | + |
| 71 | +**new_depositor:** Mints a new depositor_badge and returns it to the caller. |
| 72 | + |
| 73 | +**check_or_create_vault:** Queries the component_treasury HashMap for an existing vault, if not creates a new vault with the supplied resource_address. |
| 74 | + |
| 75 | +**show_single_treasury_balance:** Displays the current vault balance for a supplied resource_address. |
| 76 | + |
| 77 | +**show_all_treasury_balances:** Displays all current vault balances in the treasury. |
| 78 | + |
| 79 | + |
| 80 | +## Use Cases |
| 81 | + |
| 82 | +**General Case:** A person wants to fractionalize ownership of an existing NFT, a basket of tokens, property, or a mixture of assets. Logic is provided to distribute income from these assets proportionally to each owner. |
| 83 | + |
| 84 | +### Scenario 1 |
| 85 | +**Real Estate Finance:** A commercial building owner wants to raise funds but doesn't want to mortgage his property. Instead, the developer decides to mint an owner's NFTs and transfer ownership of his property to this NFT address. The owner can now split as much or little of his NFT into a second owner NFT to sell to leverage remodeling, updates, repairs, etc. It is also possible for him to repurchase his shares later if both owners agree on a price. It is also possible for this owner to mint multiple NFTs representing ownership of each unit of the property and sell stake on a per unit basis. |
| 86 | + |
| 87 | +#### How to Run |
| 88 | +While in the 'shares' directory, run the command: `bash ./manis/Scenario1/global1.sh` |
| 89 | +This will automate the Shares dApp by publishing the Shares package, instantiating the Shares component with one initial shareholder, and receiving the owner NFT with 100% ownership metadata. Next, the owner would deed the property to the NFT address of the owner NFT, run the split_ownership method with .05 input representing splitting this owner NFT into two representing 95% ownership on the NFT they would retain and 5% ownership to sell to raise funds. |
| 90 | + |
| 91 | +### Scenario 2 **** UNDER DEVELOPMENT **** |
| 92 | +**NFT Crowdfund:** Three people pool a predetermined amount of XRD, each paying equal amounts to purchase a halo cig abandoned scorpion NFT. The NFT costs 1,500 XRD, and each person will be responsible for 500 XRD. A transaction is composed via RTM to accept the required buckets from each person contributing to the pool. Each new fractional owner of the NFT can buy or sell shares of ownership of this 1 NFT to as many decimal places as Scrypto Decimal can handle. |
| 93 | + |
| 94 | +#### How to Run |
| 95 | +While in the 'shares' directory, run the command: `bash ./manis/Scenario2/global2.sh` |
| 96 | +This will automate the Shares dApp by publishing the Shares package, instantiating the Shares component with three initial shareholders, and receiving the owner NFTs each with 33.3% ownership. The person setting up the Shares component would pass two owners' NFTs to the other two initial investors and then call the pool escrow funds method. These steps will allow the RTM to compose a transaction where all three owners can contribute their 500 XRD each to the component in a trustless way to purchase the scorpion NFT. |
| 97 | + |
| 98 | +### Scenario 3 |
| 99 | +**Developer Collaboration:** Three developers want to form a group and create a shared wallet that can accept payments from clients, pool earnings, and distribute funds when needed, similar to a multi-sig wallet. A developer can instantiate a Shares component with three initial shareholders and pass the other team members one owner NFT each. The default ownership is equal for each owner, but they can split/sell or buy/merge NFTs to increase or decrease their right to the revenues. Finally, the team mints a depositor badge for the project's client that can be used to pay developers directly via the component_treasury. |
| 100 | + |
| 101 | +#### How to Run |
| 102 | +While in the 'shares' directory, run the command: `bash ./manis/Scenario3/global3.sh` |
| 103 | +This will automate the Shares dApp by publishing the Shares package, instantiating the Shares component with three initial shareholders, and receiving the owner NFTs each with 33.3% ownership. The person setting up the Shares component would pass two owners' NFTs to the other two developers. Next, a depositor badge is minted for clients, allowing them to deposit within the shared component vault. Finally, the claim_treasury_funds method can be called via RTM after payments are made from the client to split proceeds between owners of the Shares component owner NFTs according to ownership metadata held within the owner NFT. These steps will allow the RTM to compose a transaction where all three developers have a pro-rata share of revenues that come into the treasury via clients. |
| 104 | + |
| 105 | + |
| 106 | +## Contributors |
| 107 | + |
| 108 | +https://github.com/aus87 |
| 109 | + |
| 110 | +https://github.com/errollgnargnar |
| 111 | + |
| 112 | +https://github.com/krowtaergeht |
0 commit comments