SIP-4: Implement, adopt and enforce Samurai Multichain ZenGarden


This proposal suggests for the protocol to adopt and enforce a set of smart contracts (specified below) that enable, facilitate and provide access to a feature of the Samurai protocol, called “Samurai Multichain ZenGarden”.

ZenGarden is a functional smart contract already approved by the governance and deployed on the native liquidity pool of the Samurai protocol (FTM/xHNR):

The Samurai protocol remains to operate on the Fantom chain due to its strong technical scope that is well-suited for the protocol’s functionality and as it enables Samurai to be positioned in a manner, where interaction with other protocols, dApps and Fantom-based projects is natively easy, convenient and accessible.

However, further expansion onto other blockchains could significantly enhance and increase the amount of protocols that the Samurai protocol is able to interact with and could be a meaningful tool in bolstering the protocol’s user growth, enhancing the protocol’s compatibility and further improving its utility.

Samurai Multichain ZenGarden would effectively deliver the functionality of the already deployed ZenGarden smart contracts, which incentivise and reward LP staking with xHNR token emissions, among the liquidity pools of different protocols, across different blockchains, with the use of a wrapped xHNR token (wxHNR - see specification below).

It would allow the Samurai protocol to interact with well-established protocols across numerous blockchains by integration and incentivisation of LP staking of their liquidity pools and native token pairs. Liquidity providers to a number of such protocols would thus be meaningfully incentivised to stake their LP tokens, using Samurai’s ZenGarden and would be in turn rewarded by receiving xHNR governance tokens.

This could potentially achieve further decentralization and growth of Samurai’s protocol governance, by effectively spreading and distributing the xHNR governance tokens among new holders and appealing to potentially new governance participants / contributors.

The blockchains and DeFi protocols targeted for the proposed incentive deployment of Samurai Multichain ZenGarden have been selected according to parameters pertaining to their technical specification, user base, TVL and credibility.

Samurai Multichain ZenGarden shall be deployed on the following blockchains:


Site: Current TVL: $23.98B

Binance Smart Chain

Site: Current TVL: $4.42B


Site: Current TVL: $835.9M


Site: Current TVL: $1.04B

The protocols and incentivised LP pools shall include the following:


Protocol site: Incentivised pool:


Protocol site: Incentivised pool:


Protocol site: Incentivised pool:

Aave: Aave / wETH [POLYGON]

Protocol site: Incentivised pool:

5 000 000 wxHNR tokens shall be minted on each of the specified blockchains and provided for the purposes of incentivising each of the proposed liquidity pools through ZenGarden’s LP Staking.

Overall, 20 000 000 xHNR tokens shall be minted on the Fantom blockchain in total for the purposes of Samurai Multichain ZenGarden. The tokens shall be utilised until the depletion of the proposed allocation, which is assumed to be approximately 365 days from its deployment. The reward issuance shall be represented on Samurai’s frontend in a simplified, understandable and non-deceptive manner - rather than providing a % APY return representation, the frontend shall display the potential returns in concrete, discrete xHNR token terms.


Samurai Multichain is a set of smart contracts to enable the already established Samurai ZenGarden Staking mechanism to take place on other chains.

The Multichain set of smart contracts comprises of the following:

  1. The existing ZenGarden contract

  2. The new Wrapped xHNR token

  3. The Samurai Multichain Receiver

  4. The Samurai Multichain Sender

The ZenGarden contract facilitates the staking mechanism on other opposing chains such as BSC, MATIC, AVAX, and ETH. By staking selected LP tokens, the ZenGarden smart contracts will emit Wrapped xHNR tokens (wxHNR) as a form of proof.

The wxHNR is a non-tradeable token which has no other purpose besides serving as a receipt proof of rewards. There will be no liquidity pools established by the protocol on any of the hosted opposing chains.

Very much like the current ZenGarden smart contract(s), once the user decides to withdraw from or deposit to the staking pool, the accumulated rewards in terms of wxHNR are issued back to the user.

In order to convert wxHNR (on any chain) to xHNR (on Fantom), the Multichain set of smart contracts will help to facilitate this conversion by leveraging the best of both worlds of web2 and web3 technologies. On each chain, a Samurai Multichain Receiver contract will be deployed to allow the users to deposit their wxHNR. After the deposit, an event is emitted to notify Samurai’s backend services to trigger an action on the Fantom chain to send the equivalent amount of xHNR tokens on the Fantom blockchain, to the depositor using the Samurai Multichain Sender.

This observation is cyclical and can either range from being triggered immediately to being expected to be completed within 12 hours. Special circumstances may apply, should the service be congested by heavy traffic of requests in which the expectation may exceed more than 24 hours.

In order to facilitate such mechanism, the aforementioned amount of 20 000 000 xHNR tokens shall be minted and deposited to the Samurai Multichain Sender, and to the proposed ZenGarden staking contracts on the specified opposing chains.


Smart Contract risk

One of the biggest risks when it comes to liquidity pools is smart contract risk. This is the risk that the smart contract that governs the pool or the ZenGarden smart contracts deployed on any of the blockchains can be potentially exploited by hackers. If exploiers/hackers are able to find a bug in the smart contract, they can theoretically drain the liquidity pool of all its assets. For instance, a hacker could borrow a large number of tokens by taking a flash loan and execute a series of transactions that would eventually result in the funds draining.

Impermanent loss

Impermanent loss is the most common type of risk for liquidity providers. It occurs when the price of the underlying asset in the pool fluctuates up or down. When this happens, the value of the pool's tokens will also fluctuate. If the price of the underlying asset decreases, then the value of the pool's tokens will also decrease. The reason this is considered a risk is that there is always the potential that the price of the underlying asset could decrease and never recover. If this happens, then the liquidity provider would experience a loss. An impermanent loss could also occur when the price of the asset increases greatly. This causes the users to buy from the liquidity pool at a price lower than that of the market and sell elsewhere. If the user exits the liquidity pool when the price deviation is large, then the impermanent loss will be “booked” and is therefore permanent. Liquidity pools with assets of low volatility such as stablecoins experience the least impermanent loss.

High slippage due to low liquidity

Another risk to consider is low liquidity. If a pool doesn't have enough liquidity, it could experience high slippage when trades are executed. What this essentially means is that the price difference between the performed transaction and the executed trade is large. This is because when the liquidity pool is small, even a small trade greatly alters the proportion of assets.

Frontrunning transactions

Another common risk is frontrunning. This occurs when a user tries to buy or sell an asset at the same time that another user is executing a trade. The first user is able to buy the asset before the second user, and then sell it back to them at a higher price. This allows the first user to earn a profit at the expense of the second user. This is mainly seen on networks with slow throughput and pools with low liquidity (due to slippage).

The proposed Solidity code / smart contracts




Last updated