Last year, @Larry introduced a model for a generalized credit protocol utilizing Mars’ lending market. Since then, a limited version of this design called Farm has launched and Mars V2 (the fulfillment of the original vision) is coming later this year.
With the experience we’ve had developing it up to this point, this writeup explores an alternative model that may allow us to scale Mars faster.
Current design of Rovers
The current Rover account model has two significant features:
- Account ownership as NFTs. When you create a new credit account (aka a new Rover), it mints a cw721 NFT and assigns your address as the owner.
- Account positions in Credit Manager. All info related to your deposits, borrows, vault positions, etc is stored within the credit manager contract.
As a consequence, all actions a user takes with their account must be done via the central Credit Manager contract.
The only actions that can be taken on an account outside of the Credit Manager are base cw721 actions (like transferring).
Up to this point, this has not been an issue given the limited integrations. But given a future with many more, this design may prove not to scale well.
Here’s an example. Concentrated Liquidity (CL) is launching on Osmosis. In order for Credit Manager to support leveraged CL positions, a number of things must be done:
1 - Risk Parameter modeling
The research team must do extensive risk modeling on each asset pair to determine the appropriate configs to use within the Credit Manager for a given position.
2 - Smart contract support
A) Every single smart contract message of the 3rd party service needs to be re-written in credit manager
B) Credit manager needs to keep track of which positions are owned by which credit account
3 - Frontend support
We must rebuild Osmosis frontend for interacting with the new feature. Besides the branding, this is largely redundant work.
Overall, any new 3rd party integration takes months of dev work. But, if we rethink the fundamentals of the current account model, we may be able to significantly speed this up via…
Account Abstraction 
DEFINITION: The use of smart contract wallets as opposed to externally-owned-accounts (EOAs).
What does this remind you of? 
… Ah yes! A Rover Credit Account.
However, currently, Rover’s are not nearly as flexible as something resembling a “smart contract wallet”. You can only run very few pre-defined, whitelisted actions through the Credit Manager contract.
But… what if we changed the categories?
Essentially, this transforms your credit account into a smart contract wallet. And with it, you can do anything a normal wallet could do:
- Transfer assets in/out
- Buy NFTs
- LP on Osmosis (any pool)
- Use any app on Osmosis
- and on…
…but how could a smart wallet allow a user to lever beyond the worth of their deposited assets? Couldn’t they just walk away with all the funds?
Here’s the current architecture:
Let’s take a look at the new architecture:
Leverage exceeding the worth of the wallet’s assets is only possible given the Credit Manager’s ability to continue asserting a healthy loan-to-value after each transaction.
The wallet can have many assets, but it’s only the ones that credit manager has assigned a max LTV to that count toward your health.
Also, we no longer care how they get these assets. Only the state of their wallet. We don’t even need to save position values in Credit Manager anymore. The bank module handles everything.
Further, because Rovers are smart contract wallets, they can give Credit Manager special access to liquidate any collateral in the event the account is unhealthy.
A smart-wallet model for credit accounts allows Credit Manager to deprecate ~50% of its smart contract code base. All of this can go without losing any functionality:
- Swapper
- Zapper
- Vaults
- Concentrated liquidity
- Lending/Reclaim
- Borrow/Repay
And removes the 75% of the smart contract work necessary for future 3rd party integrations and brand new chain deployments.
Let’s go back to our original example. Under the smart-wallet model, we’d only need to do:
- Risk modeling (i.e. get max LTV #'s for CL positions)
-
Smart contract work:
- Whitelist CL position in Credit Manager health checker
- Add pricing ability of CL positions to Oracle
- Implement CL position transfer functionality upon liquidation event
- Frontend work: Dependent on product direction (see below)
We’d really only be limited by our ability and speed with risk modeling assets and governance.
Changes to UX 
This is a pretty substantial change. Given this is a smart contract wallet, users cannot interact with it the same as they currently do (aka Keplr).
We’ll likely need to rely upon WalletConnect to serve as the way to route all wallet actions through their Rover account.
Further, when it comes to account abstraction, we should take inspiration from Gnosis Safe and how they serve as a layer on top of other protocols their users are interacting with.
The frontend strategy with the Account Abstraction design has a few options:
A) Read only positions
Mars site is the hub that links to all of the integrations (Osmosis, Apollo, etc) and it requires minimal frontend work of its own outside of displaying the positions + health of rovers.
B) Read + Write
Somewhat similar to the current Mars v2 roadmap. The Mars site is a “super app” where users can both see their positions and interact with them from a singular place. Much more frontend work, but possibly better experience for the user. With this direction, while the Mars smart contracts would no longer need to do heavy integration work, the frontend would still bear the burden of maintenance of integrating.
Open questions
- Can we make health checking faster as opposed to looping through entire asset whitelist?
- How do we handle Red Bank undercollateralized credit lines?
- How could we migrate these smart contract wallets practically given each account is a new instantiation?
- Are there unseen risks in this model?
- Instead of a cosmwasm contract, could Authz be an alternative way to enforce the same requirements? What are the pros/cons with this direction?