Our DeVeFi R&D is funded by the Neutrinomic Foundation, a core contributor to the Neutrinite DAO.
What is a DeFi Vector?
Any canister that doesn’t require clients to send calls to it to process transactions and provide DeFi services. The canister should know what to do with the tokens when it receives them.
Why?
The current flow services use looks like this:
The frontend plays a major role and when errors occur we have to claim our tokens and restart the process. It uses 6 update calls and waits for their responses.
Most importantly when we attempt to use a DeFi service, we have to know the language it speaks - its interface. There are many types of services, such as order book dexes, AMMs, lending/borrowing, staking, etc. Each has its own language.
If we want to compose with these services to build something like this:
The first possible architecture is - An orchestrating service that knows the interfaces of each service it uses and talks to them using the existing flow.
Problems of that architecture - Everything is most probably in one canister - hard to audit and secure if it changes all the time. Developers have to add new services and that may take years. Interfaces change and it will break the flow. Getting a new service inside the orchestrator is not permissionless. The current flow allows for a lot of exceptions to occur we have to catch and handle.
There is another possible flow that doesn’t require us to know the language of each service to use it. The DeVeFi architecture is built on top of it. Simply it ‘subscribes’ to the ledger backlog and finds out if someone sent tokens to it in one of its subaccounts. These subaccounts are assigned to different vector nodes inside the canister and the service executes a predefined DeFi contract sending them ahead to their destination - another node or a wallet.
Benefits:
The biggest benefit of all is composability. To connect to a new service we have to create a vector node inside and configure it (usually with UI), using its custom interface. Then connect other services to it by setting it as a destination. The service that sends tokens to it doesn’t have to speak all possible service languages. We don’t require an orchestrator (While it’s possible to have one still). Someone creating a new DeFi service will be able to connect it to everything existing and build something more complex right away.
A vector node simply has multiple vectors inside which move tokens from source to destination based on the contract. The controllers of these vector nodes can change contract parameters and call actions while they are running.
Before things get complicated - here is a very simple vector node. One canister - one vector node.
When it receives tokens It will distribute them to multiple accounts.
DeVeFi is currently working and developers can build services/components and connect them using this protocol, but to have a UI builder, we will need to make an ICRC standard that facilitates the discovery, creation & configuration of vectors - ICRC55. There is a draft in the next repo and a node factory:
Advanced vector node factory. One canister - many vector nodes.
When it receives tokens it will periodically send them to a destination.
[devefi/example/basic.mo at main · Neutrinomic/devefi · GitHub]
Neutrinite’s exchange vector factory in production
[GitHub - Neutrinomic/defivectors]
UI here: https://vectors.icpcoins.com
Video demo of how it works: [https://www.youtube.com/watch?v=4rcROMDgDg4]
Mops packages:
devefi (makes connecting to multiple ledgers easier, uses devefi-*-ledgers)
devefi-icrc-ledger
devefi-icp-ledger
rechain - Redux like pattern + ICRC3 logs
DeFi WG repo with ICRC standards: GitHub - Neutrinomic/wg_defi
Discussions: DeFi WG (every tuesday) In Discord ICP Developer Community
Previous post: ICRC-55 DeFi Vectors
