League of Pools aims to be the easy first step anyone can take to get their feet wet in DeFi. LOP is a game that allows anyone to invest in DeFi easily and withdraw their deposit. Users learn about DeFi pools by receiving messages before a level. In order to unlock the pool the user must complete a level of the LOP platform game. Then users deposit in the pool contracts and the pool contracts automatically deposit the funds in DeFi liquidity and lending platforms' (Aave,Compound,Uniswap,Balncer...etc) pools. 

Note: we thought about users directly depositing in DeFi platforms through web3 interface, minimizing smart contracts. But went for the first option to finance the gas fees of the game by capturing fees.

HackMoney

League of Pools

a crowdfunding tool for musicians to fund their post production and recording costs. Users contribute, much like kickstarter, but instead of physical rewards they are rewarded with royalties on the streaming revenue
the key feature is that the royalties "expire" after a certain amount of payment is received. so that once contributors reach 1.0X 1.5X or some other ratio of their contribution amount the repayment ends and the artist retains future royalties indefinitely.

Liquidations on DeFi platforms as a means of making money used to be quite inaccessible to a majority of DeFi enthusiasts, while the yields they can offer are very attractive. We aim to combat this by allowing anyone to participate in DeFi liquidations.

LiquiDefi is a profit-sharing platform for liquidations. Users deposit Dai into our pool and are minted sharkTokens. These tokens represent a percentage of the total pool holdings and increase in value as liquidations are carried out. 

The pooled funds are utilised by our liquidation bots on Aave. By using the pooled assets vs flash loans we save in gas cost and are more efficient. This also will give everyday users the chance to profit from liquidation yields.

LiquiDeFi

We have built a Decentralized limit orders platform boosted by market making where we use the idle money that's sits in the smart contracts when ever user places the limit orders. No body  actually want to make their money sit idle in the smart contracts. 

For this hack we just used WETH/DAI token pair and all our contracts are being deployed on the kovan test network.

Advantages: 
This is very capital efficient. So we're relaying the deposit amount into different protocols as long as user won't withdraw money from the smart contract. 

Provides liquidity to the protocols this is actually market making. 

Limitations:
Dependency on other protocols.

Centralized execution service.

No lending rates oracles.

High cost of order creation due to new contract deployment.

Lucrum

Interest rate volatility is a big problem in DeFi, particularly for borrowers who do not have any visibility on what they will end up having to pay back. Blazar solves this with frictionless fixed-term, fixed-rate loans. This is achieved thanks to an automated market maker that leverages the money markets as a stop-gap when there is a mismatch between deposits and loans. For example, if Boris wants to borrow Dai but there is currently not enough liquidity, then Blazar transfers his collateral to Aave and takes out the loan there. As soon as more depositors provide liquidity, then Blazar repays the loan on Aave and matches it in Blazar's internal market.

Blazar

Flashmint is a nocode tool for exploring DeFi arbitrage opportunities in a gamified way. Users can drag, drop and connect DeFi protocols and, hence, build a complex Arb transaction.

Flashmint

Terminal acts like traditional insurance, helping people get compensation for their financial loss in the case of a negative event.
Also, since Terminal is an open protocol, it allows people to join the capital pool and benefit from continuous interest on their deposits.

Terminal

The project has two main use cases:

1) Users can put their NFTs up for borrowing. Anyone can borrow the NFTs as long as they pay the collateral and price to borrow. Once the lending period ends the borrower sends the NFT back and receives the collateral amount.
(Working)

2) ERC-721 tokens could also be used as collateral for loans. A user who has a desirable NFT and needs access to liquidity but doesn't want to sell their asset, can ask for a loan with the NFT being the collateral. An underwriter on the platform would accept the loan, if they agree with the details, and receive interest for taking on the risk.
(Not working)

NFT.Finance

Genie is a no-loss reward platform for games and competitions. User can start a challenge by choosing a game and creating a pool contract, setting winner conditions and other configurations like ticket price.
Every player can join the pool by staking the ticket price. The players' stakes form a fund that invested into a lending protocol and generates interest rate, this becomes the winning reward. 
When the game is over and winner is selected, he receives the prize and all of the players can withdraw their stake back.

Genie

