VeChain Docs
  • Welcome to VeChain
  • Blockchain Basics
    • Introduction to blockchain
    • Introduction to digital property
    • The evolution of the internet
  • Introduction to VeChain
    • About the VeChain blockchain
      • Consensus Deep Dive
      • Governance
    • Dual-Token Economic Model
      • VeChain (VET)
      • VeThor (VTHO)
    • Acquire VeChain Assets
    • Sustainability
  • Core Concepts
    • Networks
      • Thor Solo Node
      • Testnet
      • Mainnet
    • Nodes
      • Node Rewards Programme
    • Blocks
      • Block Model
    • Transactions
      • Transaction Model
      • Transaction Fees
      • Transaction Calculation
      • Meta Transaction Features
        • Transaction Uniqueness
        • Controllable Transaction Lifecycle
        • Clauses (Multi-Task Transaction)
        • Fee Delegation
          • Multi-Party Payment (MPP)
          • Designated Gas Payer (VIP-191)
        • Transaction Dependency
    • Block Explorers
    • Wallets
      • VeWorld
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync2
        • User Guide
          • Setup
          • Wallet
          • Signing
          • Activities
          • Settings
        • FAQ
      • Sync
        • User Guide
          • Wallet
          • Ledger Device
          • Browser dApps and web
          • Interact with dApps
          • Activities
          • Settings
          • Report an Issue
          • Contributing
        • FAQ
    • EVM Compatibility
      • VeChain Modifications
      • Methodology
      • Test Coverage
        • Gas model
        • Raw transaction
        • hardhat specific
          • Ganache failures
          • evm_increaseTime
        • Failures in constructor
        • eth_sign
        • Contract address prediction
        • BadBeacon proxy address at 0x1
      • How to Recreate
      • Additional Information
        • Using Governance Contracts
        • ERC1820/ERC777 Testnet
        • Delegate Options
    • Account Abstraction
      • UserOperation
      • Bundler
      • EntryPoint Contract
      • Account Factory Contract
      • Paymaster Contract
    • Token Bound Accounts
  • How to run a node
    • Nodes
    • How to run a Thor Solo Node
    • Custom Network
    • Connect Sync2 to a Thor Solo Node
  • Developer Resources
    • Getting Started
    • How to build on VeChain
      • Connect to the Network
      • Read Data
        • Read Blocks
        • Read Transactions
        • Read Accounts
        • States & Views
        • Events & Logs
        • VET Transfers
      • Write Data
        • Transactions
        • Fee Delegation
      • Listen to Changes
        • Events
        • VET Transfers
        • Transactions
        • Blocks
        • Beats
      • Build with Hardhat
      • Utilities
        • BigInt and Unit-Handling
        • Name Service Lookups
    • Example dApps
      • Buy me a Coffee
      • Token Bound Accounts
      • PWA with Privy and Account Abstraction
    • EVM Compatibility for Developers
      • Key Architectural Differences and Optimizations
      • Practical Implications for Developers: Key Considerations
      • RPC Methods (Detailed Breakdown)
      • Frequently Asked Questions (FAQs)
      • VeChain Blockchain Specifications
      • Key Differences Between VeChain and Ethereum (Summary)
      • Best Practices for Developing on VeChainThor
    • How to verify Address-Ownership
      • Next.js Session Verification
    • Debug Reverted Transactions
    • Account Abstraction
    • VIP-191: Designated Gas Payer
      • How to Integrate VIP-191 (I)
      • How to Integrate VIP-191 (II)
      • How to Integrate VIP-191 (III)
    • Index with Graph Node
      • Setup with Docker
      • Index with OpenZeppelin
        • Create Subgraph Project
        • Configure Contracts
        • Deploy Subgraph and start Indexing
        • Track Subgraph Indexing
        • Access Subgraph
        • Update Subgraph
    • SDKs & Providers
      • SDK
        • Architecture
        • Accounts
        • Bloom Filter
        • Certificates
        • Contracts
        • Cryptography
        • Debug
        • Encoding
        • Polls
        • Subscriptions
        • Thor Client
        • Transactions
      • Thor DevKit
        • Installation
        • Usage
          • Cryptography
          • Accounts
          • Encoding
          • Transactions
          • Certificates
          • Bloom Filter
      • DApp Kit
        • v2
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
        • v1
          • Installation
          • React
            • Installation
            • Usage
          • Vanilla JS
            • Installation
            • Usage
          • Core
            • Installation
            • Usage
          • Theme Variables
          • i18n
          • Node Polyfills
          • V0 to V1
        • v0
          • Installation
          • Usage
          • React
            • Installation
            • Usage
          • Vanilla (UI)
            • Installation
            • Usage
          • Styles (UI)
          • i18n
      • DevPal
      • Web3-Providers-Connex
        • Installation
        • Usage
      • Connex
        • Installation
        • API Specification
    • Frameworks & IDEs
      • Hardhat
      • Remix
    • Built-in Contracts
    • VORJ
    • Useful Links
  • How to contribute
