As the final hours of the year approached, Hans hosted an technical AMA, answering a range of questions from the community covering transactions, core Apps and infrastructure of the App Layer.

An overview of all the questions and answers can be found below.

⚡️Temperature check

Q: How are you?

• A: Refreshed and mega pumped for what we’re going to do.

Q: What do the next four weeks look like?

• A: Lots of face-to-face work with key teams. Super exciting!

Q: How many people created Kujira, and how many are currently working on Rujira?

• A: Kujira was initially created by four people. Currently, there are about 20-30 people directly involved in Rujira’s development.
  

⚡️Fees and Transactions

Q: How will the cost of a market order on “RUJI Trade” differ when using Base Layer liquidity versus App Layer liquidity?

• A: It will depend on how the order is routed. The Base and App Layers will have independent fees, so split routing will result in proportional fee allocation.

Q: Will “RUJI Lending” collect fees from day one?

• A: RUJI Lending will collect fees as soon as it launches. It is expected to be compatible with THORChain’s affiliate framework, allowing affiliates to earn a share of loan opening fees for user referrals, similar to how they currently earn fees for swaps.

Q: Will it be possible to set gasless limit orders?

• A: Gas costs are being reviewed holistically, and achieving gasless limit orders is a design goal for high-frequency market-making, though it requires further consideration.

Q: Is memo-less transaction support possible?

• A: Memo-less transactions will need to be extended to support smart contract execution from Layer 1s. However, execution memos will receive encoding optimizations, such as simplified structures like “x:5:0” for depositing BTC into a lending vault.
  

⚡️RUJI Core Apps

Q: Will RUJI Pools have XYK Asset/Stable liquidity pairs like BTC/USDC, or will it mainly feature RUNE pairs?

• A (PM): Still TBC, but I see value in having XYK Asset/Stable pairs for long-term, downside-mitigated exposure to assets like BTC, without needing to manage profit-taking or timing the market. If we can route swaps efficiently across various pairs and liquidity sources, fragmentation won’t be an issue. LPs should be able to choose the strategy that works best for them. Forcing RUNE pairings isn’t ideal for either RUNE (pairing with underperforming assets creates a drag on RUNE price) or projects listing on RUJI Trade (being forced to  bear RUNE price risk is not good UX).
  
  In my view, RUNE Base Layer pools should focus on top assets (BTC, ETH, etc.) and stables for system stability. As more liquidity shifts to the App Layer, the Incentive Pendulum needs to account for that to ensure economic security scales accordingly. For Node Operators, liquidity on the App Layer should be more profitable with higher average swap fees (50% x (15bps taker fee + 7.5bps maker fee) = 11.25 bps per swap vs. Base Layer at 8 bps per swap).

Q: Will there be incentives for the initial pools? How does RUJI Pools liquidity interact with RUNE liquidity?

• A: Incentives will likely be available for the pools. RUJI Pools is intended for exotic market-making strategies and stable pairing, it complements existing RUNE liquidity and will increase markets depth for traders.

Q: Does that mean RUJI Pools is only for less liquid pairs, like EURe-USDC?

• A: No, RUJI Pools isn’t necessarily about less liquid pairs but focuses on different pricing strategies, such as oracle or stable-paired concentrated liquidity strategies, which should be more capital efficient vs. Base Layer xyk pools.

Q: How will RUJI Pool interact with RUJI Liquidation?

• A: RUJI Pools will act as a market maker on RUJI Liquidations. A custom strategy could place bids at a premium and will be able to tap into Base Layer liquidity. It will auto-arbitrage premiums against base liquidity and send profits to stakers.

Q: Will RUJI Liquidations support perp liquidations?

• A: RUJI Liquidations may support perpetual liquidations, though this would require changes to the standard Levana model.

Q: Could RUJI Liquidations handle liquidations on other chains using IBC?

• A: Initially, IBC will only be used to add new chains through THORChain’s existing rails, but lots of smart people are looking at the potential opportunities that IBC brings.

Q: Will IBC enable THORChain native assets to be sent to other chains?

• A: Exporting THORChain-native assets (e.g., secured BTC) over IBC will likely be a later phase.

Q: What tokens will be available to trade on Rujira?

