This article gives a high-level overview of a possible architecture for a potential future iteration of Mars protocol. For more general background on our ideas for Mars protocol after “Terra Classic”, see here. Please carefully review the disclaimers at the end of the article.
Mars lending markets will be deployed to various chains in the form of CosmWasm smart contracts. Each deployment, known as a satellite market, will be a self-contained lending protocol that is fully functional within its own chain.
The specific technical details of each satellite market will vary based on the characteristics of the chain it is deployed on, but they will likely each consist of the following contracts:
||the asset pool|
||asset price feed; the source of the data should be based on whatever makes the most sense for that chain|
||fungible token representing a user’s deposited assets, i.e. their borrowing power|
||a contract that collects protocol revenue, and forwards it to Mars Hub to be distributed to stakers|
Mars Hub acts as a “command center” sitting between satellite markets, allocates resources across them, and exercises governance powers.
MARS token holders earn governance power by staking their tokens in Mars Hub’s L1 staking module. The L1 governance will take the owner/admin role of the satellite market contracts via interchain account. MARS stakers will vote on issues such as new contract deployments, asset listings, risk parameter adjustments, and the allocation of incentives using the Keplr wallet UI, similar to how they currently do with other major Cosmos chains. In return, MARS stakers receive protocol revenues collected by each satellite market’s FeeCollector contract.
At the core of Mars Hub is the allocator module. At regular intervals (e.g. every 10 minutes), the allocator module will fetch data from each satellite market, including the deposited and borrowed amounts of each listed asset, via interchain query:
The allocator module then computes an optimal asset allocation that will result in the same interest rate for each asset across all satellite markets; it then executes the allocation, sending instructions to each satellite market to move the assets accordingly. This process is known as market synchronization, which, essentially, merges the satellite markets into a global liquidity pool serving all chains.
In the example below, we assume a hypothetical Juno market has an excess of ATOM, while the Osmosis market has a shortage. Mars allocator will instruct the Juno contract to transfer an appropriate amount of ATOM to the Osmosis contract. In this case, the Juno market will utilize Cosmos Hub’s multi-hop transfer feature to execute the transfer.
A more advanced feature this architecture can potentially enable that is (in our knowledge) not seen in any other lending protocol is interchain collateralization: deposit collaterals on one chain, and borrow against it on another.
Consider a user who deposits OSMO in the Osmosis market, and wishes to borrow JUNO against it in a hypothetical Juno market. This can be achieved simply by transferring the user’s maOSMO tokens from Osmosis to Juno.
The design for Mars Hub contemplated herein is very ambitious. It depends on many cutting-edge technologies (interchain account, interchain query, multi-hop routing…), a robust IBC relayer infrastructure, and needs to consider all sorts of antagonistic situations (e.g. relayers going offline for extended periods of time) in the protocol design. It is subject to many uncertainties, including the continued willingness and ability of technically competent persons to contribute code to Mars protocol.
Thus, if something resembling this vision is to be realized, Mars Hub should be developed incrementally. First, Mars Hub can launch as a barebone chain, with the MARS token, core modules (e.g. governance, staking, reward distribution, etc.), and IBC connections to several major Cosmos chains so that the MARS token can circulate. This can serve as the foundation for any future Mars protocol development along the more ambitious lines set forth herein.
Please be advised: This article sets forth speculation regarding a possible design of a potential future derivation and deployment of ‘Mars protocol’ and the creation of new MARS tokens. There is no guarantee or promise being made, or duty or obligation being assumed, or right being created or conferred hereby, and no contract or agreement is implied. There is no guarantee or assurance that new Mars software will be created or deployed, or that any Mars software which is created or deployed will adhere to the design or have all of the features described herein.
If Mars software is created or deployed, this article does not constitute a representation, warranty or guaranty as to how that software will function or the outcomes to be produced by that software. This article is not an offer or solicitation to purchase or otherwise acquire MARS tokens, and does not constitute investment or other advice.
Mars protocol is open-source software, and the Mars branding is licensed under creative commons. Accordingly, no single person or group controls what forks or derivations of Mars protocol may be created in the future. There is no specific entity or entities that have promised or committed to develop the software described herein, and you should not have any expectation of continued software development or governance on the part of any specific person or persons.
Do not make any financial decisions based on this article.
This article is further qualified by, and subject to, the Mars Disclaimers.