Lenders should be able to view loan request and amortization schedule and buy fractional shares of loan request

Step 3: Lenders can view Loan Request and amortization schedule
Once Loan Contract (at the stage of 'new request') has been deployed, lenders should be able to view the loan request on a frontend app. The frontend app should show the loan parameters that the borrower requested. The frontend app should also show the amortization schedule (i.e. repayment table). The frontend app might also show some graphs to show the declining outstanding balance.

Step 4: Lenders can fund the loan request
[Needs more thought] Lender should be able to either:

Buy fractional shares of the loan (e.g. 1000 outstanding shares) - this might be easier for routing repayments
Contribute variable amount, as long as it is within the loan cap

For simplicity, Lender should use a stablecoin (e.g. Dai). However, given that Dai is currently trading at 0.95, we might explore fiat-collateralized stablecoins (e.g. Paxos, USDC) as an interim measure.

To dos:

Wireframes for Lender page and viewing amortization table @onggunhao
Use ERC-20 contract to interface with Dharma debt contract?

Legality of Loan

I have some questions/concerns regarding the loan:

Who forces the smart contract if either party breaches the contract?
What if the stable coin we use closes down? How do I repay?
What if the stable coin I use is no longer 1:1 ratio, lets say it changes to 1 coin for 1000 dollar or the other way around? How to mitigate or how to make sure it's fair for both parties in case changes happen
Is it possible that one of the lenders force me to early repay the full amount I owe them before the loan due?
To what extent I have to share my personal data? What will they know about me and how can I be sure it's safe and not misused

Routing of repayments to debt token

Payment values derived 'on demand' vs Payments Table
It's about gas cost, complexity on users, and if one enables more w/ tradable debt tokens

Withdrawal vs Direct Transfer
I'm a fan of withdrawal pattern rather than dealing with the loops and sending money directly. It removes the potential looping pitfalls and gives the lenders more control becuase they can choose when and where to send their funds.

Contact USDC and Paxos teams to let them know about project

Think of way to do proof-of-"social attestation"

Initial thoughts

Can we use existing tools (e.g. 3Box or uPort) to verify social media profiles of borrowers and attestors?
If we do it from scratch, can we use the LinkedIn OAuth flow to get users' token and verify ownership of LinkedIn account?
Loan Contract needs method to allow another wallet (hopefully w/ 3Box or uPort) to attest
Is there a better name for social attestation? Gah

Get landing page email signups working

Mailchimp campaign w/ newsletter?

Favicon and Icon

Favicon
Logo

Spec for 3Box Integration

Purpose

We need a Decentralized ID provider for the Borrower and Social Attestor's identity and links to their socially verified profiles.

Functionality

Profiles API

3Box's "Profiles" API supports basic social identity and basic reputation

Full API documentation

Can get existing public profile of an address (i.e. name, image, basic social metadata)

There is also a read-only 3Box API:
Read-only 3Box Build API

// Read profile data
const profile = await Box.getProfile(<ethereum-address>)
console.log(profile)
// Output:
// {
//   name: 'mollie the narwhal',
//   emoji: 😋
// }

const name = await box.public.get('name')
console.log(name)
// Output:
// 'mollie the narwhal'

const email = await box.private.get('email')
console.log(email)
// Output:
// 'mollyí[email protected]'


// SET

// Update public profile data
await box.public.set('name', 'Molly the Narwhal')

// Update encrypted profile data
await box.private.set('email', '[email protected]')

Storage API

3Box's Storage API saves data to an OrbitDB key-value datastore controlled by user. User can consent to their data being shared w/ dApp)

"Global Namespace"

