🄷
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. Articles / Announcements

The path towards sustainability

Mar 10, 2022

Aloha Samurais,

We hope that all of you are safe and sound during these unprecedented times.

Before delving into the scope of profound and meaningful features, changes and implementations that are approaching Samurai, it is vital to begin by shedding light on the history of the protocol and the rationale at its inception.

This protocol was launched as a fork (1:1 copy) of RING's, a DaaS protocol, which unfortunately failed. While the Samurai protocol never shared the DaaS approach, thesis and focus of RING, we were thrilled and excited for many of the mechanisms underpinning RING's codebase, which is one of the core reasons that led to the formation of Samurai.

However, soon after the inception of Samurai we encountered a series of unexpected issues stemming from the smart contracts being exploited. At the time, the pressure and urgency of the situation led to a number of decisions, which while being executed in best faith, have not been the most optimal and garnered poor results (reductive migrations, 1:1 token swaps, arbitrage debacles, and more…)

For an extensive amount of time, we have therefore heavily focused on trying to find solutions and ways towards fixing the situation, proving ourselves and presumably, overly focusing on making somewhat of a tangible comeback. At the same time, our reputation and credibility took a toll and hence seeking partnerships and cross-protocol integrations that could deliver additional utility and appeal to Samurai was not viable, which yet again led to us making efforts and new decisions that did not come to fruition later on.

The vast majority of our time was therefore heavily spent on finding ways and approaches to deliver the desired tangible comeback and in many ways the other, yet important components of maintaining the protocol were not given enough attention and focus.

Furthermore, when forking RING we made assumptions that most of the flaws and issues are a result of the team’s decision making and management. However, after establishing a more profound understanding of the protocol and its functionality over time, the deep flaws and imperfections of the overall model surfaced. It became apparent that the model is unsustainable and its long term prospects are fundamentally flawed.

This is a fundamental flaw that is coded and solidified in the protocol’s smart contracts but that we strive to change with the implementation of numerous, meaningful features and changes. The only solution towards long term sustainability is a deviation from RING’s underlying model and there are numerous paths that will be taken to attempt to address this:

1. Hybridising into a NaaS model

As you read this, we are rolling out RPC endpoints for all Samurai nodes. Although the enforcement of this may appear small or negligible, it is a big step for the protocol, as it effectively marks our transition into a hybridised model of NaaS (Nodes as a Service) and allows us to achieve several things. Firstly, it allows us as a protocol and its node holders to provide infrastructure solutions for different blockchain protocols (our RPC endpoints are compatible with Avax, Polygon and Fantom). This is attained by leveraging a proprietary system that aids in a number of aspects such as security, scalability, and reliability of data transactions. Furthermore, it allows us to tap into a new market of consumers that are interested in NaaS solutions and opportunities, effectively enhancing the exposure, visibility and accessibility of Samurai. Last but not least, the implementation of RPC endpoints enhances the overall utility of the protocol, as node owners can use the RPC endpoints of their nodes to execute transactions and no longer have to rely on the public, congested RPC endpoints.

2. Enhancing the utility of the token

It is essential to deliver new ways in which Samurai’s native token can be utilised. Our plan is to deliver and introduce a number of utilities over time, starting with a lottery system that utilises Samurai’s native token as its main medium of exchange. This ensures that a portion of the tokens collected by the introduction of the system will be directed towards the replenishment of reward pools.

3. Deconstructing the underlying unsustainable model

This is a meaningful step in building a functional protocol that deviates from RING’s underlying and unsustainable model.

Turning nodes into NFTs

  • All existing nodes will be turned into NFTs. This will enable the nodes to be transferable and tradeable. It will also enable a secondary market for the nodes to appear, effectively mitigating the previous system of ā€œsunk costsā€ when purchasing a node.

Introducing a node cap

  • A node cap/limit will be introduced, ensuring that there is a finite amount of nodes. This will inherently enhance the node scarcity.

Switching to a system of dynamic rewards

  • The nodes will issue rewards in a dynamic manner, based on the performance of the protocol. This ensures that the rewards issued are sustainable and that the protocol’s tokenomics are no longer threatened.

By introducing a node cap, this will effectively terminate the use of nodes as a liquidity mining program / substitute to staking, and will no longer allow new participants to enter.

The total deviation and pivot also require a change and refinement in how resources are utilised and allocated. Given, that the primary focus of the protocol will now revolve around building out an ecosystem of various utilities for its native token, the resources need to be appropriately re-allocated to enable, allow and fuel the corresponding development efforts and related undertaking.

These are significant changes that require a lot of amendments and effective development of new contracts from the ground up. While we have been actively working on a number of these aspects already, the development is heavily time-consuming. It is however our top priority to shift to this model as soon as possible and hence most of our time is spent on the development side of things for the time being.

Thank you for fighting with us!

PreviousClearing the air and moving onwards

Last updated 2 years ago