Ubiquity Credit

[0x4007]

I think we have a shot at making the crypto industry's first under collateralized credit program.

Normally you need to be over collateralized to borrow, but, we have two key points of leverage in our infrastructure that can make under collateralized credit work.

1. Contributor reputation: we can track a contributor's earnings over time and extend credit based on their monthly average earnings. For example, a user earns on average $5000 a month for the last three months, so they can borrow $5000 from us at X% APR if they need liquidity. Not sure what a good minimum threshold is but obviously the shorter the riskier. We could start a pilot with a whitelist of OG contributors first. We can consider only allowing card minting to disincentivize the use of leverage/trading with the funds.

2. Permits: wages are distributed through our system and could be used for automatic payback (or garnishing wages) which could help make financing easier to payback.

I think the biggest piece of advantage is the reputation system though. Contributors who have old GitHub profiles can be more inclined to pay back debts to continue using the system if they have an old GitHub profile and worked for a long time in the system.

[jordan-ae]

How can we mitigate the risk of losses for the lender in this scenarios? because there's not much collateral to cover the debt if the borrower defaults.

[sergfeldman]

Sounds like credit backed by reputation on GitHub. If so, most credit systems use credit scoring, on the basis of which the size and terms of the particular credit are determined.

Since a significant part of the activity on GitHub is public, it is possible to calculate the credit amount for each GitHub account in advance. Based on this, we can create a promo campaign engaging all active contributors on GitHub.

[rndquu]

From my observation, traditional banks (we’re talking about credits without any collateral, i.e. not about mortgages, etc...) allow credit limit up to 1/12 of all of your last year income.

Ideally Ubiquity Credit should be fully on-chain but we somehow need to get contributors’ income so there will be an off-chain component.

It could work this way:

1. Contributor calls credit() at our UbiquityCredit smart contract which emits a CreditRequest(contributorAddress) event
2. Some off-chain component sees this event and sends the amount of credit limit which contributor is available to borrow to the smart contract
3. Contributor borrows funds on-chain at some X% APR (USD year inflation rate + our interest?)
4. Contributor either transfers funds back to the smart contract directly every month either some part of generated permits is deducted in favour of credit redeeming

[0x4007]

allow credit limit up to 1/12 of all of your last year income.

We can take the monthly average income sampled over a year. That Seems fine especially if we already have that data in place before rolling out the credit program.

Ideally Ubiquity Credit should be fully on-chain but we somehow need to get contributors’ income so there will be an off-chain component.

This is a good aspirational goal. The best I can think of at this time is to write GitHub reputation on chain but it doesn't seem that useful unless GitHub goes down. I think it can be a later priority to figure out.

3. Contributor borrows funds on-chain at some X% APR (USD year inflation rate + our interest?)

Good point on considering inflation! I know that banks essentially get paid on risk. We can consider a dynamic APR calculation based on some risk parameters we still need to determine. Perhaps you can be eligible for better APR if you KYC, work at Ubiquity, have been working in the DevPool for longer, high portfolio balance of wallet from sites like zapper.xyz etc. it would be a useful exercise to list all of the possible risk parameters and rank them for this calculation.

4. Contributor either transfers funds back to the smart contract directly every month either some part of generated permits is deducted in favour of credit redeeming

I think there is room for innovation here to automatically handle micropayments back from their wages.

I'm not sure if this is too harsh, but I feel like it would be interesting to do a "linear vest" to stay current on the payments. For example, instead of operating on a monthly resolution ("your credit card bill is due on the 1st of the month!") we can make it a continuum and make the account automatically current (also known as a minimum payment) as soon as the next permit is generated. Essentially micropayments if the contributor is active.

We can then reset the minimum payment timer for another 30 days before the account is considered at risk.

Also we can start charging interest only on the balance that exists one month after the line of credit was initialized. As long as they make a minimum payment within any 30 days, their account remains current and accrues interest. If they are working regularly in the DevPool then this should be seamless for them.

An example of the "linear vest" calculation for minimum payments:

Scenario:

• 5000 Ubiquity Dollars borrowed
• payback schedule (one month by default?)
• user earns a permit after the first day, so 1/30 of 5000 = 166.67 auto minimum payment back, regardless of the permit amount if its enough.
• user earns another permit an hour later, so the auto minimum payment would be very small (166.67 * 1/24 = 6.95)
• user earns their next permit in a week
  • Linear "vest" through the month 8/30 of 5000 = 1333.33
  • Subtract payments made -(166.67 + 6.95) = $1,159.71 payment due
• etc until the balance is paid off.

Minimum Payment Amount

I realized that I made the calculations such that the "minimum payment" would pay the balance off in full after a month. This might need to be renamed to automatic full account payoff etc. but that means no profit gained for us if paid within a month.

I'm not sure how banks calculate minimum payments (is it aiming for 1 year payback time?)

RFC on min payment amount

[molecula451]

Ambitious idea, this feature can be launched primarily to core contributors and build up from there, the main idea of credit without collateral is trust, trust is a risk factor, in APR/APY terms the lending house alway plays in favor but this vary not by decision it also depends on the market fluctuaction in the sense of overcollateralize borrowerers pay lenders, but the entity here is Ubiquity, trusting it's borrowers

[sergfeldman]

It would be good to review the GitHub terms and policies to realize that this activity comply with the GitHub vision.

https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies

[0x4007]

It's fine.

To ensure compliance with GitHub’s Acceptable Use Policies, you should:

• Obtain explicit consent from contributors to use their GitHub data for credit assessment. • Ensure transparency in data usage and credit evaluation criteria. • Comply with all relevant financial regulations and data privacy laws. • Avoid excessive automated activity that could be perceived as spam. • Protect contributors’ personal information and comply with GitHub’s privacy policies. • Ensure that your system does not disrupt GitHub’s services or facilitate unauthorized access.

By adhering to these guidelines, you can minimize the risk of violating GitHub’s Acceptable Use Policies while implementing your credit-based feature.

[sergfeldman]

We should define how and what information about GitHub accounts we will collect.

I assume that we can get basic information on accounts using the GitHub API https://docs.github.com/en/rest/users

The criteria can be used to evaluate a GitHub account:

• Account age in years
• Number of contributions over the past few years
• Number of followers

Some criteria can be easily manipulated, so it is better not to use them

• Number of stars
• Number of repositories

[sergfeldman]

In the future, a smarter scoring system for GitHub accounts could be created to determine the credit size and terms.

One option is to evaluate the value of this account's contribution, as Tea plans for example https://tea.xyz/learn/proof-of-contribution

Another way could be to assess the social weight of an account. I don't know yet any examples on GitHub, but there is a good example with TwitterScore https://twitterscore.io/

As a fanciful idea, we can consider logic with guarantors. For example, an account that wants to receive a credit makes a PR to a special repository. His PR with the specified credit amount must be approved by several guarantors - other GitHub accounts. After approval of the guarantors, the account automatically receives the credit in the specified amount.

[sergfeldman]

Another example of the GitHub organizations assessment that can be applied to the users assessment. https://skynet.certik.com/

Overview of Skynet Github Monitoring This section includes essential metrics such as the GitHub repository link, GitHub age, GitHub followers, repository stars, commit history heatmap, and overall impact indicator, all aiming to show the transparency and current stage of project development. The Impact Indicator is a tailored feature that assesses a project’s significance in GitHub repositories. It examines factors such as followers, commit history, recent activity, stars, forks, and community engagement. Through analysis of various repositories across web3 projects, it presents an impact level that accurately reflects the project’s influence.

[0x4007]

Integrating Reloadly

I suppose that we are able to offer $1000 credit in the form of a prepaid card if the user has earned over $12000 annually in the DevPool program. The problem is that the loan amount isn't very flexible, in that if they take a $1000 loan, they have to get the $1000 from elsewhere to pay it back. They wouldn't be able to use a part of the balance, for example. Unless Reloadly has some type of drain function, to close a card and return the leftover funds.

Penalties

We can then reset the minimum payment timer for another 30 days before the account is considered at risk.

What are some enforcement actions we can take when the account is "at risk"? Some off hand:

1. Kernel garnishes wages of banned user.
2. APR is higher next time the user takes a loan (more risky.)
3. Kernel bans user from GitHub organizations it is added to.

Risk Mitigation

Maybe not the best idea, but just throwing it out there to spark more ideas. At this point, any money we can clawback is better than none. Perhaps we could whitelist a series of assets for the user to "allow" a clawback smart contract to transfer?

i.e. I am holding some WETH in my wallet and as sort of an "insurance policy" before taking out my loan, I allow the clawback contract to withdraw WETH just in case things go south.

[rndquu]

What are some enforcement actions we can take when the account is "at risk"?

Predict bad credit rate and increase APR for all of the users to cover possible credit losses.

[sergfeldman]

FYI https://app.ether.fi/cash

No need to offramp your crypto to use it. Load your ether.fi balance to spend, and earn Cash Points with every purchase! A real-life spending account that will allow you to borrow against and spend your ether.fi balance in the real world. Cash includes a mobile app MPC wallet that connects to your ether.fi account and a physical credit card that you can load with your balance. Earn Cash Points when you spend with your card!

[0x4007]

What are some enforcement actions we can take when the account is "at risk"?

Predict bad credit rate and increase APR for all of the users to cover possible credit losses.

Socializing losses is nice for us but it could upset the upstanding users. I certainly wouldn't appreciate being on the receiving end of that. But if the APR only fluctuates 0-2% in a year it's probably fine. Also ideally this should happen gradually.

---

I was thinking that we could offer credit after the first month. Example:

5k earned

Average against 11 other 0s (simulates a year)

Average annualized monthly earnings = $416.67 it is total credit line after the first month?

[rndquu]

Average annualized monthly earnings = $416.67 it is total credit line after the first month?

We really need someone with traditional bank experience for such kind of tasks. Traditional banks have more data to perform a person's credit scoring while we're limited only to a github account, solved issues and, perhaps, flow of funds on contributor's address.

The approach of "Average annualized monthly earnings = $416.67 it is total credit line after the first month" is good for v1 but ideally we should come up with smth more comprehensive.

P.S. Github / onchain credit scoring sounds like a new ubiquibot's plugin

[0x4007]

I can loop in @hpiyankov on a contract when there's more of this type of work that is required. He has plenty of relevant experience.

Traditional banks have more data to perform a person's credit scoring

Fundamentally the purpose of credit scoring, in the context of loans, is to develop a means to be able to quantify the likelihood that they will repay their loan. The less likely they are to pay their loan means the higher risk that they are, which translates to a higher fee (we are paid for risk.)

I think that underwriting could be feasible with on-chain analytics and the DeFi ecosystem. I hope that we can use APIs from the likes of Zapper or Arkham.

• Some ideas, but for example, if their net worth fluctuates too much on chain, perhaps we can consider them higher risk.
• If they have been liquidated, we can consider them higher risk.
• If they have enough liquid assets on chain to cover their entire loan, they can be considered lower risk.
• We can assign higher confidence based on the length of history on the wallet address.