-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Verida "bank" smart contract #29
Comments
Feedback:
Next steps:
|
@pranavburnwal suggests using OpenZeppelin contracts, that leverage vesting and think if of this as a "virtual" (ERC1155) contract that is for DID's not blockchain wallets. |
Accounts will charge the credits using addCredit() or removeCredit() function as in the |
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/escrow/Escrow.sol @tahpot These are the contracts I was mentioning about. Lets see how we can use to build this. cc @ITStar10 |
Background context
We currently have multiple smart contracts in our network architecture require users to "bond" or "lock" tokens:
The service registry currently implements
addCredit()
andremoveCredit()
methods that support depositing VDA tokens that can then be used transfer VDA tokens between users based on the service infrastructure each account uses.In the future, the
interactions registry
and thetrust registry
will require similar functionality.We require a separate
vda bank
smart contract that provides a common way to "lock" tokens in the Verida network, that can then be moved around by any of our Verida smart contracts. It acts like a Verida bank where each smart contract can lock, unlock or transfer tokens in this common deposit contract.This will also allow for a simpler user experience because a user can lookup at the
vda bank
smart contract and see how many of their tokens are locked by different verida smart contracts, how much credit they have and where their tokens are being spent across the Verida network.This also provides the best way to allow VDA community token holders to support the network (via gasless transaction payments) while also receiving a return for their staking.
User stories
TBA
Methods
TBA
Phase 1
For phase 1, we only require the necessary functionality to support the service registry.
This is likely:
addCredit()
removeCredit()
lockCredit()
unlockCredit()
transferCredit()
availableCredit()
The text was updated successfully, but these errors were encountered: