Understanding App Layer Security
Last updated
Last updated
The App Layer is designed with strict boundaries to ensure it does not introduce new risks to the Base Layer. Smart contracts on the App Layer are essentially “accounts with code” that are only permitted to perform MsgSend and MsgDeposit operations. They are sandboxed within a walled garden, with no special privileges that could compromise the Base Layer.
This setup ensures that the App Layer introduces no greater risk than a centralized entity holding a large amount of RUNE today. To further minimize risk, applications that might lead to significant RUNE accumulation will be avoided. Instead, the focus is on building apps centered around Secured Assets.
Additionally, THORChain’s governance mechanism (Mimirs) allows for fine-grained control: they can pause specific apps, all apps, or the minting/burning of Secured Assets if needed. Developers must go through a due diligence process to have their deployer address and smart contract bytecode whitelisted before deploying on Mainnet, adding another layer of security.
If there is a smart contract exploit on the App Layer leading to the misappropriation of secured assets, the loss is for each individual user that interacted with the malicious smart contract. This would obviously be a bad outcome, but it has no impact for the Base Layer, it’s just a change of ownership. The Base Layer would continue to neutrally process minting and redemptions of secured assets, as it is supposed to do, and would not assume any loss.
Note that Node Operators have the ability to pause smart contracts as shown above if such an issue was to happen and they wish to mitigate it.
A key concept around security is the separation of concerns between the Base Layer and App Layer. Smart contracts on the App Layer interact with the Base Layer the same way as any EOA, they can only do things that regular users can do.
What is the Mimir to stop minting/redeeming secured assets? HaltSecuredDeposit-{CHAIN} HaltSecuredWithdraw-{CHAIN}
What is the flow of redeeming secured assets and sending out the L1 outbound? Swap to an L1 address with the redemption memo.
How does secured asset accounting work? Is it held at App Layer or Base Layer? The accounting is held on the Base Layer. App Layer just gets to play with secured assets.
Can smart contracts mint secured assets? No. They can only use secured assets across the different contracts, but not mint (or burn) secured assets.
Are there TVL limits on the App Layer? Can secured asset balances grow larger than pools? This depends on the TVL Cap, which is an ongoing discussion in the THORChain community.
What happens if a protocol on the App Layer accrues bad debt? Bad debt would be assumed by the lenders in the Lending vaults. As long as the bad debt IOU is not in RUNE, then it has no impact for the Base Layer - we don't entertain releasing apps that will take excessive RUNE collateral.
What security measures are in place to prevent illicit actions in the mempool by MsgExecuteContract message? Messages are de-prioritised against all Base Layer messages so can't DoS MsgExecuteContract wraps MsgSend or MsgDeposit actions.
Will the Base Layer now need to consider each App Layer contract in its overall security posture? No - the Base Layer doesn't know that the App Layer exists, because apps can only do what EoAs can already do, and nothing extra.
Are there any risks App Layer products affecting Base Layer swap execution? No. All msgs are de-prioritised against Base Layer. Apps use the Base Layer to settle swaps.
What if there is an exploit and are all wiped? Any impact for the Base Layer? If an app gets hacked, it just means the hacker can withdraw the secured assets, not the original owners. It would take a Base Layer vulnerability to "mess with secured assets".
Why can swap against base-layer at 5-10bps rather than the mimir settings which results in 8bps at best and 31.9 bps at worst? The minimum swap rate for Secured Assets is defined by the mimir SecuredAssetSlipMinBps currently set at 5bps, same as Trade Assets (TradeAccountsSlipMinBps = 5bps). In practice, no user will be able to swap at those rates. To understand that, you need to understand how the App Layer is able to atomically tap into the Base Layer liquidity with its . The way this strategy works is that, for a given quantity of input token to swap, the AMM can estimate how many output token it would get if it was to execute a Base Layer swap, and then provide a quote for that quantity at Base Layer price + 2x SecuredAssetSlipMinBps + 15bps Taker Fee + 30bps Arbitrage Fee. You can think of the duo Arbitrage Fee + Taker Fee as an Affiliate Fee charged by traditional frontends, it’s economically the exact same thing for the end user, it’s just the mechanic for collecting those fees that is different.
What audits have been made on the integration of the App Layer? All apps deployed on Rujira have gone through rigorous internal testing and an external audit before release. You can find a collected overview of both contracts and audits in