This evolving document describes and drives development of the initial version of Crowdtainer, so that any interested parties working on it have a central point to refer and make improvements to the system. Non-developers are also welcome to read this document to make decisions about how the system works and set expectations accordingly. Eventually development should be frozen (together with this document) before an initial version is released.
The main goal of these smart contracts is help people with similar interests to coordinate and form a bulk purchase. This helps reduce costs for the whole group due improved logistics, and might enable otherwise not viable projects to actually happen due improved social coordination. Buyers then have more diversity of products and services to choose from, at a potentially lower cost. At the supply side, projects that were formerly impossible due low economies of scale or tragedy of common goods problems, may now become a possibility. The main focus of this project is to empower the many small entrepreneurs or small communities that has been marginalized by monopolies.
If we imagine a very generic way to categorize project types based on quantity and cost per unit delivered, we envision Crowdtainer projects in its current version to be a good fit (or not), according to the following table:
| Unitary value | Sale quantity | Applicability |
|---|---|---|
| Low | Large | Yes |
| Low | Small | Yes |
| High | Small | No |
| High | Large | Maybe |
The idea is not far away, but there are some crucial differences:
- The lack of yet another company between the seller and buyer, since coordination happens via smart contract.
- Competitive/low fees: the theoretical minimum fee possible is the blockchain or rollup transaction fee.
- Allows for more flexible design and transparency of the incentive mechanims, for example: In Crowdtainer, the person that indicates a friend with a referral code is rewarded proportionally to the number of people using the given code. This doesn't happen with most crowdfunding platforms (if any).
- Here (at least to start) we envision usage to be accompained with an agreement for delivering the promised products if the funding is successful, making it a normal product sale in legal terms.
- Generic implementation, allowing a variety of applications ranging from bulk purchases to crowdfunding donations or aid missions.
- Permisionless: anyone can deploy and start their own project. The reputation and worthiness of each project however lays on the participant to analyse and judge, and it is upon the service provider to write their legal sale contracts, websites, and finally deliver on the promises. Competitive interfaces may then be built around the smart contracts, providing the full range of choices from the most permissionless all the way to a curated version where only audited service providers can join.
-
Intentionally, there is no curation or KYC mechanism at the smart contract level itself. Campaigns are generally in one of two modes: either it has a 'signer' set or not:
- If no signer is set, anyone can join, given it passes all smart contract enforced restrictions.
- If a 'signer' is set during deployment of a campaign, in addition to the smart contract checks, joining that campaign requires an off-chain approval generated by a private key that matches the set 'signer' public key. This allows one to develop any arbitrary off-chain mechanism to set rules for joining the given campaign. This is implemented following the EIP-3668 protocol. However, because there is no widespread client-side implementation of EIP-3668 for writting data to the blockchain, the generation of this payload happens in the Crowdtainer web application itself, between the backend (generating the 'approval' signature) and the frontend - which eventually sends the payload to the blockchain, which in turn performs signature verification on the authorization.
-
We hope people will build systems on top of this basic layer, to curate high quality projects and help avoid scams while keeping those raising funds accountable in their respective juridsdictions. It enables implementation of arbitrary law compliance rules, without which a project might not be possible in the first place.
An innovative farmer has discovered a way to produce fresh, healthier vegetables using fewer chemicals by protecting his crops in a smart, natural way. He'd like to bring this innovation to his whole town, but he needs some upfront capital to plant more crops. However, he doesn't know if the future sales will be enough to pay for the investment.
He could do it anyway, taking a huge risk by sponsoring the whole thing and hoping for the best later (that there will be enough demand and purchases to pay off the debt). Or he could simply not take the risk and not grow his plantation.
In the above situation, his community may have lost out on a great idea. Instead, this smart contract gives him another option, to see if there is real demand for his product before he takes on debt.
Using the smart contract, two outcomes are possible:
- In the bad case, not enough people are interested. Those who did participate (if any) simply take their money back from the contract. At least now the farmer knows there is no demand and is not in debt.
- If enough people are interested, the farmer knows he can proceed in producing more vegetables because the buyers have shown a strong signal of interest (skin in the game) by putting money into the contract.
There are 2 main types of actors involved:
- Group buying side: a collective of people willing to coordinate in group buying. This group is called "participants".
- Selling side: A company or person willing to sell a service or product. This group is referred to as the "seller", "shipping agent" or "service provider".
The smart contract has the following possible states:
- Uninitialized: The Crowdtainer contract has been deployed but not yet initialized.
- Funding: The project has been launched and is collecting funds from interested participants. Any participant may change their mind and withdraw their funds at this stage. The service provider is not allowed to withdraw any funds.
- Failed: The project goal has not been reached in time. Any participant can withdraw their funds back. The service provider is not allowed to withdraw any funds.
- Delivery: The project has been successfully funded and the service provider has withdrawn the funds signalling the commitment to deliver the products or services.
Only the selling side (service provider) is able to move the contract into "Delivery" state. This is used to simultaneously withdraw the funds and signal that the provider agrees with the orders and represents her/his "signature" of the agreement to the terms of sale.
If, for whatever reason, the provider is no longer able to provide the service/products, it is possible for the provider to manually signal this via the smart contract method abort(). Or, it eventually enters an "Expired" state if no action is taken beyond expiration time). Both of these conditions set the project state to Failed mode, where contributors can withdraw all of their contributed funds.
For a successful campaign, once the smart contract is in "Delivery" state, it is no longer possible for participants to withdraw their funds, as the service provider requires the funds as a payment to fullfil their promises. Failure to deliver after this stage is outside the scope of this project and should be resolved by normal means (via consumer protection laws and external contracts). In this situation, the provider should return the funds to the participants manually.
Note: Future versions may add other verification methods, so that funds are withdrawn in steps over time (e.g., upon confirmation of milestones) and not up-front all at once, thus reducing the need to trust in the local existing legal system for disputes related to the contractual sale. Other possibilities include connecting Crowdtainer to 'split contracts', where payment goes directly to and pre-defined agents, in pre-defined proportions.
For the group buying side, the smart contract contains two incentive mechanisms (described below) in order to reward participants that provably helped the group to achieve the project goal. This is similar to referral codes available in apps like Uber or Airbnb, but it is different in that usually those credits are restricted for usage within those apps themselves (in posterior transactions), while here, one can withdraw the credits and do whatever is desired with it, since it is redeemed in ERC20 tokens (e.g., a 'stablecoin'). Such indication rewards are proportional to the number of times it was referred to. Furthermore, to incentivize another user to use a referral code, a discount is applied to the new purchase. That said, this mechanism is opt-in an can be disabled during deployment of a campaign.
The following main parameters are given by the user when joining:
quantities: Array with the number of units desired for each product or service.enableReferral: Informs whether the user would like to be eligible to collect rewards for being referred. The participant's wallet address becomes the "referral/voucher code" that can be given to other people. If a subsequent new purchase refers to this given code, it entitles the referrer user a percentage of the 'sale' - redeemable directly in the smart contract if the funding is successful.referrer: Optional referral code to be used to claim a discount. If not specified, the participant pays the full product price times their respective quantities. If specified, half the referral value is credited to the referral code owner (the user which joined withenableReferralset to true), and another half becomes a discount applied to the total cost of the user joining ((sum of product quantities _ prices) _ discount).
Example:
-
Consider a Crowdtainer campaign deployed with a single product at 50 USDC price per unit, a referral rate of 20%, and a minimum target of 500 USDC. Recall that the referral rate is divided by 2, where half is used to apply a discount for a user joining, the other half as reward for the referrer (10% each in this example).
-
Alice joins requesting one unit (thus spending 50 USDC), with referrals enabled for her account. She publishes her referral code in her blog (as of today, the 'code' is simply her Ethereum wallet address).
-
5 other new participants use Alice's referral code to request one product unit each when joining. These new participants get a discount of 10% on their purchase (depositing therefore 45 USDC to join the campaign, instead of 50 USDC).
-
Alice's rewards will be 25 USDC: 5 (units) x 50 (product price in USDC) x 10% (reward rate / 2).
-
Let's say another 5 participants join the campaign (without using referral), causing the minimum raised target to be reached.
Therefore:
- Alice gets one unit of product while effectively spending 25 USDC (cost of joining the campaign, minus the rewards of 25 USDC).
- 5 of Alice's friend is entitled each to one unit of the product, paying 45 USDC each.
- 5 other random participants are entitled to one unit of the product, paying the full price of 50 USDC each.
- The service provider is able to withdraw from the campaign smart contract:
+ 50 Alice's payment to join (1 product unit)
+ (45 * 5) Total value accrued from 5 participants using referral to join (5 product units)
+ (50 * 5) Total value accrued from 5 participants not using referral to join (5 product units)
- 25 Alice's rewards
------------
500 USDC Total available for withdraw by the service provider
The service provider must ship a total of 11 product units, thus the effective price average charged for the product is 500/11 (around 45.45 USDC), which shows that the referral impact was 15%, of a maximum possible of 20% set in the campaign deployment.
All rewards are redeemable only if a project has its minimum funding goals met and entered
Deliverystate.
The minimum target is set by the project creator (when deploying a new Crowdtainer). Also, the project deployer may set the referral rate to zero, which effectively disables the referral system altogether.
Front-ends / UI's should enable ENS resolution to make sharing/typing these codes easier.
In addition to the core "Crowdtainer" contract, a wrapper ERC-721/1155 contract can be used to manage Crowdtainer projects.
Being ERC-721/1155 compliant provides the following benefits:
- User interfaces can more easily manage multiple projects, keep track of ownership, and allow for easy transferability of ownership/claims in projects.
- Interoperability with other platforms that understand the ERC-721 interface.
- Allow service/product providers to authenticate messages for communication and delivery, based on the token owner. E.g.: gated discord channel for chat support, which only buyers can enter, thus solving the spam/bot problem without requiring KYC.
- Allow service providers to ask the customer's personal data (if needed), only when needed (upon successful project funding). This makes the token act as a voucher that is used to redeem the given products. Only when the redeem period arrives, the customer may provide any personal data required for service fulfillment.
- With the token, it becomes possible to easily "gift" someone a product/service, without knowing anything but the person's Ethereum wallet address:
- E.g.: Alice wants to give a bottle of fine wine to Bob. Usually, Alice would have to ask Bob for his physical home address, then put Bob's address in the service provider website. In that case both she and the service provider knows Bob's home address. Having a token allows Alice instead to simply send the token to Bob's Ethereum wallet address, and this allows Bob to claim the wine bottle in the service provider website to be shipped to him. In the latter case, only who needs to know Bob's address knows it: the service/product provider.
- The project can enter a temporary "redeem period", where token transfers are paused. This gives time to allow participants to prove their participation in order to claim the products or services with the service provider (off-chain), providing any further information as required (off-chain).
Currently we have an ERC-721 implementation, which is the contract called Vouchers721(.sol).