• A: Any token available on THORChain will also be tradeable on Rujira. If a pool does not exist, tools will be provided to support the creation of new tokens and pools.
  
  Token whitelisting for apps like “RUJI Trade” or “RUJI Lending” will be permissioned (likely under Rujira team control initially), but Node Operators will also be able to update the contract properties, leveraging THORChain’s management features.

Q: How will stablecoins from different chains work in the order book?

• A: Stablecoins from different chains will have unique representations. Stable pools on the App Layer will support efficient swapping.

Q: How does App Layer liquidity impact Base Layer liquidity?

• A: App Layer liquidity creates arbitrage opportunities and allows swap routing between both layers.

Q: Will the features of RUJI Trade (e.g. crank-less operation, no front-running) be retained on Rujira?

• A: Yes, all these features will be retained.

Q: How will the $BTC lending mechanism work? Will it be possible to lend or use perpetuals with all THORChain-supported chains?

• A: BTC lending will involve signing transactions directly from a Bitcoin wallet. These features will be available for all currently connected and future connected chains.

Q: Will Rujira meet the requirements of large BTC holders for native BTC loans?

• A: The team has had promising conversations with key stakeholders. This is a significant focus area for development.

Q: When depositing BTC for lending, how is it secured? Is it essentially the same security as THORChain savers?

• A: Yes, the security is the same as THORChain savers. More info on how THORChain savers security works can be found here.
  

⚡️App Layer Infrastructure

Q: What wallets will be supported on Rujira and what will the default wallet for Rujira be? What will happen to Sonar Wallet?

• A: Rujira will support all wallets. Sonar Wallet will continue to exist as a mobile-native front end for Rujira, potentially with some exciting upgrades.

Q: How will single-sided LPing work? And how can the App Layer replace current savers?

• A: There are designs for a delta-neutral single-sided staking protocol that could help migration and offer similar properties to existing features. This is a work-in-progress for later in the year.

Q: Will there be a new block explorer?

• A: Work is ongoing with block explorer providers to extend functionality to the App Layer.

Q: Will Rujira have a tool to export transactions to CSV or an API for tracking cost basis?

• A: This will depend on the support provided by individual block scanners and finder providers.

Q: Are there plans for oracle orders on Rujira?

• A: Yes, oracle orders are planned. They will use on-chain TWAP pricing to offer pseudo-streaming swaps, arbitraged against Base Layer pools. Oracle orders can also be instantly consumed by a counterparty.

Q: How efficient will the connection between the App and Base Layers be for apps, especially for limit orders? E.g. in the context of a limit order, will the limit order execute against the entire liquidity pool on the Base Layer when price reaches the target price?

• A: Smart contracts on the App Layer function similarly to normal accounts on the Base Layer. The swaps are all queued and executed in endblock (i.e. not in the same part of the block that the tx is submitted). It makes atomic execution against Base Layer liquidity hard.
  
  However, oracle orders will enable continuous arbitrage and faster consumption by counterparties. We are working on ways to internalise that arbitrage profit, benefiting RUJI stakers.

Q: Will App Layer trading have MEV protection?

• A: Yes. Limit orders cannot be sandwiched, and CometBFT’s transaction ordering works differently than how Ethereum does it, it requires validator collusion to extract value, making MEV less of a concern.

Q: Will L2s be treated as independent chains on the App Layer, or will they be integrated into Ethereum?

• A: Check the upcoming Base integration. Ethereum L2s are equal to Ethereum in THORChain architecture, meaning they are treated as their own independent chain.

Q: What will a standard swap look like if you hold native BTC? Will it all happen in one app?

• A: It will all be done in one transaction. Aggregators will compute routes and offer either a direct Base Layer swap or an App Layer contract execution memo for routing through both layers simultaneously.

Q: Can Rujira functionality map to current Base Layer functionality (e.g., a spot limit order triggering a streaming swap)?

• A: Yes. Oracle orders can simulate this through arbitrage, and managed market orders can aggregate liquidity from both layers.

In an earlier Q&A we addressed some of the communities questions around the Merge. You can find an overview of that in this article

Still have questions after exploring all the details? Join our Discord for the technical questions, and our Telegram chat for everything else!