White paper
  • Introduction
    • 🔍Overview
  • TA-DA APP
    • ⚙️How it works
    • 📱Application overview
      • 🫂Social Media Engagement
    • 🎮Game Mechanics
      • ➡️Energy
      • ➡️Abilities
      • ➡️Items
      • ➡️Shop
      • ➡️Lootboxes
      • ➡️Marketplace
      • ➡️Gems
    • 💰User rewards
      • ➡️Prize Pools
      • ➡️Rewards & Staking
      • ➡️Ta-da Bondz (T-Bondz)
  • WHITE PAPER
    • 📖Introduction: The Data Wall
    • 📖Human Generated Data
    • 📖Scaling data generation with blockchain
    • ❇️Use-cases
      • 🧠Artificial Intelligence
        • ➡️Audio Datasets
        • ➡️Video Datasets
        • ➡️Image Datasets
        • ➡️Text Datasets
      • 🖇️Data Structuring
    • ⛓️Blockchain Integration
      • ➡️Smart Contracts
      • ➡️Snapshot System
      • ➡️In-app Wallet
      • ➡️Signature
      • ➡️Next step: Slashing Authorization
      • ➡️Next step: Ta-da chain
    • 📄Quality Assurance
  • Token
    • 🏦Economy
      • ➡️Agents
      • ➡️Money Flow
      • ➡️Economy Breakdown
      • 🔥The Big Burn
    • 📊Token Metrics
    • 🏦Staking
      • ➡️On-chain Staking
      • ➡️Meria Staking
      • ➡️xExchange Metastaking
    • 💰Buy $TADA Tokens
      • 📈Buy on Kucoin
      • 📈Buy on PancakeSwap
      • 📈Buy on xExchange
  • Project
    • 🛫Roadmap
    • 🧑‍🤝‍🧑Team
  • LINKS
    • 📱Try the beta!
    • 🌎Website
    • 🐦X (Twitter)
    • 🗣️Discord
    • 🗞️Telegram
Powered by GitBook
On this page
  • Slashing Authorization
  • Auto withdrawal
  1. WHITE PAPER
  2. Blockchain Integration

Next step: Slashing Authorization

Slashing Authorization

Our goal is to fully decentralize Ta-da. However, this cannot be achieved all at once, so we are progressing gradually. In this second step, we are addressing the slashing system. In the previous version, the backend could theoretically slash an arbitrary amount of tokens. Therefore, it is necessary to implement a solution that prevents or mitigates this risk. This section describes such a system.

When the user performs a task he sends to the backend a slashing authorization signed by his private key. A signed authorization is irrefutable proof that the user allows the deduction of a precisely determined deposit amount for a specific task.

The backend stores this authorization and sends it to the Deposit Pool if the user is slashed. This smart contract then checks that the authorization is valid thanks to the signature and slashes the user accordingly. That way, a user cannot lose more than he has previously authorized.

A slashing authorization must contain this information:

  • the identifier of the task

  • the amount of tokens the user accepts to lose through slashing

  • a nonce avoiding replay attacks

  • a timestamp

  • the signature

Before accepting and storing the slashing authorization, the backend checks the validity of each field.

The nonce prevents replay attacks. Without it, the backend could send the same authorization multiple times to slash all of a user's tokens. The Deposit Pool prevents this attack by checking that the authorization has not already been executed using this nonce.

At this stage, the backend could still arbitrarily slash a user. However, it could only do so for the amount specified in the authorizations that have been sent to it and have not yet been executed. This greatly mitigates the risk.


Auto withdrawal

As a reminder, the Deposit Pool executes withdrawal requests only after backend confirmation. This means that if the backend fails for any reason, the withdrawals cannot be processed. To address this issue, the smart contract implements a period during which the backend must authorize or refuse the withdrawal (it must respond either way). If there is no response after this period, the tokens are automatically released and returned to the user.

PreviousSignatureNextNext step: Ta-da chain
⛓️
➡️