Comment on page
TIMT (Trustable Investment Management Toolkit) built with TARS Protocol, including TARS Space, Smart SAFT, Claimer, Portfolio Board, etc., will help users to effortlessly engage in Web3 token economies and efficiently manage their portfolios in a trusted environment.
PoI (Proof-of-influence) is the mechanism that allows users with verified identities to prove their social relationships and endorse their influence in a decentralized manner. Proof-of-influence was first proposed by TARS Protocol and adopted in Web3’s Soul Profile (WSP), which powers various Social-Fi scenarios.
WSP (Web3’s Soul Profile) will act as verifiable and programmable identities aggregating trustable data for the residents in Decentralized Society (DeSoc). WSP works as your holistic resume, digital passport and unified identity and offers Open APIs for all Web3 applications to access the profile data in real time with your authorization, enabling monetization for both individuals and organizations in Web3 economic model.
SoulScan is an open data aggregation platform providing data query and index services with scalable dimensions for Web3.
DeSoc (Decentralized Society). On the 10th of May,2022, a paper titled “Decentralized Society: Finding Web 3’s Soul”, was co-authored and published by Glen Weyl, a researcher at Microsoft, Puja Ahluwalia Ohlhaver, a strategist at Flashbots, and Vitalik Buterin, the co-creator of Ethereum. This paper points out that Web3 today centers around expressing transferable, financialized assets, rather than encoding social relationships of trust. Yet many core economic activities—such as uncollateralized lending and building personal brands—are built on persistent, non-transferable relationships.
SBT (Soulbound Tokens), proposed by Vitalik Buterin, would form an essential building block for this Decentralized Society, or DeSoc. These non-transferable tokens represent credentials and affiliations within DeSoc, and are linked to Souls, a type of address that establishes provenance.
At TARS, Space is a Web3 DAO Hub created for managing all Smart SAFTs, portfolios, token vesting, and creating IDO/Private Sale deals shared with the community, etc. Anyone can create a Space at TARS to launch dApps such as Smart SAFT, Claimer, and other dApps.
All the data and information of TARS Space are stored on the chain in a decentralized way, which is the basis of the Credit Data Network.
At TARS, Verified Space means the Space and its owner have been verified by the TARS operating team. The benefits and privileges of Verified Spaces are as follows:
- Receive a green Verified badge next to their Space Name.
- Gain a dedicated, unique, and short URL created according to Space Name.
- Edit the Space Profile including Space Name, logo, description, website, Twitter, Discord, Telegram, etc.
- Be included on the Space List page and able to be searched by the public.
- SAFTs created will be listed on the Explore page and able to be filtered and searched by the public.
Space Owner is the user who creates Space at TARS and has the rights to launch Smart SAFT, Claimer, and other dApps. Space Owners can request verification to the Space at TARS and will be able to edit the Space Profile on the chain once the Space is verified. In the Smart SAFT/Claimer dApp, the Space Owner is usually considered as the proposer. One wallet address on each chain is only allowed to create one Space.
All Space Profile information is stored on the chain, including Space Name, logo, description, website, Twitter, Discord, Telegram, etc., which is the foundation of the TARS SocialFi ecosystem. Only Space Owners who have completed the verification can edit the Space Profiles at any time and an unlimited number of times.
TARS Dashboard is an easy-to-use yet powerful Web3 operating desk for crypto users to make full use of the plug-and-play modules without coding. TARS Dashboard is the entry for end users to manage Spaces, Smart SAFTs, Claimer dApp, NFT, etc.
At TARS, everyone can effortlessly draft an on-chain proposal for the deal including all key terms with the counterparty (token buyer/seller), which is called Smart SAFT.
As we know, projects secure funds in the early stages through mutually signed legal documents called Simple Agreement for Future Tokens (SAFT). Compared with traditional SAFT legal documents, Smart SAFT provides effective constraints and security by smart contracts, and protection for the crypto users' investment in the primary market on Web3.
There’re Whitelist/Public/Hidden Types for options in each Smart SAFT. At TARS, Smart SAFT is referred to as SAFT for convenience.
SAFT deal page will be created once the Space Owner has successfully launched Smart SAFT, which will display all key terms and details of the deal, including project info, token info, and fundraising details.
All counterparties (token buyer/seller, and proposer) will participate in the deal on the SAFT deal page.
When the Space Owner launches the Smart SAFT and chooses “White Type”, the Whitelist Type SAFT will be created. In this mode, only specific addresses will be able to participate in the fundraising on the SAFT deal page after they get whitelisted by the Space Owner, no matter if it's just one specific investor or multiple investors.
Whitelist Type SAFT is suitable in the following scenarios:
- Only one investor. For example, the individual investor or Venture Capital (VC) who wants to participate in the investment of a project should prepare two wallet accounts, one for the Space Owner to launch the Smart SAFT and the other for the investment.
- More than one investor. For example, multiple individual investors participate in the investment of a project, and the Smart SAFT is launched by the investors’ representative as the Space Owner.
When the Space Owner launches the Smart SAFT and chooses “Public Type”, the Public Type SAFT will be created. In this mode, everyone will be able to participate in the fundraising of a first-come-first-served (FCFS) pool on the SAFT deal page.
When the Space Owner launches the Smart SAFT and chooses “Hidden” under the Whitelist Type. In this mode, all features are the same as the Whitelist Type, but the SAFT deal page will be hidden from the public and the Explore page. Only relevant counterparts (whitelisted buyers, Token Provider and Space Owner) have access to the SAFT deal page.
Space Owners are allowed to set the Commission Rate in the deal of the Smart SAFT calculated according to the following formula:
The z refers to the commission that the proposer/Space Owner will be able to claim after Token Provider (usually refers to the project party) transferred the token.
The x refers to the commission rate. Typing 0 in the SAFT creation form means the proposer/Space Owner doesn't have any commission in this deal.
The y refers to the total final fundraising amount. The proposer/Space Owner can only claim the commission when someone participates in the deal.
Token Provider (usually refers to the project party) will be able to claim the balance of the total final fundraising amount after deducting the commission of the Space Owner.
Token Vesting Schedule is a textual description of the project token unlocking rules which is a required field in the Smart SAFT, but the smart contract will not lock the tokens as described in the text.
Token Vesting Schedule will be displayed on the SAFT deal page and automatically covered by the finalized “Claim Rules” that the Space Owner entered on the SAFT deal page, which will be followed by the smart contract.
The Space Owner has to enter the finalized “Claim Rules” before the Token Provider (usually refers to the project party) transfers tokens, which will cover the Token Vesting Schedule on the SAFT deal page. The smart contract will lock the tokens according to the Claim Rules.
Claimer is a dApp powered by Dynamic Penalty Function (DPF) and allows project teams/ token purchasers to lock tokens in a non-custodial, time-released smart contract vault, and whitelisted users will be able to claim their specified tokens according to Token Vesting Schedules.
As a once-and-for-all Token Vesting Schedule with few clicks, Claimer will allow all investors to claim specified tokens fairly/timely with no more complaints.
At TARS, the proposer/Space Owner who launches Claimer dApp usually refers to the project party or the investors’ representative (KOL/Influencer, etc.), is allowed to adjust the Token Vesting Schedule and fined accordingly due to DPF however.
Dynamic Penalty Function (DPF) is designed by TARS and followed by Claimer to limit adjusting token vesting during the period, which is calculated according to the following formula:
The symbol Σ (sigma) is used to denote a sum of multiple terms.
The Ceil() method rounds a number UPWARDS to the nearest integer and returns the result.
The Abs() function returns the absolute value of a number.
The z refers to the total amount of penalty that the proposer will pay if all adjustments to the token claim rules are completed by the Claimer smart contract.
The k refers to the specific fines per hour.
The x refers to the adjusted claim time of the specific batch.
The y refers to the initial claim time of the specific batch.
The unit to Abs(x-y) should be an hour/hours.
TARS NFT Receipt is the world's first Non-Fungible Tokenized Receipt on Web3, as the proof of purchase when the token buyers/investors buy tokens through Smart SAFT, records their deal information and will be swapped into Non-TradableToken (NTT) to power the Credit Data Network in DeSoc. NFT Receipt can be minted to unlock multiple benefits including token presale whitelist, airdrops, NFT exclusive farming, lottery for free of charge, swap into Non-TradableToken (NTT), etc.
At TARS, Token Provider usually refers to the project party or the token seller.
In the Smart SAFT, once Token Provider successfully transfers the corresponding project tokens to the Smart SAFT Contract, it will be able to claim the balance of the total final fundraising amount after deducting the commission of the Space Owner.
In the Claimer, Token Provider usually becomes the proposer who launches the dApp and sets the whitelisted users who are allowed to claim tokens according to the Token Vesting Schedule. In order to avoid confusion, we no longer use the “Token Provider” to refer to the proposer, but directly use Space Owner in the Claimer case.
An end user (sometimes end-user) is a person who ultimately uses or is intended to ultimately use a product.
In different features of TARS, there will be different types of end users. In Smart SAFT, there’re Space Owners (proposer), Token Providers (token seller) and investors (token buyers). In Claimer dApp, there’re Space Owners (proposer), and whitelisted users.
In Smart SAFT, Space Owners/Token Providers are not allowed to invest in the projects on the SAFT deal page created by themselves.