# JIJI

## Credit contract execution for USN

SoApp -> NEAR: deploy contract
SoApp -> Borrower: set allowance for delegated transfer
note left of SoApp: once per month with USN
SoApp -> Borrower: delegate transfer tokens to merchant

## Wallet setup for new users

User -> SoApp Backend: sign up
SoApp Backend -> SoApp Blockchain: create wallet
SoApp Blockchain -> SoApp Blockchain: generate implicit account

# non-USN payments

We cannot make automatic withdrawals from user's wallet in onther tokens, in that case we will push user to make the payment manually or won't support tokens other then USN

# open questions

1. what if user doesn't have any USN or NEAR should we allow them jut to fulfill the credit form bank card? - YES
2. should we focus on those users who don't have NEAR and NEAR wallet but want to pay in crypto? - YES, we should create wallet for them

3. USN team want to make gas-free transactions or transaction will be paid in USN, is it a blocker for Jiji or not. - NO

4. do we want to support other tokens then USN (eg. USDT, USDC) - YES, potentially but only with USN we can allow delegated transfers

# considerations

1. NEAR token is volatile, so the proposition is to accept only stable coins for payments

# credit request approval flow

Borrower-> SoApp: create credit request
SoApp -> SoApp: score borrower
note left of SoApp: if decision is "approved"
SoApp -> Merchant: settle payment in USN for SoApp wallet
SoApp -> Borrower: set allowance for USN for value of credit

# credit payment flow

note left of SoApp: once per month
SoApp->Borrower: transfer USN from borrower wallet with allowance to SoApp wallet
note left of Borrower: if not enough balance
SoApp->Borrower: charge credit card
note left of SoApp: once per N days
SoApp->SoApp: automatic clearing FIAT<>USN

# Staking of USN

SoApp will hold USN on the balance and this USN can be put into Lending or Staking protocols to generate around 10% APY

This APY can be used to pay for transactions fees or can be reduced from credit fees to make credits cheaper

# Use cases diagram


# Development Plan

1. Website with user account development
2. Delegated transfers with USN
3. Gasless transactions with USN
4. Wallets generation in SoApp for borrowers
5. Probability of default backend intgration
6. Transaction settlement from wallet to merchants
7. Acuiring integration

# Appenix: Points from Illia about delegated transfers

Illia Polosukhin

1. Token -- preferably a standard, chain-wide recognized stabletoken should be used, which is also fully supported in other wallets and explorers
2. User Account -- there should be a notion of a user account that can hold the Token. The User Account should allow for full self-custody Token operations like receiving from and transfering to other User Accounts, as well as to other users of the blockchain
3. User Account should preferably be a standard account for the blockchain, so that given a private key, a user can gain free access to Token operations using any standard wallet software
4. Card Authority is a special account controlled by our system, which performs necessary operations backing up card transactions
5. A User Account should be able to delegate access to Card Authority for a limited Token amount. Access should also be revokable.
6. The Card Authority should be able at its own discretion to perform a Token transfer from a User Account that specifically provided delegated access, towards a certain other account (vault), up to a limited amount set by delegation process, without the User Account approving this specific transfer operation. This is the Delegated Transfer
7. Alternatively and preferably, the operation described in [6] could be an operation taking a hold of the Token on User Account, so that the user can no longer freely transfer the specific amount (freezed amount), with the Card Authority being able to later capture the freezed amount and transfer to its vault account
8. Delegated Transfer duration is the time duration that starts with Card Authority service starting the delegated transfer or freeze [6 or 7] and ends with Card Authority having a solid proof of this operation is finalized / irreversible, by performing necessary network requests using HTTP polling, or a WebSocket connection, or other similar means
10. The Delegated Transfer duration should have a predictable distribution and ideally consistently fall under 2-2.5 seconds

## What about USN?

1. USN would be the best here

2/3. These are just regular accounts, are they not?

4/5. Instead of an account Card Authority this can be a specific private+public key pair, where the public key is added to user accounts to gain limited access

7. Why do you prefer freezing/transfer vs just transfer?

8/9. One option to optimize time in general with specifically USN, and add ability to delegate/transfer on behalf of user direclty to the token contract. Given it may become a pretty useful primitive for USN it's worth considering with their team.

What do you think of 8/9 I responded? if we add an ability to create delegations - it may be a very nice way to allow people and apps to "pull" funds from accounts of others

# Sub-account creating diagram


[Example of account creation with nodejs](https://gist.github.com/Shockedshodan/aade19b1319ed69e57cf341309c4a9ef)