🄷
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. 2. Understanding the NODES

2.2 How does sliding tax work?

Previous2.1 How does the Lottery system work?Next2.3 - How much does a node cost ?

Last updated 2 years ago

The sliding tax model functions in the following manner:

Time tiers: 0 - 6.9 days - 50% tax 7 - 13.9 days - 40% tax 14 - 20.9 days - 30% tax 21 - 27.9 days - 20% tax

28+ days (after 28 days is where each node tier is exposed to a different tax rate): BUKE - 5% tax MONONOFU - 8% tax MUSHA- 10% tax

You can view individual tax rates on each of your nodes within the Samurai dApp. When you click on ā€œCLAIM ALLā€, the relevant tax rates are applied to each of the node, it is not averaged.

e.g. If you have 2 nodes: Node #1 with 50% tax rate and Node #2 with 20% tax rate, the protocol will not take an average of 35% tax, rather it will apply 50% tax on Node #1's accumulated rewards and 20% tax on Node #2's rewards.

--

The sliding tax mechanism is a deviation from the previous fixed claims tax mechanism that the protocol previously relied on. All taxes (cashout fees) collected by the protocol are a part of the core team's allocation (see and for additional details about the protocol's smart contract functionality, tokenomics and the core team allocations)

section 1.3
section 1.10