🥷
Samurai Protocol
  • DISCLAIMER
  • Samurai Financial
  • 1. What is Samurai and how does it work ?
    • 1.1 - What is Samurai?
    • 1.2 - What is the total supply of HNR tokens ?
    • 1.3 - Now, how does it actually work ?
    • 1.4 - How does Samurai differ from RING?
    • 1.5 - Why is SAMURAI on the Fantom (FTM) ?
    • 1.6 - Is Metamask the only wallet compatible for now ? What about TrustWallet ?
    • 1.7 - Do I need to install a VPS?
    • 1.8 - Do I need to keep my computer running ?
    • 1.9 - Where can I see the size of the liquidity pool ?
    • 1.10 - Smart Contract Functionality
  • 2. Understanding the NODES
    • 2.1 How does the Lottery system work?
    • 2.2 How does sliding tax work?
    • 2.3 - How much does a node cost ?
    • 2.4 - Can nodes be transferred from one wallet to another ?
    • 2.5 - Are these real nodes ?
    • 2.6 - Why do you call these "nodes" ?
    • 2.7 - I don’t see my rewards every 4 or 8 hours. Is there a problem ?
    • 2.8 - What happens if I don't claim my rewards every time ?
  • Tokenomics
  • Governance
  • Samurai AI
  • Vaults
  • MultiChain ZenGarden
  • Levels
  • Sambot
  • ZenEstate
  • Governance Proposals
    • Samurai Governance
    • Initiate and adopt protocol level governance
    • SIP-1: Adopt and enforce an incentivised LP staking mechanism - Zen Garden
  • [EXTENSION] SIP-1: Adopt and enforce an incentivised LP staking mechanism - Zen Garden
  • SIP-2: Implement a Samurai native OTC NFT solution
  • [EXTENSION] SIP-2: Implement a Samurai native OTC NFT solution
  • SIP-3: Implement, adopt and enforce Samurai Vaults
  • SIP-4: Implement, adopt and enforce Samurai Multichain ZenGarden
  • SIP-5: Implement, adopt and enforce Samurai Levels
  • SIP-6: Replenish Samurai Levels rewards
  • SIP-7: Conduct an OTC NFT acquisition event
  • SIP-8: Retroactive funding
  • SIP-9: Expand MultiChain ZenGarden
  • SIP-10: Conduct an OTC NFT distribution event
  • SIP-11: Temporarily pause Samurai Levels
  • SIP-12: Replenish Samurai Node NFT's rewards
  • SIP-13: Levels v2 Product feature set Ideation
  • SIP-14: Deploy and fund Samurai Governance Vault
  • SIP-15: Implement, adopt and enforce Samurai Levels v2
  • SIP-16: Conduct ‘Settlement & Release’ initiative
  • SIP-17: Expand ‘Settlement & Release’ initiative
  • SIP-18: Implement, adopt and enforce an update to Samurai Node NFT RPC Endpoints
  • SIP-19: Implement, adopt and enforce Samurai Chat
  • SIP-20: Refine Samurai Levels Parameters and Conditions
  • SIP-21: Retroactive funding 2.0
  • SIP-22: Conduct an OTC NFT acquisition event
  • SIP-23: Conduct an OTC NFT distribution event
  • SIP-24: Enact a Samurai Governance Vault Conversion
  • SIP-25: Refine Samurai Chat Parameters
  • SIP-26: Replenish Samurai Levels v2 rewards
  • Articles / Announcements
    • Samurai is here!
    • Honour
    • News, updates, migration and plans for Honour
    • Clearing the air and moving onwards
    • The path towards sustainability
Powered by GitBook
On this page
  1. 1. What is Samurai and how does it work ?

1.10 - Smart Contract Functionality

Previous1.9 - Where can I see the size of the liquidity pool ?Next2. Understanding the NODES

Last updated 2 years ago