Powered by GitBook
On this page
  • Introduction
  • Fee Delegation Protocols
  • Multi-Party Payment (MPP)
  • Designated Gas Payer (VIP-191)
  • Conclusion

Was this helpful?

  1. Core Concepts
  2. Transactions
  3. Meta Transaction Features

Fee Delegation

VeChain provides two approaches for fee delegation on the VeChainThor blockchain.

Introduction

Fee delegation is a feature on the VeChainThor blockchain which enables the transaction sender to request another entity, a sponsor, to pay for the transaction fee on the sender's behalf. Fee delegation greatly improves the user experience, especially in the case of onboarding new users by removing the necessity of the user having to first acquire cryptocurrency assets before being able to interact on-chain.

The purpose of this document is to provide a high-level introduction to both fee delegation protocols and to compare and contrast them. Further detail is provided on both fee delegation protocols in subsequent documents.

Additional detail and documentation is provided in the supplementary sections:

  • Multi-Party Payment (MPP)

  • Designated Gas Payer (VIP-191)

Fee Delegation Protocols

The VeChainThor blockchain offers two protocols for implementing fee delegation, multi-party payment (MPP) and designated gas payer (VIP-191). Both fee delegation protocols achieve the same goal of delegating the transaction fee from the transaction sender to a designated sponsor. The difference between both protocols is the implementation and the use cases.

Multi-Party Payment (MPP)

MPP is a native protocol on the VeChainThor blockchain. MPP enables the sender of a transaction to request that a sponsor or the receiver of the transaction pays the transaction fee on the senders' behalf. MPP is a fee delegation approach which is implemented on the smart contract level. This means that data must be written on-chain, which comes at a cost. It is more cost-effective to use the MPP protocol for frequent interactions between users and a decentralized application (dApp). An example of MPP implementation could be a marketplace or game which has opted to pay for all users transaction fees.

Designated Gas Payer (VIP-191)

The designated gas payer is a standard which has been implemented on the VeChainThor blockchain, through VIP-191, which extends the MPP functionality in a more flexible way. VIP-191, allows a transaction sender to seek for an arbitrary party to pay the transaction fee on the sender's behalf. An example of VIP-191 implementation could be to implement a transaction fee sponsor for users that are performing a particular action such as minting an NFT at an event or awarding the highest points scorer on a game with sponsored transactions.

Conclusion

Both fee delegation protocols achieve a common goal of allowing a transaction sender to delegate the transaction fee to a sponsor. However, both protocols are implemented in different ways.

The MPP implementation is at a smart contract level and thus comes with a cost. Including MPP within a smart contract will increase the size of the smart contract which will requires more space and thus will have a larger cost when it comes to deploying the smart contracts on the VeChainThor blockchain. The MPP approach to fee delegation is worthwhile if you intend to sponsor all user transactions for a set of smart contracts which form a decentralized application (dApp).

VIP-191 is a more flexible fee delegation approach which moves the fee delegation feature from the smart contract to the transaction itself. A user when sending a transaction can provide a sponsor who will sponsor the transaction fee on the sender's behalf. However, VIP-191 requires that both the transaction sender and sponsor are both online for the transaction to be completed. This is not the case for MPP as it is implemented at a smart contract level.

Both fee delegation protocols have their specific use cases, and it is up to the developer to determine which fee delegation protocol best suits their needs. Please read the following articles and subsequent documents for deeper information on both fee delegation protocols.

Some useful articles to read on this subject include:

PreviousClauses (Multi-Task Transaction)NextMulti-Party Payment (MPP)

Last updated 11 months ago

Was this helpful?

This MPP article
This VIP-191 article