Leverage Accounts

Alloc8 uses Gnosis Safe as credit accounts and deploys a new safe for the user for each asset and a collateral pair. These safe accounts are owned by the borrower and they can perform any kind of transactions available on the protocol. Using these credit accounts a borrower could take up a leveraged position and use those assets on the vaults available on the protocol to farm yield or points.

The safety of these accounts is maintained using a credit guard (SAFE GUARD), which limits the type of transactions a user could perform from these accounts and makes sure the borrower can't perform any malicious actions and move the debt funds to other EOAs or accounts.

As the Safe accounts are owned by the user, the protocol can't perform any kind of transactions on them and in case of liquidations that would have been a hurdle. So, to solve that we enable a liquidation module on the safe credit account at the time of deploying the safe. Using this Liquidation Module the protocol can withdraw funds from the vaults and liquidate the account when the health factor hits the threshold.

Credit Guard

The credit guard is a Safe guard implemented using the IGuard structure for Gnosis safe.

Safe Guards can make checks before and after a Safe transaction. The check before a transaction can programmatically check all the parameters of the respective transaction before execution. The check after a transaction is called at the end of the transaction execution and can be used to perform checks on the final state of the Safe.

This guard makes sure any transaction done by this safe is not malicious or tries to remove the guard or module. The credit guard also restricts the user's ability to perform transactions to our protocol and doesn't allow a new module to be added by the user.

Liquidation module

The Liquidation module is a Gnosis Safe module implemented on top of Safe Modules structure.

Safe Modules add custom features to Safe contracts. They are smart contracts that add functionality to Safe while separating module logic from Safe's core contracts. A basic Safe doesn't require any modules. Adding and removing a module requires confirmation from the configured threshold number of owners. Events are emitted whenever a module is added or removed and a module transaction succeeds or fails.

Our liquidation Module allows certain types of transactions to be executed, e.g. to liquidate the credit account or to remove funds from vaults at the time of liquidation. Transactions can only be performed from this module when the health factor reaches the threshold.