🥷
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
  • Motivation
  • Specification
  • The proposed Solidity code / smart contracts

SIP-17: Expand ‘Settlement & Release’ initiative

PreviousSIP-16: Conduct ‘Settlement & Release’ initiativeNextSIP-18: Implement, adopt and enforce an update to Samurai Node NFT RPC Endpoints

Last updated 5 months ago

Motivation

This proposal suggests for the protocol to expand the existing ‘Settlement & Release” initiative (). The assumption underlying the proposal and the thesis behind the expansion of the “Settlement & Release” initiative is that it shall effectively allow and enable the protocol to operate more efficiently in the context of the dynamically, rapidly and continuously evolving regulatory landscape while employing a reasonable and considerate approach towards its users.

In the context of the continuous efforts to ensure that the protocol operates in compliance with its established policies and Terms of Service and the constituent frontend geolocation-based restrictions and blockers, this proposal shall only be applicable and eligible to previously undetected protocol users from restricted areas with negative Redeemable Amounts (which were determined based on the trades, engagement, and interactions of the users with the protocol’s products and services).

The existing list of restricted areas (Burma / Myanmar, Cuba, Iran, Sudan, Syria, the Western Balkans, Belarus, Canada, Côte d'Ivoire, Democratic Republic of the Congo, Iraq, Lebanon, Liberia, Libya, Netherlands, North Korea, Russia, United Arab Emirates, United States, certain sanctioned areas of Ukraine, Somalia, Venezuela, Yemen, or Zimbabwe) shall be expanded and additionally include the following: United Kingdom, Hong Kong, China, Saudi Arabia, Qatar, and Singapore.

The eligible users shall be able to claim an FTM equivalent of the “Redeemable Amount” specifically computed for their wallet(s).

The Redeemable Amount shall be computed utilising the following methodology and rationale: Firstly, the list of Node holders shall be collected. The list shall not resort to a simple solution of taking into account the current snapshot and determining who the node holders are but rather traverse the entire history of the protocol from KTNA V1, V2, HNR to xHNR. At each step, to the best extent possible, the information shall be gathered from Snapshots, DEX data using Bitquery, or old migration files. For each of these wallet addresses, their transaction history shall be analysed against the protocol’s contract addresses and scraped for function signatures that contain "createNodeWithTokens" or "createNode". The approximate time of node creation shall also be noted. If the nodes were attained in KTNA V1, but migrated over in V2, then they shall not be considered as an additional node, but rather, shall be considered to be the same node that is currently present in V2 but deprecated in V1. This shall be done to avoid unfair duplications in the dataset and to only consider node creations, which were originated from the users and not created by the core team.

Once the raw data is collected, it shall pass to the second stage - post-processing. As a result of the protocol’s initial code inheritance, the original codebase contained security flaws and was consequently exploited. The exploiters utilised the "createNode" function signature instead of "createNodeWithTokens". Given the collected, associated function signatures from before, these wallets shall be filtered out. These wallets shall be simply removed from the entire dataset, regardless of the wallet’s other activity, to enforce a no-tolerance policy towards exploiters.

In the next stage, Bitquery shall be utilised again to build the appropriate graphql query. The query shall fetch all the trades made against KTNA, KTNA V2, HNR, and xHNR for a given wallet address. This shall return an array of all trades made by the wallet and shall be followed by a simple reduce algorithm to sum up all the trades. If the trade was conducted for the purposes of acquiring a node, it shall be converted to a negative number (e.g. 256 to -256). However, if the trade was conducted for the purposes of a sell using the protocol’s native token, it shall remain as a positive number. The reduce algorithm shall then sum up all the trades, and compute a single net “Redeemable Amount” number. The initiative shall not take into account any TofuNFT-related activity.

The proposal shall only revolve and focus on conducting the “Settlement & Release” initiative with users and wallets whose “Redeemable Amounts” are negative. If the total Redeemable Amount is positive or zero (likely due to a simple NFT transfer post pivot migration), the user shall not be eligible to receive an FTM denominated “Redeemable Amount”. In order for the users to be able to claim the “Redeemable Amount”, the users shall sign the relevant Settlement & Release agreement and dispose of their Samurai NFT Nodes to the protocol’s smart contracts. The Samurai NFT Nodes attained through the initiative shall be burned at a later date.

Upon the successful verification of eligibility and completion of enrolment for the collection of the “Redeemable Amount”, the appropriate total amount of “Redeemable Amounts” denominated in FTM shall be transferred from the Samurai Governance Vault to the smart contract devoted to the Settlement & Release initiative and shall be consequently transferred to the respective users. The Samurai Governance Vault shall also transfer relevant amounts of FTM to cover the gas fees associated with the FTM transfers.

The snapshot period shall remain identical to the original SIP-16 in order to avoid data conflicts.

The first batch of FTM transfers of the “Redeemable Amounts” shall be conducted 7 days after the potential approval of this proposal.

Other FTM transfers of the “Redeemable Amounts” for users who enroll at a later date shall be conducted arbitrarily.

Specification

Transfer the appropriate amounts (to be determined based on continuous enrolment) of Fantom tokens from Samurai Governance Vault to Samurai Release smart contract

Conduct the initiative and distribute the appropriate and relevant amounts of FTM (based on “Redeemable Amounts”), using the methodology outlined above

Transfer the collected Samurai NFT Nodes to the burn address

The proposed Solidity code / smart contracts

https://snapshot.org/#/samuraifi.eth/proposal/0x9af7bf478a1495864d8d1a7c543b539d35bfd14082b43072f1d2a3b0bebd7b6b
https://gateway.pinata.cloud/ipfs/QmTgGhboKEdjJn5qpV5bpqpVyFBQLn6E3VVYQmhiVQ92at