A DeFi Vector has a source address and a destination address.
The source address is controlled by the vector agent (canister).
The destination address can be anywhere and doesn’t have to be controlled by the agent.
Vectors are first set up inside the agent and then used simply by sending tokens to their source address. No other communication is required for them to move tokens to the destination.
They are automatic agents using heartbeats or timers.
The client can send multiple transactions to the source address over a long period of time.
This makes them perfect for usage by developers and DAOs for dApp tokenization. Integrating them takes sending one icrc1_transfer and since there are no additional interfaces for their primary operation, nothing can break.
These could be a fundamental building block when creating dApps that speeds up development and results in bullet proof tokenization.
A simple visualization of DeFi Vectors and the reason they were named vectors.
Vector within one ledger
Such vectors can send tokens from A to B on a schedule - scheduler agent. Or be a splitter agent - sending tokens to different addresses. It’s possible to also have neurons as sources and targets.
The destination of agent A can be the source of agent B
Vector between two ledgers on the IC
These are exchange vectors and any DEX can provide services with its own vector agent.
Vector crossing different networks
Vectors within one agent can share sources
Vector agents on the IC can work with sources and destinations in other chains thanks to t-ecdsa.
Example - serve as tokenization engine for Bitcoin inscriptions.
When it comes to IC tokens, vectors communicate between each other and clients through the ledger. Using ICRC-1, ICRC-4 to send transactions and ICRC-3 to follow the transaction log. They don’t have to wait for a callback when sending transactions (oneway calls).
This requires the client to setup their vectors with the agent. Ideally vector agents will be permanent, audited and black-holed or DAO controlled.
There is one exception - withdrawing from the source in cases when the agent fails to move tokens to the destination (Ex: an exchange vector agent couldn’t satisfy a target rate for a long time). This one takes a call to the agent. It’s possible to not have it - for example the agent sends automatically tokens back to an address if it fails.
Vectors work very well with the new messaging model.
Interfaces for different vector agents can be standardized with icrc extensions.
DeFi WG GitHub - Neutrinomic/wg_defi
Next meeting: 6th Feb. 4pm CET