Please keep in mind that this smart contract functionality is no longer current, as node creations and their effective use as a liquidity mining program have been capped (stopped). It is no longer possible to create new nodes.

Nodes can be only bought, sold and traded on the tofuNFT marketplace.

--

There are 2 main Samurai owned addresses to consider: FutureUsePool and DistributionPool.

This is how the Node Creation algorithm works, line by line.

The contract effectively conducts the following:

  1. Check the input parameters to ensure that the wallet buying a node is not blacklisted, is not a zero address, is not a FutureUsePool or DistributionPool, and that the wallet has enough balance to buy the node at the stated price. Furthermore, the node name is validated and checked for node name length.

  2. Check whether the contract contains enough of KTNA tokens to engage in a DEX swapping operation, and if swapping is enabled. It also ensures that the transaction sender is not an owner, and that the address invoking the creation operation is not an AMM pair contract. If all these conditions pass, the contract will engage in a swapping operation and then follows step 3, or else the contract will skip the swapping operation and just passes through to step 3.

  3. Lastly, after the initial 2 steps, the contract will transfer an amount of KTNA tokens equivalent to the Node Price out of the wallet, which has called the transaction, and the said tokens will arrive to the contract address. After this step, the node is finally created for the respective wallet.

The Swapping Operation

The following fee structure is used to determine the amount that will be swapped:

FutureFee: 2%

LiquidityPoolFee: 10%

RewardsFee: 60%

RwSwap: 30%

These keywords will be reused to describe how the swapping operation works.

We are also assuming that the swapping threshold for the contract to engage in the operation is 100 KTNA and “swapLiquify” is enabled. That is, if the contract Samurai contains 100 KTNA tokens at the moment, and wallet A invokes a “createNodeWithTokens” function, the contract will engage in the swapping operation as part of the function processing.

This is the algorithm procedure given 100 initial KTNA tokens:

  1. Set “swapping” state to true (to lock the process and prevent re-entrancy)

  2. Swap 2 KTNA tokens and send them to FutureUsePool. This is using FutureFee rate of 2%.

  3. Calculate rewards tokens to swap, by firstly calculating the rewards pool tokens amount. This is 60 KTNA (rewardsPoolTokens) and 18 KTNA (rewardsTokensToSwap). It is 18 KTNA, because we are taking 30% out of the 60 KTNA tokens.

  4. Swap 18 KTNA tokens and send them to DistributionPool. This is using the RewardsFee rate of 60% and RwSwap fee rate of 30% in conjunction to calculate this fee of 18%.

  5. Transfer 42 KTNA tokens (60 minus 18) from the contract address to the DistributionPool. Note, these tokens are NOT being swapped, just transferred to refill the distribution pool.

  6. Swap 10 KTNA tokens and refill the liquidity pool on SpookySwap. These tokens are therefore given back to the DEX. This is using the LiquidityPool fee rate of 10%.

  7. Swap the remaining 28 KTNA tokens into FTM and leave them on the contract address.

  8. Set the swapping state to false and conclude the swapping operation.

The payees/shareholders (the core team) can then withdraw the amount of FTM, which has been swapped from the final 28 KTNA tokens, from the contract address into the designated wallets. All the fees collected by the aforementioned pools and the funds that are directed to the payee wallet addresses represent the allocation of the core team (as outlined in the tokenomics section - 1.3).

The total amount of percentage of inital KTNA tokens, that is swapped to FTM and then kept within the wallets is therefore:

2 (FutureFee) + 18 (RewardsFee * RwSwap) + 28 (Remaining amount of final tokens) = 48%

10% is used to automatically refill the DEX pool, and 42% of KTNA is used to refill the distribution pool to redistribute KTNA further.

All the fees collected by the Shareholders, FuturePool, DistributionPoolSwap pools and the funds that are directed to the payee wallet addresses represent the allocation of the core team (48% total as outlined in the tokenomics section - 1.3).