In traditional finance, an option enables the owner to buy or sell an underlying asset at a specified conversion rate before an expiration date. XOpts extends the native capabilities of Ethereum to track and execute PUT Options against BTC. Specifically, we enable sellers to lock DAI collateral in a contract to mint ERC-20 compatible option tokens that can be traded on Uniswap. Buyers can then insure an arbitrary amount of BTC relative to the contract's strike price and pay in an amount of DAI collateral as premium. Finally, options can be exercised once the buyer proves payment to the respective underwriters of that contract using BTC-Relay (a Bitcoin SPV client deployed as an Ethereum smart contract).

Our solution does *not* use any kind of wrapped BTC construction (pTokens, wBTC, ...), but uses *native* Bitcoin transactions instead. Hence, the overhead for the buyer is minimal: anyone who owns BTC can join. Moreover, the buyer *maintains custody* over his BTC - no need to trust a central party (pTokens, wBTC) or committee (tBTC).

**Basic protocol flow**

- A seller (underwriter) creates a BTC put option with a strike price (the value of BTC the seller is willing to insure in Dai), an expiry time (the validity of the option), and a premium (the fee paid to the seller for buying an option in Dai).
- A seller underwrites an option contract previously created by locking a number of Dai into the option contract. This creates a number of option tokens with the specific expiry, premium and strike price that are now available for buyers to obtain. During this process the seller also attaches his BTC address to the option tokens. For example, if the strike price is 10,000 Dai for a BTC and the seller locks 1,000 Dai, he would have generated 1,000 option tokens.
- The buyer then goes ahead and buys a number of option tokens at a specific expiry, premium, and strike price.
- During the expiry time, the buyer can exercise the option. To achieve this, he must send a number of BTC to the seller. Then, he proves that he sent the required number of BTC to the option smart contract. In return, the option tokens are burned and the buyer obtains underlying Dai provided by the seller.
- After the expiry time, the seller can reclaim any unused collateral.
- At any time a buyer can exchange his option tokens on Uniswap in a (Dai/Options) trading pair.

**Components**

- XOpts front-end: The front-end to allows buyers to buy Bitcoin put options in return for Dai. They can exercise the option from the UI as well. It also allows sellers to underwrite Bitcoin put options with Dai. They can also reclaim unused Dai from expired options.
- XOpts smart contracts: A new ERC20Lockable that allows sellers to mint tokens that are then assigned to a buyer when obtaining the option. We also added an expiry functionality to the option.
- XOpts framework: A number of scripts to generate options and testdata.
- Uniswap integration: we are deploying a new pair via the Uniswap factory. We are using the uniswap-sdk and the uniswap-core contracts for that.
- BTC-Relay extension: we integrated payment verification into a solidity BTC-Relay.
- Relayer: We wrote a relayer that submits current BTC block header to the BTC-Relay.

XOpts

Important: There are two source code repositories for the project: https://github.com/opz/DALP-core and https://github.com/opz/DALP-frontend. The source code link will only show you the smart contract code.

The problem:
Adding liquidity to Uniswap to earn fees is not as simple as lending money on Compound or Aave. You need the correct proportions of each asset to start, and moving from one Uniswap pair to another that is generating more fees is especially time consuming. Today, this requires you pull out liquidity, swap to new assets, try to get the correct proportions of those assets, add new liquidity, and then deal with all the token dust left behind.

Zapper can help with some of this for Uniswap v1, but not v2. Regardless, you would still need to monitor your liquidity and manually invest in a different token pair if it starts generating better fees.

The solution:
The Decentralized Autonomous Liquidity Provider, or DALP, solves all these problems. A user simply buys DALP tokens and the DALP manages their liquidity for them, always seeking the Uniswap pairs that can generate the most fees.

How it works:
The DALP contract performs on-chain calculations to rate Uniswap pairs by their ability to generate fees. This is done by comparing the percent growth of a pair’s square rooted k value to the total notional value of the pair’s reserves. The notional value is calculated using the new Uniswap v2 oracles. In theory this tells us which pairs generate the most fees for the least liquidity.

When a user purchases DALP tokens, the ether they spend is added to the liquidity managed by the DALP. This liquidity is swapped to the appropriate tokens so the DALP can add it to the highest rated pair. If the DALP discovers a new pair that has a higher rating, it will remove its liquidity from the old pair and swap to the tokens required for the new pair.

