Allocating tokens to a SAFT or Private Sale
On your venture dashboard, click the drop-down next to “New Allocation”, and pick whether you would like to sell an ERC20 or NFT (ERC721(a)) token.
The following example takes you through the flow of creating a SAFT or Private Token Sale with ERC20 tokens. There are some DAOs that use NFTs for governance, however an ERC20 is more dynamic and feature rich, so its a great place to start if you don’t know what your tokenomics and governance structure will really look like.
The name of your venture is displayed at the top of the page, if you are involved with multiple ventures, and are not using separate wallets for each venture (recommended from a security and separation of concerns perspective), please make sure you are allocating tokens for the correct venture.
Access Control
In the course of running a business, it may be useful to delegate certain tasks to other wallets. In the simplest case starting out, you may already have approved a certain allocation of tokens for investors or community sales. This allocation can be delegated to another wallet to sell, and therefore giving that wallet rights to manage allocators allows you to lower the administrative cost of having to approve all transactions from the venture multisig.
For pre-token ventures, this is as simple as granting rights, and for ventures with a token, it would involve minting the budgeted tokens to the wallet and making them an allocator manager. This means that neither the allocator smart contract nor the allocator manager require minting rights on your token.
Step 1: Allocator Details
Let’s complete the basic details of your token sale:
Token Address
The most important field to fill in or leave blank!
To create a SAFT, leave this blank, and once the sale is closed you will be able to set a token.
To create a private token sale, supply the address of the token you are selling. In this case, you will need the budgeted token amount in the wallet you are using to create the sale, as it will be transferred to the allocator smart contract upon creation.
Token Price
The fixed price at which you are selling your (future) token for this round.
We currently only support $USDC as a purchase token. Please contact us if you have alternate requirements.
Tokens for Allocation
The number of tokens up for sale in this round.
If you have minted your token and is selling it, you will need this amount in the wallet you are using to create the sale, as it will be transferred to the allocator smart contract upon creation.
Sale Goal
Simply a function of the number of tokens for sale, multiplied by the price per token. This amount represents the total proceeds of the sale if all tokens are sold, and is displayed for convenience.
Hurdle Amount
This is the floor for the round. The minimum number of tokens that need to be sold for the sale to be successful. Until this amount has been sold, the proceeds of the sale will be held in escrow in the sale contract, and if the contract is closed, participants will be able to claim back the purchase tokens spent.
After the hurdle is reached, proceeds of new purchases will go directly to the venture wallet, and escrow can be claimed.
Allocator Name
The name to identify this sale to participants, and will also be displayed in your venture dashboard.
Allocator Description
A short description of the round or the venture
Terms URL
The contract terms that you and sale participants will sign as part of the sale. In the off-chain world this would be the actual SAFT/SAFE, or if you have a token already, a Purchase or Subscription Agreement.
Jubi has partnered with https://www.cadenalegal.com.au/ to supply a best in class SAFT and Token Purchase Agreements (TPA) that works with our smart contracts out of the box.
To use our SAFT template, use https://mirror.xyz/makeitjubi.eth/6aqJudFC2-XM_2doLW_4mUZsJbZOxXTAWa8bREM0Ak8
To use our TPA template, use https://mirror.xyz/makeitjubi.eth/K7bIZE5Rl_r_fIgoeW-wm4zksGp9XiRPqp8Vx718Utk
If you are bringing your own contract, you can enter the URL here. We recommend minting the terms on https://mirror.xyz/ where you will get 2 links, one for a nicely formatted one that you can pass to the sale participants, and one that’s just the text that was minted to Arweave. If you include the same mustache variables in your SAFT, it can be easily rendered to display the parameters of the sale smart contract that you are busy configuring, as well as the digital signatures.
NOTE:
We highly recommend minting on Arweave as it is currently the only easily accessible immutable storage chain, and increases confidence in the contract terms.
Terms Hash
Supplying a cryptographic hash of the contract terms allows participants to ensure that the terms have not been altered. This is a key part of ensuring the validity of the digital signature process. If you minted on https://mirror.xyz/ , you can use the characters after the arweave.net/ url as this uniquely identifies the terms on an immutable blockchain storage solution. You can also find this URL at the bottom of your mirror document under “Arweave Transaction”.
If you are using our SAFT template, use bxHYQqS0XaeLTCqQ0ZLB30CYw8WskoSDH4olx6gR6kw
If you are using our TPA template, use TmwTO6-uVn1VDI74t-E7NobRdBivFlW00p8uS9AppOs
Automating the hash is on our roadmap.
Whitepapers and other additional information
To give sale participants further context and important information around your project, token, as well as this sale, we will be displaying the URL for your venture on the sale page.
Please make sure to have sufficient information accessible at this link to support the professional image of your project.
Step 2: Scheduling
This section allows you to configure lockup and release schedule details for tokens purchased through this sale.
Release schedules are currently linear, starting from the end of any specified lockup period.
If you do not wish to have any token lockups and have tokens be immediately available to claim after the sale is closed, leave this toggle off, else, switch it on to have a release schedule enforced.
Why have a release schedule?
Distribution/Release/Vesting schedules are a common tool to align long term incentives. The longer a token holder is unable to sell their tokens, the greater their incentive to support long term growth in your token price. If token holders are able to sell tokens prior to or upon your TGE and public listing of your token, this will likely create a lot off downward pressure on your token, and you risk a typical “pump and dump” price curve.
Alternatively, a linear release starting at least 2 years after your TGE spreads the sell pressure over time, and separates it from the critical project sentiment that is formed during your TGE or public listing.
Start Date
For a SAFT, the start date is intended to represent the intended TGE date, and if your token already exists, we recommend that you try to line up the start date, or at least the end of the lock duration, with the date you intend to list your token publicly.
If you are pre-token, we understand that the TGE may be a moving target, and you will be able to kick off the schedule when you set the token contract address. Given this may be earlier or later than the scheduled date, it is important that your sale terms [link to other section] account for this, and sale participants are aware that this is a goal date.
Please note that the smart contract will store this as seconds from Unix Epoch, however the Jubi interface will allow you to pick a date.
Lock Duration
The lock duration assumes the token has been minted and deposited into the smart contract, but is not available for claiming. The smart contract will store this as seconds, however the Jubi interface will allow you to set the duration in months.
Claim Duration
This is the number of months over which the purchased tokens will be released after the lock period ends. The release will be linear, and new tokens will be claimable every incremental block timestamp, so for Ethereum, this is every 12 seconds, as per block time.
Again, the smart contract will store the claim duration as seconds.
Invite Codes
Jubi sales are private by design. We use a merkle tree based invite code to limit access to the sales. When you allocate (future) tokens to a sale, you have to specify the number of invite codes to create, along with the number of tokens that each invite code can purchase.
You are able to create multiple sets of invite codes, and it is not required that all of the invite codes are used. However, you should make sure that there are sufficient invite codes to allow all the allocated tokens to be sold.
Each invite code grants the user the ability to purchase a number of tokens between the minimum and the maximum number for that invite code. This allotment can be exhausted across multiple purchases, as long as the first purchase meets the minimum purchase threshold.
Please be careful when sharing invite codes, as they can only be used by a single wallet. A single wallet can however, use multiple invite codes, with the maximum purchase amount being cumulative. The minimum purchase amount only applies to the first purchase.
One of the benefits of using invite codes is that you have a reasonable amount of certainty that the token purchase is being executed by the party that you shared the invite code with. Helping you to meet the KYC requirements that is present in many jurisdictions.
Another is that you can use them to shape your cap-table, whilst allowing participants to purchase more tokens as the sale progresses.
For example, if you wanted to have 5-10 participants lead the round and have at least 60% of the token allocation, you can create one set of 10 invite codes with a minimum purchase of 1/12th of the allocation. A second set of invites can have a smaller minimum and maximum. The minimums should cumulatively be able to cover the total token allocation, and the maximums can create some space for competition and rewarding early commitments.
As you may have guessed, a set of invite codes require that you specify the number of invites, the minimum, and the maximum purchase amounts.
You can add or remove invite code sets with the [- +] buttons.
Confirm
Once you’ve completed the details, you will be asked to give them a once over and make sure everything is correct before you mint the contracts.
You will also be asked to agree:
To the Jubi terms of use. Jubi provides a web app for you to interact with smart contracts that are owned and operated by you.
That the organisation’s leadership do not contain sanctioned persons
Lastly, that you are compliant with the laws of the jurisdiction that pertains to you and the company that you represent.
These terms apply to the use of our front-end, and help us be compliant within the jurisdiction that we operate in.
Create Allocation
Now that you are ready, hit the button, and the minting process will start.
There are 3 steps for SAFTs with an additional 4th step if you need to approve the movement of an existing token.
Creating Invite Codes
Nothing to do here but wait. A process will run to generate the specified invite codes and merkle tree nodes. How long this takes depends on how many invites you are generating.
Contract Signing
You will be asked to sign the terms that you have provided, along with the sale variables:
Signer: This is your connected wallet address. When generating a PDF of the signed contract using mustache, it will display as you signing on behalf of the venture (identified by the multisig specified when creating the venture contract).
TermsUrl: The URL to the Contract Terms
TermsHash: A cryptographic hash of the Contract Terms, to be used to validate that the signed terms are unchanged.
NumTokens: The number of tokens you are allocating to this sale. This number is in 18 decimal notation as that is the standard for ERC20 tokens. This means that if you specified an allocation of 1 million tokens, this number will be 1 000 000, followed by eighteen 0s.
TokenPrice: The number of $USDC a participant will have to pay for each of your tokens, with $USDC having 6 decimals, so a $USDC 1 token price will be denoted as a 1 followed by six 0s.
Hurdle: This is the Sale Hurdle, in the amount of sale tokens to reach the hurdle, again denoted in 18 decimals
ReleaseScheduleStartTimeStamp: is the Schedule Start Date in seconds from 1970-01-01 (Unix epoch format)
TokenLockDuration: The Token Lock duration in seconds
ReleaseDuration: The Release Duration in seconds
InviteCode: The merkle tree root. This is a cryptographic match to all invite codes generated, so you are countersigning for all possible invite code uses.
Paired with the signature of a participant on purchase, these two signatures along with the terms and variables captured in the smart contract constitutes a signed contract of terms between the buyer and the seller (your venture).
Transaction Approval
You will be asked to confirm the gas and transaction of minting the smart contract.
Transaction success and Download invite codes
Once the minting transaction is successful, you will be presented with a confirmation dialog providing the address of the sale contract, a block explorer link to it, as well as a link to the Jubi sale page.
If you did not get a dialog to save the invite codes, you also have the option to download them again.
NOTE on saving invite codes:
We only store a list of the merkle proofs that the invite codes can be verified with. We do not store a copy of the invite codes and cannot help recover them. If they are lost or compromised, you will have to close the allocator and create a new one.
CONGRATULATIONS!
You now have a smart contract that for selling your (future) token!
For more details on what sale participants will see, read our Private Token Sale documentation
Last updated