VIT is a private initiative to create an open-source competitor to TWINT. Our primary objective is straightforward: acquiring all the world.
The purpose of this project is to provide a simple and intuitive API for our VIT Wallet. This API facilitates spending, swapping, and lending, and is specifically designed for certain tokens such as XCHF, USDC, (BTC), and ETH (on the Optimism network).
The main feature provides also a solid solution to protect your Digital Identity with multiple strategies.
- select startup SDK (Thirdweb,StackUp,Biconomy,Pimlico)
-
account.create// ERC-4337 instance, plus recovery code, plus horcruxes- One-Time Use Codes, Two-Factor, Whitelist, Timespend, DeadDonation
-
account.recovery// Horcruxes + Guardians -
account.localEncrypt - [~]
account.TX(Time-Locked Transactions) -
account.TX(Reputation System) - [~]
account.TX(Custom Validation Logic) - [~]
account.paymaster: paymasters allow users to sponsor transactions or accept xCHF (ERC20 tokens) for gas payment.
- [~]
evm.transaction: Interact with the ETH network to sign/send/read/list transactions (TODO). - [~]
evm.paymaster: Interact with 4337 Account Abstraction (TODO). - [~]
transaction: high level api for transactions that include black/white-addresses.
-
core.identity: Manage and secure an identity associated with the device (DOING) -
core.AES: Simple AES encryption wrapper available natively on the browser. -
core.POW: Simple Proof-of-Work API. -
core.SSS: Shamir's Secret Sharing Wrapper. -
core.XOR: Shuffle operations to avoid clear content. -
core.entropy: API related to Mnemonics and seed. -
core.derivation: API related to key derivation.
-
aavePoolProviderAddress -
aavePoolProviderABI -
aaveContractAddress -
aaveTokenAddress -
rocketPoolContractAddress -
uniswapRouterAddress -
USDC_CONTRACT_ADDRESS -
RPL_CONTRACT_ADDRESS -
XCHF_CONTRACT_ADDRESS -
salt -
allowedTokens -
networks
-
tools.config: Secure configuration for the project. -
tools: Utilities (Secure Session Storage , Converters, ...).
-
defi.aave: Interact with the Aave protocol to lend USDC. -
defi.rocketpool: Interact with the Rocket Pool to stake ETH. -
defi.uniswap: Interact with Uniswap to swap XCHF <=> USDC.
- Use scam-database/blacklist for TX.validation
- Paymasters: Biconomy allows the use of Paymasters to sponsor transactions. Developers can implement custom logic in the Paymaster contract to validate transactions.
- Gas Tank: Biconomy’s Gas Tank mechanism ensures that users can pay transaction fees using ERC-20 tokens, adding an extra layer of security by abstracting gas payments.
- Rate Limiting: Implementing rate limiting can prevent abuse by limiting the number of transactions a user can perform in a given period.
- Monitoring and Alerts: Biconomy provides tools for monitoring transactions and setting up alerts for suspicious activities, enabling quick responses to potential security threats.
- Custom Validation Logic: StackUp’s Userop.js allows developers to define custom validation logic within their smart contracts to ensure transactions meet specific security criteria.
- EntryPoint Contract: The EntryPoint contract in StackUp verifies and executes UserOperations. Developers can customize the verification process to include additional security checks.
- Simulation: Before actual execution, transactions can be simulated to verify their validity. This helps in identifying and preventing potentially malicious transactions.
- Reputation System: StackUp supports implementing a reputation system to prioritize transactions from trusted sources while scrutinizing or rejecting those from untrusted sources.
- Two-Factor Authentication (2FA): Pimlico allows integrating 2FA within smart contract wallets. This requires users to provide an additional authentication factor before a transaction is approved.
- Multi-Signature Wallets: Pimlico supports multi-signature wallets, where multiple approvals are required to validate a transaction. This adds a layer of security by distributing control across multiple parties.
- Time-Locked Transactions: Implementing time-locked transactions ensures that a certain period must pass before a transaction is executed, providing a buffer to detect and prevent fraudulent activities.
- Recovery Mechanisms: Secure recovery mechanisms, such as social recovery or backup keys, ensure that users can regain access to their accounts and secure their transactions even if their primary keys are compromised.
Digital identity is a new reality, it appears complex or wird because we have no practice on that subject. The goal of VIT is to provide a few solutions to protect your identiy without the needs of a trusted thirdparties.
A Digital Identity is simply a 32-bytes large number, often represented as a mnemonic of 12/15/24 words (to facilitate human memorization of words instead of numbers). With this large number, you are able to generate an infinite number of Wallets and public identities.
Okay, but what it means for a day-to-day life? With this secret large number, you can generate multiple digital identities: one for cash transactions, one to collect funds for a birthday, some for social networks, some are publics, some are privates.
To achieve that goal, we built a simple and deterministic API as a frictionless solution to manage your own private mnemonic.
To increase the security of your identity, we break the Mnemonic phrase (the secret large number) into 3 separate pieces (called Horcruxes). You need at least two pieces to reconstitute your identity. You decide where you want to store each Horcrux. We recommend you keep them in separate places/locations. We provide a few alternatives (do not keep all of them on trusted third parties):
- One Horcrux is stored on the device.
- One or two Horcruxes are stored on printed paper and kept in separate places/locations.
- One is stored on our Vault SmartContract, a digital and secure place.
Before storing Horcruxes on your devices or on public ledgers, we use our API to protect the content.
- Secret-Leafs (A/B) are generated client-side with the preimage of a pseudo, password, and POW.
The POW element is the puzzle result of user sha256(username, password). It's a simple way to protect against DoS attacks.- The POW element is a PBKDF2 of username and password, it's a simple way to protect against DoS attacks.
- Users can also choose to store the pseudo/password form fields on a third-party service.
- Public-Leafs (A/B) are derivated images of Secret-Leafs (A/B), These values can be used for specific online features, such as storing a Horcrux in a public blockchain.
- Public-Leaf0 is the result of sha256(leaf1, leaf2). This publicKey (leaf0) will be used as address to store a Horcrux.
This how identity is used to prepare Horcruxes of our Identity.
We propose the usage of Shamir Shared Secret (SSS) to protect your Mnemonic without the problem of single point of security. We decide to use as source of SSS the entropy that produce the Mnemonic. Shamir split entropy in 3 separate pieces (called Horcruxes). Your need at least two pieces to reconstitute deterministicaly the same Mnemonic. We recomend you keep them in separate places/locations:
- Use printed paper.
- And use our Horcrux SmartContract. 👇