When a user wants to cash out, they can redeem their DALP tokens. An amount of liquidity is removed from the active Uniswap pair that is proportional to the number of DALP tokens redeemed and the tokens are swapped to ETH before being transferred to the user.

The risks:
Impermanent loss is always a risk when adding liquidity to AMM exchanges and the DALP faces the same risk. We want to explore ways to hedge against that risk with techniques such as depositing Uniswap share tokens as collateral on Aave to borrow stablecoins the DALP can use to purchase other assets such as leveraged longs, shorts, or options.

How it benefits Uniswap:
With some refactoring polish, a number of the functions developed for the DALP can be broken out into useful standalone periphery contracts that could benefit others trying to develop on top of Uniswap. These functions are built on top of the UniswapV2Router01 and UniswapV2Library. They simplify the process of adding liquidity from a single balance of ether as well as simplify certain types of swaps.

Where we are going:
In addition to supporting more protocols, we want to improve the DALP’s decentralization. Right now there are a couple of function calls that require a contract owner and we believe we can completely eliminate the need for an owner at all. Because we were able to perform our rating calculations on-chain, we believe the DALP could be capable of operating truly autonomously, with zero or at most very minimal governance. With some extra work, the DALP could exist completely independent and immutable, with no external entity in control.

DALP

The idea of Save is to offer through a chatbot interface an onboarding for non technical audiences into the realm of blockchain, and more specifically to offer investment exposure to curated DeFi protocols, while minimizing risks for the user.
The education part covers some context about blockchain in general of course, as well as some cultural onboarding (memeology), and of course some needed education to the inherent risks of DeFi, and a risk profile assessment. The onramp is done on the side of the chatbot window, in order for the user to ask Save for additional explanations during the process.

Save

Complete details about our submission can be found in our blog post: https://medium.com/@atvanguard/introducing-defidollar-742e30be9780

Including the most important parts here as well:
- Since DefiDollar (DUSD) is backed by existing stable coins, for the sake of the illustration, we start with choosing two stable coins, A and B for e.g. Dai and sUSD as the underlying reserves, in an equal ratio.
- To mint 200 DUSD, the user deposits 100 coins each of A and B.
- Within the mint transaction, A and B are locked in Aave, and the corresponding interest-bearing Aave coins aA and aB are deposited in a liquidity (balancer) pool. Interest income from Aave is redirected to an earnings pool.
- aA and aB in the pool can be traded using an Automated Market Maker mechanism (a pool-based swap mechanism used by Uniswap and curve.fi and for which balancer provides a framework).

Now, say the price of A fluctuates to $1.1 and B goes to $0.9.
- This opens an arbitrage opportunity since, in the pool, A and B are still in a 1:1 ratio. Hence, arbitrageurs will trade A for B from the pool which will cause the values of both the pools to come close to $100 each and the DefiDollar will be balanced again. A small fee from these trades will also be directed to the earnings pool.

While the arbitrage opportunity discussed above will keep the relative prices of the underlying coins in sync, there is still a possibility that the DefiDollar slips from its peg. A couple of such scenarios are when all of the underlying coins have fallen above or below the $1 mark.

To be able to explain this, let me draw your attention back to the earnings pool discussed above, which was accruing earnings from the interest and trade fees. Let’s say this pool has accrued 5 coins of A and B each over some time. This pool will act as a volatility cushion.
- Say the price of A and B has dropped to $0.97 and $0.98 respectively and so DefiDollar would be at about $0.975. To counter this an oracle (chainlink) would periodically be pushing prices of the underlying coins.
- Since the pool of A is valued at $97; to cover the deficit of $3, the protocol will send (3 / .97) = 3.092 coins from the earnings pool to the main pool. Similarly, the pool of B is in a deficit of $2, and hence (2 / 0.98) = 2.04 of B will be sent to the main liquidity pool.
This way DefiDollar will be at the $ mark again.

After there are enough funds for the volatility cushion, any following earnings will act as the protocol fee.

DefiDollar

DeFi protocols are incredibly powerful tools for personal finance. However, there are still many UX barriers that prevent everyday people from taking advantage of them. Installing Dapp browsers such as Metamask is a high barrier to entry, and and transaction confirmation popups can be confusing. Argent has done great work at simplifying DeFi protocols, however this requires custom integration by the wallet developer.

DeFi777 takes a hint from the user experience of the ICO boom. To participate in an ICO, users would typically send ETH to a provided address, and instantly receive their ICO tokens. This action could be initiated from any wallet, and would feel familiar to anyone who is used to sending transactions with Bitcoin or other cryptocurrencies.

DeFi777 lets users use DeFi protocols from any Ethereum wallet (ENS isn't required, but it makes the experience much easier). Users send tokens to various "adapter" contracts, and receive other tokens in response.

Here are some actions that are supported by DeFi777
* Send ETH or any DeFi777 wrapper token to dai.uniswap777.eth, and swap that token into a Dai wrapper (Dai777) using Uniswap
* Send ETH or any DeFi777 wrapper token to dai.balancer777.eth, and swap that token into Dai777 using Balancer pools
* Send ETH or supported DeFi777 wrapper tokens to aave777.eth, and receive wrapped aTokens that accrue interest. Send those aToken wrappers back to aave777.eth to withdraw from Aave
* Send any DeFi777 wrapper token to linkethrsi.set777.eth to swap for wrapped Set Protocol LINKETHRSI  tokens

If users wish to unwrap their 777 wrapper, they can send it to defi777.eth and receive the inner wrapped token.

One other benefit of DeFi777: it can be a tool for developers that wish to integrate with DeFi protocols. Developers may find it is easier to interact with DeFi protocols using DeFi777, as opposed to learning the sometimes-complex APIs of these protocols.

DeFi777

Oya is a decentralized ecommerce protocol owned by its users and run by smart contracts.

Online sellers suffer from high transaction fees from traditional ecommerce marketplaces and payment processors and are forced to pass those costs along to their customers. They also have little control over their own business when orders are going through a centralized service.

We've built the foundation of a protocol that manages orders and payments through smart contracts and surveyed actual online sellers to develop a persona with detailed and realistic pain points. This persona is also informed by our years of experience as Amazon sellers.

We've also developed a high-fidelity design of a decentralized marketplace and a user flow for integrating the protocol into existing online stores running on platforms like Shopify or WooCommerce.

Our naive implementation already has lower estimated fees than traditional ecommerce marketplaces for items over $30, and we think we can bring gas costs lower to be price competitive for cheaper goods. However, the savings for high-end online sellers are significant and a good catchment to draw in real users.

In addition to the basic order functionality, we have coded a basic token rewards system that could be integrated into a DAO for managing and upgrading the protocol. Oya tokens are earned by using the protocol as a buyer or seller, not from a token sale, putting real users in control of how the protocol evolves. Fleshing out the voting and upgrade mechanism would be the next key step.

Oya Market

As a content creator it is hard to self host, market, and monetize your products and services using video. It’s technically hard and time-consuming to deliver a premium service that customers will pay top dollar for. Other platforms are expensive and lack the visibility on how people are engaging with your offers.

Eventdrip is a virtual event platform that lets you launch, promote and create interactive virtual events with premium experiences for fans willing to spend a little more for exclusivity.

Creators can mint merch as NFTs and sell directly to their fans – before, during, and after their event. Our platform wraps around livestream content and gives livestreamers the ability to monetize using digital collectibles. 

How it works:

1. SIGN UP FOR A WALLET
Connect with popular Ethereum wallets (MetaMask, Portis, etc) and interact with our smart contract to create and purchase NFT-based tickets and merch.

2. CREATE & MARKET YOUR EVENT
Anyone can create an event, setting their own parameters such as ticket price and capacity. Creators then market the event to their existing fan base across the web. We used ReactJS for the app and configured based on design in Figma

3. CREATE & SELL MERCH
Creators can mint merch as NFTs and sell directly to their fans – before, during, and after their event. 

4. LIVESTREAM YOUR EVENT
Creators can stream to their fans using existing services (RTMP via YouTube, Twitch, etc). Use ours. Or not. All good either way.

5. GET PAID
Once the event is over, creators can collect their ticket and merch earnings.

This pandemic sped up the need for us to transition our brands and businesses online.

Unfortunately, many artists, authors, musicians, speakers, and performers of all kinds have had to cancel their upcoming live events, shows, and conferences.

It’s uncertain what the future of live events are, and creators need a solution NOW.

Eventdrip wants to reinvent the way we participate in online and physical events using crypto as the catalyst to explosive growth.

Eventually, Eventdrip will not only interface with existing marketplace platforms, but also will have its own marketplace for buying/selling tickets and merch. The protocol will not only prevent fake tickets, but offer a safe medium of exchange.

EMAIL: dan@eventdrip.com

Eventdrip

Connecting Ethereum to your Applications could be a task that requires several skills and most of the time you have to manage also the infrastructure.

In a world that is going to a decentralized direction, everyone should be able to build without experiencing a steep learning curve, simplicity leads to user-friendliness which leads to adoption.

That's why we demonstrate a simple way to keep track of key events on WBTC, which double their total supply few days ago and is actually the leading platform for tokenized Bitcoin on Ethereum.

We built the Twitter integration for HAL and WBTCBot (on Twitter and Telegram). It informs you about new mints and burns on WBTC.

https://twitter.com/WrappedBTC/status/1263638972653162496?s=20

But these are just one use case, with HAL.xyz you can develop several use cases in a jiffy!
And this is just the start, we are going to add more and more integrations aim to be the IFTTT for Ethereum and later on a fully fledged Gluer

Read the long term vision, "The Gluing Manifesto"

https://medium.com/coinmonks/the-gluing-manifesto-159cabef0532

We propose an incentivization mechanism to enhance activity on MakerDAO Ecosystem.

A user can activate a Badge for activities on MakerDAO Ecosystem that are checked both on-chain for real-time activities (eg. voting on a Governance Poll) and off-chain via TheGraph for historical data (events) and stored on a merkle tree verified on-chain.

The user gets a Badge, a proof of its activities on Maker, that is Non-transferable, that means that Is the only owner of  the Badge, in particular when activating the Badge he mint a new Non-transferable Non Fungible Token that can eventually be burned by himself, the owner.

Smart Contract Building Blocks:

InsigniaDAO

InsigniaDAO to check for activities on MakerDAO ecosystem and keep track of redeemers

To enable InsigniaDAO to check on-chain for activities on MakerDAO ecosystem we are using three interface to map the functions that we'll use:

Pot: to check if a user has accrued 1 or more Dai from DSR, via pie(address guy), chi(), rho() and drip() used in the internal function _dai(address guy) to return the wad or the current accrued Dai interest in DSR.
DSChief: to check if a user is voting on a Governance Poll via votes(address) a getter function to check who is currently voting.
Flipper: to check for high bidder in the current Bid in Collateral Auctions via bids(id) a getter function of current Bid on Flipper to check for bids(id).guy the high bidder.
The function checkRedeemer(uint id) will check on-chain for the previous activities on MakerDAO and will store the hash of the caller address, casted in address type, into the OpenZeppelin EnumerableSet.AddressSet redeemers that will be verified in BadgeFactory via verify(address guy) function linked to it, to allow a redeemer to activate a Non-transferable Badge.

InsigniaDAO, let the owner to set (via setRootHashes(bytes[]) memory rootHashes) an array of root hashes, called roots, ordered by template Id to allow redemeers checked off-chain for activities via TheGraph on the front-end, and stored into a Merkle Tree, to activate Badge. The getter function roots(uint templateId) is then linked to BadgeFactory and checked via OpenZeppelin MerkleProof.sol verify() function.

The contract also inherits OpenZeppelic AccessControl.sol to set the Pauser role to the owner of the contract that can pause(), unpause() functions in case of emergency (Circuit Breaker Design Pattern).

In order to integrate OpenGSN, InsigniaDAO inherits BaseRelayRecipient.sol and do the following changes:

msg.sender is replaced by _msgSender().
trustedForwarder is set in the constructor with the address deployed on Kovan
the following function is added to override OpenZeppelin Context _msgSender():
  function _msgSender() internal override(Context, BaseRelayRecipient) view returns (address payable) {
            return BaseRelayRecipient._msgSender();
  }

BadgeRoles

BadgeRoles Access Management for Default Admin, Templater and Pauser Role

BadgeRoles inherits the OpenZeppelin AccessControl.sol, allowing the owner of the contract to be set as Default Admin, Pauser and also as Templater and to add a Templater via addTemplater(address guy).

In order to integrate OpenGSN, BadgeRoles inherits OpenGSN BaseRelayRecipient.sol and do the following changes:

msg.sender is replaced by _msgSender().
trustedForwarder is set in the constructor with the address deployed on Kovan
the following function is added to override OpenZeppelin Context _msgSender():
  function _msgSender() internal override(Context, BaseRelayRecipient) view returns (address payable) {
            return BaseRelayRecipient._msgSender();
  }

BadgeFactory

BadgeFactory to manage Templates and activate Non-transferable Badges for redeemers

To enable BadgeFactory to verify redeemers checked on-chain/off-chain for activities on MakerDAO ecosystem, when they try to redeem their Badge, we're using the interface InsigniaDAO to map the function we'll use.

In particular, we'll use:

verify(address guy) to verify redeemers checked on-chain.
roots(uint templateId) a getter function to return root by templated Id to be verified via MerkleProof.sol verify() function, allowing redeemers checked off-chain and stored into a Merkle Tree to be able to redeem Badges.
A Merkle Tree is generated for every Template and the root hash is updated by owner of InsigniaDAO daily to allow batches of redeemers to be checked and to redeem Badges.

BadgeFactory inherits BadgeRoles, allowing a Templater to create a new template via createTemplate() specifying name, description and image.

It also inherits ERC721Burnable, where the _transfer() has been overridden to implement Non-transferable feature, allowing redeemers checked on-chain/offchain to redeem a Badge for a specific activity on MakerDAO ecosystem via activateBadge() that will verify if the caller is a redeemer and then will allow the caller to mint a new Non-transferable Badge with tokenURI stored on IPFS (eg. "ipfs.json").
The owner of the Badge can then burn it eventually via burnBadge(uint tokenId) specifying the token Id of the Badge.

During deployment the contract sets the following ERC721 metadata:

name: "InsigniaBadges"
symbol: "BADGES"
baseURI: "https://badges.makerdao.com/token/"
In order to integrate OpenGSN, BadgeFactory inherits BadgeRoles and add the following function to override the _msgSender() in OpenZeppelin Context and in BadgeRoles:

  function _msgSender() internal override(Context, BadgeRoles) view returns (address payable) {
            return BaseRelayRecipient._msgSender();
  }

BadgePaymaster

BadgePaymaster to pay for user's meta-transactions

In order to pay for user's meta-transaction BadgePaymaster inherits OpenGSN BasePaymaster.sol and implement the following functions:

acceptRealyedCall()
preRelayedCall()
postRelayedCall()
Once deployed, BadgePaymaster owner need to set RelayHub contract address via setRelayHub(IRelayHub hub) that can be found on Kovan.

Finally the owner just need to fund the contract sending ether to BadgePaymaster contract address and the balanced will be automatically updated in RelayHub contract.

MetaBadges

Income JAR is a Decentralized Finance project giving users the ability to create an income stream from their assets.  At its core, the user will deposit crypto assets like ETH or DAI into the contract, and will create a monthly or annual income stream, yielding a certain rate of return.  

The basis and theory for the application is an annuity in the traditional finance world.  An annuity allows investors to pay a premium, and receive an income stream, or defer the promise of an income stream.  In traditional finance, the annuity is actually an insurance-based product, which comes with certain tax benefits (which we obviously can’t replicate at this time).  

However, the idea is powerful.  As a retail investor, I don’t want to always manage my investments, trying to get the best return compared to my risk profile, life profile, age, etc.  It might be best for me to receive an income stream that is equivalent to a decent rate of return, and offload much of the investment risk, time, effort, etc. to another company.  

We wanted to create a similar ability in the Decentralized ecosystem.  

In our initial version of Income JAR, we will give the user the following choices:

Deposit amount
Length of income stream - 1, 3, or 5 years
Payment frequency - monthly, quarterly, or annual.  

We will also pre-determine the rate of return for each length of the income stream


1 year - 6-7%
3 year - 8-9%
5 year - 12-13%

Once the user makes those choices, he will be presented with the amount of the regular income payments.  If he agrees to the amount, he can then connect an Ethereum wallet and approve the transaction.  

From the user side, the deposit amount will leave the wallet, and JAR tokens will be placed in the wallet.  There is 1 JAR token for each DAI that is to be paid, and each JAR token is only good for a specific month.

For example, if Ron wants to deposit 1000 DAI and receive monthly income for a year, he will receive 89 DAI per month.  After agreeing to the transaction, the 1000 DAI will leave the wallet, and the 1,068 JAR tokens will go into the wallet.

Each JAR token will be denoted with a month and year.  In this example, the first JAR tokens might be July 2020.  So on the first of July, 2020, those 89 JAR tokens will leave the wallet, and 89 DAI will be there.  

At any point, Ron will have the ability to come to our website and connect his wallet.  We will show him his income steam based on the JAR tokens he has in his wallet, and even a Net Present Value based on a discount rate he chooses.  

Technicals

As of now, we will accept ETH or DAI as the deposit currencies.  We will use Chainlink as the oracle to determine the value of the ETH for purposes of creating the amount of income.

The JAR tokens will be minted immediately, and they are ERC-20 tokens.  

Since they are just ERC-20 tokens, they can be moved, traded, sold.  We intend to give users the ability to send them to other wallets.  We may offer to buy them back, but at a lower rate than we sold them originally.  

Target Market

Our time in traditional financial services has taught us how valuable an income stream can be over just holding assets with a hope of increase in value.  We use annuities for such a purpose in traditional finance, and they help our retirees have some guaranteed income based on a certain value of their assets plus a growth rate.  The investors don’t have to worry much about the investment portfolio, volatility, management, etc.

With this product, we expect to build something similar in the Decentralized Finance world.  

First, we know many DeFi users are not in the US or other developed countries that have insurance products like annuities.  

We also know that many DeFi users are not able to manage their assets all the time.  They want to take advantage of the potential to earn greater returns than in traditional banks or even insurance or investment products, but don’t have the time, expertise, or ability to discover those returns for themselves.  

If we are to see more DeFi users that are not crypto native, but are more early majority, we need to help them easily take advantage of the efficiencies and opportunities, without having to learn all the nuance.  

While we know the DeFi and crypto enthusiasts might not find the utility in Income JAR, we feel that the early majority will like the ease of use, and increased usability of Income tokens.  As a parallel, we look to companies like Outlet Finance and Dharma as projects that allow users to see the growth afforded them from DeFi protocols, without having to fully manage the protocols themselves.

Use Cases

The easiest and most obvious use case for Income JAR is to just have an income stream, with a good rate of return.  Again, we see this in traditional financial planning as a way to take some risk off the table and know that a client will receive income.

However, since these are ERC tokens, they are able to be sent to other wallets, traded, or sold.  This opens so many opportunities for use cases.

Remittances
We can see users buying the income tokens, and sending them to family in their home country.  The family would not have the ability to spend all the money at one time, which is safer.  Of course, they are earning a rate of return over this time.  

Allowance
Parents can purchase the income streams, and send them to their kids’ wallets as an allowance.  This can work particularly well in the case where the kids are in college.  Again, the children cannot spend all the money at one time.  

Recurring payments
The tokens can be purchased to match recurring payments like credit card, mortgage, auto loan, tuition, rent, etc.  The return being generated on the deposit is usually higher than the interest charged for the payment terms.  

Project Escrow
Paying over time for a development or construction project, I can place the tokens in escrow and know I have the cash flow, at a decent rate of return, to pay contractors.

How Does it Work

When a user makes a deposit of ETH it is first converted to DAI using Uniswap.  

The DAI is then added to the Investment Pool.  Since we always know how many tokens we have outstanding for each month, we automatically move enough DAI into the safety pool to cover the next 2 months’ of payments.

We will be actively managing the funds in the Investment Pool.  Based on our short-term, mid-term, and long-term cash flow needs, we will be allocating among different protocols and investment options.

We will be comparing the value of the Investment Pool to our cash flow needs.   When the value of the pool is greater than the Net Present Value of cash flows, at 8% discount rate, we will move the delta to the Safety Pool.  The funds in the Safety Pool will be invested in various lending protocols to continue to receive some growth, while not being subject to currency risk.

The Investment Pool will be invested in various options, some of which will not be pure DeFi investments, and some will not be on the Ethereum blockchain.  For example, we may decide to stake a different cryptocurrency to increase our returns.  

Even though our investments are not purely DeFi, they will all be reportable and auditable, since they will all be on some chain.  Using Chainlink, we will provide the total value of all of our Pools, as well as the NPV of all cash flows, so users can see that we have enough assets to cover our obligations.  

Our compensation will be the interest generated by the funds in the safety pool.


Future Plans

We have several options for the future of Income JAR, as we believe income tokens will become a vital part of the DeFi infrastructure.

Wallet connection
We would like to connect to various Ethereum wallets like Argent, Portis, etc. as a DApp in their UI, so users can quickly create JAR Tokens, and see their own income stream.  

They would also be able to buy, sell, and trade the tokens. 

Market/Exchange
We would like to create an exchange for the JAR tokens, in which users can buy and sell as many of the tokens as they would like.

Multi-currency Deposit
We will have the ability to accept deposits in multiple currencies.  We have not done it in this version as we do not want to take on the liquidity risk of being able to quickly convert to DAI.  Shortly, we will have several more options for deposit, as we assess those currencies with high liquidity on Uniswap and Kyber.

White Label
We would like to give investment managers the ability to offer Income JAR tokens but utilize their own investment management tools.  For example, a group like Zapper, or PieDAO, or a fund using MelonProtocol could use their own wealth management to manage the Investment Fund.  

We can give them the ability to make a few quick choices, and be offering their users income tokens rather than just volatile returns.  

Fiat Connection
Whether through a connection with a smart wallet like Dharma, or some other wallet that already has a Fiat on/off ramp connection, we would like to give users the ability to create income streams from Fiat currency, while we manage the crypto portion in the back end.  

Security and Safety
The first iteration of Income JAR is on the Ropsten TestNet.  Before we go live we plan to have the smart contracts audited and the reports made public on our website.

The wallets we use will have multi-sig capabilities and will require more than one of us to enable transactions.

The Investment, Safety, and Payout pools will all be transparent, showing the values.  As mentioned earlier, not all the Investment Pool funds will be in pure DeFi apps or protocols, but will be all on-chain so they can be audited.  A report will be constantly available on our website.

We will purchase Smart Contract cover via Nexus Mutual to cover any smart contracts for which the coverage is available.  We will also be utilizing hedges like Opyn and Hegic to protect against extreme downside risk in our Investment portfolio.  We will also be managing risk via cash flows management.  We will be able to weather some volatility in the value of certain staked tokens by virtue of the diversified allocation that can provide regular returns.

In the first iteration, we will limit deposits to $1000 initial values per wallet.  In the case that a smart contract is hacked or the system is gamed, we don’t want our users to lose too much.

Income JAR

On deployment, the bank owner specifies the following parameters:
- Debt Token: This is the token users borrow from the bank (i.e. USDC)
- Collateral Token: This is the token the bank accepts as collateral (i.e. TRB)
- Interest Rate: The annual interest rate the bank charges borrowers
- Origination Fee: The fixed fee charged to borrowers
- Collateralization Ratio: The loan-to-value amount borrowers must maintain to avoid a liquidation
- Liquidation Penalty: The fixed fee charged to borrowers who get liquidated
Once deployed, the bank owner must deposit some debt tokens into the bank's reserve. After depositing debt tokens, users can deposit collateral tokens and borrow the bank's debt tokens. During the borrow, the borrower is charged an origination fee and then interest will accumulate until they repay what they've borrowed plus interest and fees. If at anytime the price of the collateral falls, then the bank owner will liquidate the borrowers collateral to repay their debt.

The project I am submitted includes the smart contract code, test suite, and a DApp all designed to be extended and deployed by anyone interested in offering loans on Ethereum.

Bank Protocol

This project lets people play Kahoot quizzes with prizes distributed via Ethereum. Players bid some ethers on our smart contract, which handles quiz result and sends money to a winner.

Find a Project