Public (i.e. visible to everyone)
Private (i.e. global access to any app that opens the user's box)

dApp-specific Space

(i.e. an dApp-centric space which has both a public and private store, user has to grant explicity consent)
Public store (??)
Private store (only our dApp is allowed to update data and read private store)

// Read space data
const spaceData = await Box.getSpace(<eth-address>, 'myApp')

// SET

// Open space for writing
const myAppSpace = await box.openSpace('myApp')

// Update public space data
await myAppSpace.public.set('favorite-nft', 'Space Narwhal')

// Update encrypted space data
await myAppSpace.private.set('last used', 'id-of-last-used-item')

How we can use it

We can use 3Box as a DID provider for Borrowers and Social attestors (as a simpler solution vs. Bloom, which requires more integration work)
Borrower's deployment address should be the same as their 3Box Eth address
Should lenders have option to use 3Box to provide identity?

Walkthrough

Fields in 3Box Public Profile

Questions to 3Box team

Basic questions

Is box.private a global namespace for the user? (i.e. if I create a new key called loans, another app could possibly remove it?).
Is box.space.public a thing? For a specific use case - I want people to know that this person has an open loan, but nobody except my dApp can change the values
box.logout - will this continue to work, even if the user logs out of Metamask? (are you caching the jwt in localstorage?
What does Box.isLoggedIn check for? Does this refer to whether the user is logged in via Metamask, or whether they've authorized us to open a box?
If data is stored on IPFS or OrbitDB, who is paying for the storage?

Verified Accounts questions

Overall intent: we want to show "verified social media profiles" of borrowers and social attestors.

Should we just ask the user to create a 3Box account, and then in our dApp we use Box.getVerifiedAccounts?
box.verified - what does this do?
box.linkAccount - how is linking different from verifying?
box.isAccountLinked - same as above
verified.DID() - what does this return? The Ethereum address?
Will you be adding Linkedin Integration anytime soon?

Can we use an existing loan contract?

Dharma
It will add unnecessary complexity for the loan process and will still require custom code for the crowdfunding aspect. We can certainly take architectural inspiration.

Compound

Check viability of Compound for loans

After talking with the founder, I've learned Compound is interested in companies building on top of their platform. I'll see if / how we can use the platform.
I'd prefer to minimize the custom smart contracts for risk and expense

Clean up Readme to include description of project, how to participate

Create loan contract prototype

The loan contract is essentially an extension of openzeppelin crowdsale contracts that takes in a loan token rather than either.

Parameters are defined on creation
Only 1 loan currency is accepted (that is defined at creation) [this could be expanded without too much work]
There is a hard cap
Once the cap is reached, the money can be withdrawn
There can be a kickstarter-style time limit

Next work:

Finish the prototype.
Use logic proxy for the LoanRequests to dramatically save deployment costs.
Write the basic tests.

Deploy to Heroku and set up simple CI process

Splunking

Run on localhost
Read through bloom-starter-react Heroku docs

Deploy to Heroku

Things to KIV

(KIV due to time? Also Heroku's review apps are pretty nice)

Enable review apps w/ subfolder Procfile
Set up Travis CI
Separate development and production branches?

Buy `ines.fund` for $3.99?

Logo Design

Where?

Navbar
When the web app requests data sharing to the mobile app via QR code, information about the org is displayed incl. a logo.

Inform Bloom, Dharma of the project

Borrower should be able to deploy a loan request with amortization table

Spec

Step 1: Borrower deploys Loan Request
Borrower should be able to deploy a Loan Contract, which defaults to the initial state of "New Request". The borrower will specify loan request params, which are the following:

principal amount
disbursement date
disbursement address
effective interest rate
tenor
grace period on principal
grace period on interest

Step 2: Loan Request produces deterministic amortization schedule
Loan Proposal should have a call function that, based on proposed loan parameters, generates an amortization schedule (i.e. proposed repayment schedule). This removes the possibility for ambiguity (e.g. different rates)

Things to decide

Use Dharma debt request contract?
Can Dharma debt contract produce an amortization table?
Can Dharma debt contract accommodate a grace period of 24 months?
Does Dharma debt contract produce a principal / interest / fees / penalties breakdown?

Finalize Ines' Loan Parameters and Amortization Table

I will be using Apache Fineract (an open source core banking system) to illustrate key loan concepts, as well as generate a sample amortization table.

Mifos Demo:
demo.fiter.io
User: mifos
Pass: password

Sample Loan Parameters

See annotated screenshots below

Sample Fee Parameters

Sample Amortization Table

Bear in mind that this amortization table is at a 3% per month interest (i.e. 36% per year), which wreaks havoc on the numbers (you'll see that a $60k loan eventually earns the bank 3 times that amount in interest!) This is the reality facing emerging markets

Realistic do-up of sample loan:

I used Apache Fineract below, and then go to the following URL
demo.fiter.io
User: mifos
Pass: password

https://demo.fiter.io/#/viewloanaccount/126

Parameters
Principal: US$60,000
Interest: 6% per annum (i.e. 0.5% monthly)
Grace period on Principal: 24 months
Loan Tenor: 144 months (12 years including 2 years of study)

Results
Grace period installment (1st 2 years): $295-305
Monthly installment post-graduation: $700
Final repayment tranche: 20 Sept 2030

Have beta warning on loan / lender page

Similar to Uniswap

Do up first iteration of wireframes for Lender's view (fractional funding), Social Attestation, Repayment tracking

Reach out to potential lenders and test wireframes on them

Add an email opt-in on landing page

This is a plus for the bounty judgers, to have a live site with an email opt-in.

Loan Funding page

@tspoff
I am starting to implement the Mockups from @onggunhao in #13 .
Is there a particular preference for rebass https://rebassjs.org/getting-started,
We will need something with more components.
I am thinking we could use this to test https://rimble.consensys.design/

Decide on project name (Enable or Socialbond)

Twitter poll posted at:
https://twitter.com/onggunhao/status/1132978090420916224

Test assumption that people are willing to loan Ines stablecoins at prevailing rate (6%)

Task

We need to test and validate the assumption that there are at least 600 people willing to give a $100 stablecoin loan.

Why this is important

Enable is a P2P marketplace. We've validated demand for one side (i.e. demand for loans). I don't think we've validated demand for the other side (i.e. supply of loans). It's critical to validate this for the following reasons:

Ines needs to have some idea of whether she needs to find alternatives
The time cost of building even a MVP is high, and there is opportunity cost on our part
This is especially for the design / front-end eng part, which is time consuming

I learned a few hard lessons from previous startups:

Always do a demand experiment before sinking in time / resources (i.e. Tim Feriss)
Do riskiest assumption tests, instead of building MVPs: i.e. test core value prop before getting stuck in product / eng

Proposal

I'll use 2hrs to do up a simple one page site at www.ines.fund. This one page site will articulate the lender value proposition. It'll include the interest rate, repayment schedule, our backstory at the hackathon

We'll then have a simple call to action that leads to a Google Form. We'll ask:

Do they want to lend or do they want to donate?
How much are they willing to lend?
What interest rate do they want to lend at?
What stablecoin do they want to lend in?
Do they mind having a video interview w Ines as a pre-screen?
What recourse do they want in case of late payments or defaults?

This data is important for us to figure out whether this project looks more like a GoFundMe, Kiva, or LendingClub.

I'll put this out on Crypto Twitter and Reddit etc, and we'll ask the community to help us forward it around. Hopefully Consensys will help us spread the survey.

I see this as a low-risk experiment which helps us learn quickly and fail fast.

If the results come back negative, I still think I'll work on the project but really focus on the Solidity stuff instead of trying to fill the gaps on design/UX and "bizdev".

Practice and ensure process to redeem stablecoin works (USDC, Paxos etc)

Why

On May 20th, Ines will need to show proof to Cornell that she has $60,000 in the bank
Assuming that the loan amount is funded, we will need to go through the stablecoin provider's redemption process (e.g. USDC, Paxos) to convert the stablecoin into fiat

Todos

A lot of this is business-related, and Ines will be driving this

Research redemption processes for various stablecoins (Paxos, TrueUSD, GUSD, USDC)
Go through process for KYC / AUML to get an account with each of the stablecoins
If necessary, contact the stablecoin to let them know we are doing this experiment and ask them for help with redemptions / making sure we can
Can we run an experiment where we buy some Stablecoin on an exchange, and then redeem it to a bank account (to test that the process works?)

Definition of done

Ines should be able to redeem stablecoins from her crypto wallet, and get fiat in her / her husband's bank account
She should have gone through the KYC / AUML and activation process for stablecoins

Resources (Stablecoin to Fiat redemption)

Paxos
Paxos' redemption process

USDC
USDC Redemption Process

TrueUSD
TrueUSD Redemption Process

GUSD
GUSD Redemption Process

Create User Staking prototype

User staking is very simple - users can just stake for another user in this contract and an event is emitted. The indexing service collects these and they are used as part of the calculation to determine the creditworthiness of an individual.

Based off the unimplemented bloom model as described in the whitepaper
When users stake eachother, their scores influence eachother.
Users with low credit can establish some credibility if more established users vouch for them
Score calcuations will happen off chain for performance (all primary data is on-chain, all derived data is calculate off-chain)

Assess Stablecoin suitability (Dai, USDC, Paxos etc) as a fundraising medium and smart-contract compatibility

Why

Dai might be too volatile and high stability fees might result in very high interest rates (currently 14.5%). For 150% collateralized loans on Dharma, the interest rate is 11%.
Dai currently only trades at ~0.98 : 1 USD. The exchange rate still fluctuating and there is a chance that it changes in the future, leaving Ines susceptible to forex risk.
Fiat-based stablecoins might have significantly lower interest rates.

Analysis of similar projects

lendoit

https://lendoit.com/

colendi

https://www.colendi.com/
Colendi is doing sovereign ID + Credit scoring mechanism as their core product.
Conclusion: Core business is possible partner, looking to build competing product in the future

Credit scores are more credit bureau like - they collect phone / social media data, combine it with data from trusted providers. and Colendi calculates a score based on it.
This score is sold to lenders / merchants.
The first app they want to build is microlending
Our app would be an app on top of the core mechanic, it’s one of the things they’re looking to build going forward.

Ultimate vision: “In Colendi ecosystem, users can create their Colendi ID and get Colendi Score and can join Colendi network to access microcredits, P2P financing and installment shopping by simply using Colendi app.”

EthLend

Interesting project for ethereum loans. Talks about support for unsecured loans in the future, they have users earn 'credit tokens' on successful repayments that they can stake as 'reputational collateral' in future loans.
Conclusion: Good source of inspiration

r/borrow

Online P2P loan marketplace. No blockchain, just people! Interesting case study in p2p unsecured lending.
https://www.reddit.com/r/borrow/

Patch Tar security vulnerability

Enable Contract Upgradability

What's upgradable

Social Staking logic
TermsContract
CrowdfundFactory

What's not upgradable:

TermsStorage
Crowdfund instances.

Governance Discussion

The parties with power to change the system are the Core Devs and a DAO of stakeholders for each loan.

The Core Devs power is intended for rapid response in contract emergencies. To that end, they can pause any contracts in the system.

However, the DAO holders have to vote on any changes they propose, and can unpause the system. They can also ban the devs from pausing if they abuse their power.

What changes are possible:

Logic upgrades / bug fixes, say of the Terms Contract.
Otherwise changing the address of a core contract
Choosing to go around Dharma (intended if dharma fails), by unlocking the "native backup repayment process" that lies dormant on each Crowdfund contract.

We're skipping renegotiations of terms for now - it's messy even in "real life".

Find potential loan funders and test wireframes on them

To prove business case of 2-sided loan marketplace, we need funders willing to lend money.

Daniel to use wireframes and talk to people in industry, w intent to validate and rapidly iterate prototype / business case:

Add Ethereal Hackathon win to Readme (with award video)

Demo Discussion

The MVP live demo imo is a lender signing on, checking out the homepage / loan / user profile, and requesting data from the user.
I'm using Ines (Borrower) and Daniel (Lender) as the sample users here.

Build Process

Deploy our smart contracts to rinkeby or mainnet
Deploy the web app on Heroku

Pre-demo setup

Ines creates the Loan request
Daniel vouches for Ines account.

Demo

Daniel signs in and views the landing page / loan page / account page.
Asks for attestation data from Ines to evaluate candiate?
Ines forward their attestation data from Bloom to the potential lender somehow.
Daniel makes a payment to the (rinkeby) crowdsale and it shows in UI.

Any more steps we can add to the UI are good:

Creating loan requests through the UI.
Stake other users through the UI.
Display full repayment data like in the mockups.

More important than any by far is a well researched business case imo

Consideration: Data that currently isn't stored anywhere

Large text (user public profile, loan description): We can just mock it up in the front-end, or store on IPFS if there is time.
User photo: Likewise.

Break down high-level specs for Loan Contract and user-stories

I'm going to just take a crack at high-level specs and user story, which we can refine over the next few days.

High-level Spec

Step 1: Borrower deploys Loan Request
Borrower should be able to deploy a Loan Contract, which defaults to the initial state of "New Request". The borrower will specify loan request params, which are the following:

principal amount
disbursement date
disbursement address
effective interest rate
tenor
grace period on principal
grace period on interest

Step 2: Loan Request produces deterministic amortization schedule
Loan Proposal should have a call function that, based on proposed loan parameters, generates an amortization schedule (i.e. proposed repayment schedule). This removes the possibility for ambiguity (e.g. different rates)

Step 2B: Social Attestation

Once Loan Request is created, others can "attest" for the loan through Bloom ID or 3Box linked accounts

Step 3: Lenders can view Loan Request and amortization schedule
Once Loan Contract (at the stage of 'new request') has been deployed, lenders should be able to view the loan request on a frontend app. The frontend app should show the loan parameters that the borrower requested. The frontend app should also show the amortization schedule (i.e. repayment table). The frontend app might also show some graphs to show the declining outstanding balance.

Step 4: Lenders can fund the loan request
[Needs more thought] Lender should be able to either:

Buy fractional shares of the loan (e.g. 1000 outstanding shares) - this might be easier for routing repayments
Contribute variable amount, as long as it is within the loan cap

For simplicity, Lender should use a stablecoin (e.g. Dai). However, given that Dai is currently trading at 0.95, we might explore fiat-collateralized stablecoins (e.g. Paxos, USDC) as an interim measure.

Step 5: Loan Contract needs to determine what to do as funding period ends
[Needs more thought] Mechanics associated with ending funding period:

Should there be a deadline for funding a loan? By block height?
Can people withdraw their funding amount as long as the amount hasn't been disbursed?
What happens to partial loan funding?

Step 6: If fully funded, Borrower needs to confirm the loan and disburse principal to wallet
Once the loan funding amount is reached, borrower can "confirm" the loan, with the total amount being .send to their pre-specified wallet address. For safety we might have a method to allow him/her to withdraw a variable amount (e.g. 1 Dai) to make sure the wallet address is correct.

Step 7 (loop): Borrower makes a repayment to the loan contract each month
Each month, Borrower calls a MakeRepayment contract and pays a stablecoin (e.g. Dai, USDC etc).
Needs thought What happens if borrower just sends money into smart contract, without calling MakeRepayment? (i.e. confusion or mistake made)

Step 8: Loan Contract assesses each repayment and updates Amortization table
Loan Contract will track repaid amount and update the Amortization table. If Repayment is late, repayment amount will go into settling the payment streams in order (i.e. Penalties, Fees, Principal, Interest).

Step 9: Amortization table should deterministically update outstanding loan amount and calculate additional interest if borrower defaults
If borrower defaults on multiple repayments, Loan Contract should have a call method that takes into account the additional interest (or late fees) so it can deterministically calculate additional interest / late fees.

Random ideas

Can the lender "shares" be tradeable to allow for secondary market movement and liquidity
Can we securitize lender "shares" to package loan bundles, albeit with the repayment streams of underlying assets completely transparent?

Implement Solidity CI and testing related packages

Surya for graphing out contract dependencies
https://github.com/ConsenSys/surya

Developer environment

Setup repo-level linter (solhint? ethlint?)
Setup repo-level formatter (prettier?)
Setup git hooks to run lint before upstream push

https://medium.com/edgefund/testing-and-code-coverage-of-solidity-smart-contracts-660cb6291701

solidity-coverage
eth-gas-reporter
solhint
solidity-docgen

https://ethereum.stackexchange.com/questions/47188/what-continuous-integration-services-support-running-truffle-solidity-tests/59176

https://blog.coinfabrik.com/test-solidity-smart-contracts-using-travis-ci/

https://ethereum.stackexchange.com/questions/47188/what-continuous-integration-services-support-running-truffle-solidity-tests/59176

Architecture Discussion

Here's a link to a draw.io architecture diagram (can open in draw.io and make changes I believe)
https://drive.google.com/file/d/1U54sHhv3xVk7-CZ5dnR1l-UjgkhmGyRO/view?usp=sharing

I'm happy to recreate it in a more collab-friendly software if anyone has suggestions.

Design and validate wireframes for Loan funding flow, and Post-funding flow

Deliverables

Balsamiq wireframes (clickable) to test and prototype ideas
Interaction design is critical: build in Rimble UI components etc

High-level spec

Fundraising period

Crowdfunding page as the home page
What should the repayments table look like during fundraising period (i.e. my projected cash flow streams)

Interim period (crowdsale complete, pending selection of funders)

(potential) How do we show that a loan is fully funded?

Funding a loan

What should the "fund loan" process look like?
What warnings should we show the lender?
How do we explain the issuing of debt token to the funder?
How do we prevent someone from overfunding a loan?
How do we ask potential funders to include their email address, so that we can do a video interview with them? (Ines' request)

Funding goal complete

How should we show the details of the loan?
What should we show? i.e. on time, in default, early settled (copy Mifos' UI)
How should we show the debt token allocations? i.e. who owns the debt tokens
How should we show the repayment status (i.e. which tranches are settled, etc)

Examples:
Warning should be similar to Uniswap

Assess Dharma contracts for suitability / extensibility

Why

Dharma has a set of open-source loan contracts available

Todos

Assess suitability of Dharma contracts for multi-repayment loans with amortization schedule
Reach out to Nadav / Sid to ask about Dharma contracts / collaboration
Install Dharma truffle box in repo (get sample loan contracts)

Storing or generation of repayment values from Terms Contract

Do we need a big table? How many variants are there?
Can we have it mathematically derived w/ a few parameters (for less cost)?

If we do need a table, I envision us passing it in on contract creation and having it be static.

Loan Contract should allow for early settlement

Originally, Ines requested for the ability to do "early settlement" for the loan request (e.g. after 5 years) as the cost of interest is very high

Early settlement by paying off the entire loan (i.e. clearing out all future loan tranches) is very easy. Just sum over all outstanding loan tranches and pay it off
Early settlement by waiving additional interest (i.e. paying on the principal on future loan tranches) requires us to have a PMT function to break down future loan tranches into principal, interest payments - and only pay off the outstanding principal amounts

For example

(early repayment by paying all outstanding loan tranches) at the 5 year mark in April 2026: Ines will pay total of $85,774
(early repayment by waiving additional interest): Ines will only pay 5 years worth of interest (I'd estimate around $72,000)

'Loan Sniping' Frontrunning issue.

As discussed.

I should be able to make it such that debt orders submitted to kernel revert if the "rightful lender" doesn't send it.

Create Paper + Balsamiq wireframes for frontend

Come up with first cut wireframes of frontend to drive product discussion + requirements

Research other loan smart contract implementations

Implement multiple payment methods (Wyre, Kyber)

Idea: Easy Crypto -> Stablecoins in-dapp

We can integrate Kyber network to have an in-dapp token converter such that lenders can convert Eth or ERC-20s into stablecoins using Kyber DEX.
I believe Airswap or 0x could offer similar functionality

Idea: Fiat -> Crypto onboarding

We could speak w/ Wyre protocol ("API for compilance and payments") about them handling KYC and fiat onramping for the product.

Consensys pitch deck

Social Attestation for loan request

Step 2B: Others can "attest" for the loan (i.e. use Bloom or 3Box-linked Ethereum accounts to support the loan)

Once Loan Request is created, others can "attest" for the loan through Bloom ID or 3Box linked accounts

Todos

Wireframes for social attestation @onggunhao
Set up Bloom ID attestation
@onggunhao Watch Bloom Workshop to understand starter kit

Ethereum-based data reading

The simplest approaches are web3 subscriptions in front end, and TheGraph.
I imagine we'll eventually want a service that handles making queries to data sources for each of our integrations.

Simple Social Staking (our code)

Simple web3 subscription in front-end and filtered events should be fine here

Bloom

However, the Bloom attestation events don't use indexed parameters 😬
They do have good event coverage, TheGraph would work

Crowdloan (our code)

We can design it to have good event coverage.

Adapt Crowdsale contract to use Dai ERC-20 token

Some previous discussion:

Reddit discussion on Dai crowdsale contract:
https://www.reddit.com/r/ethdev/comments/8iith6/what_would_a_crowdsale_raise_in_dai_look_like/

BlankDAO evidently did a crowdsale using Dai:
https://github.com/BlankDAO/smart-contracts/blob/master/contracts/BlankCrowdsale.sol

enabledao / enable Goto Github PK

enable's People

Contributors

Stargazers

Watchers

Forkers

enable's Issues

To dos:

Initial thoughts

Purpose

Functionality

Profiles API

Storage API

How we can use it

Walkthrough

Questions to 3Box team

Basic questions

Verified Accounts questions

Splunking

Deploy to Heroku

Things to KIV

Spec

Things to decide

Sample Loan Parameters

Sample Fee Parameters

Sample Amortization Table

Realistic do-up of sample loan:

Task

Why this is important

Proposal

We'll then have a simple call to action that leads to a Google Form. We'll ask:

Why

Todos

Definition of done

Resources (Stablecoin to Fiat redemption)

Why

lendoit

colendi

EthLend

r/borrow

What's upgradable

What's not upgradable:

Build Process

Pre-demo setup

Demo

Consideration: Data that currently isn't stored anywhere

High-level Spec

Deliverables

High-level spec

Fundraising period

Interim period (crowdsale complete, pending selection of funders)

Funding a loan

Funding goal complete

For example

Idea: Easy Crypto -> Stablecoins in-dapp

Idea: Fiat -> Crypto onboarding

Todos

Simple Social Staking (our code)

Bloom

Crowdloan (our code)

Recommend Projects

Recommend Topics

Recommend Org