Skip to content

Commit

Permalink
REP-43: Introducing Payment Processor for Request Fees (#43)
Browse files Browse the repository at this point in the history
  • Loading branch information
@Candinya
Candinya authored Aug 19, 2024
1 parent c5b8afb commit 485ddff
Show file tree
Hide file tree
Showing 3 changed files with 60 additions and 10 deletions.
21 changes: 11 additions & 10 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,16 +6,17 @@ REP stands for RSS3 Evolution Proposal, a detailed documentation proposed by the

This repository tracks all REPs proposed by the RSS3 Community.

| REP Number | Title | Proposer(s) | Type | Status |
| -------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------- |
| [REP-1](./REPs/REP-1.md) | Purpose and Guidelines | <henry@rss3.io> | Process | Living |
| [REP-11](./REPs/REP-11.md) | Protocol Upgrade | [BruceXC](mailto:xichang1510@gmail.com), [HenryQW](mailto:hi@henry.wang), [KallyDev](mailto:kallydev@gmail.com), [Nya Candy](mailto:github@candinya.com), [polebug](mailto:polebugfly@gmail.com), [pseudoyu](mailto:pseudoyu@connect.hku.hk), [Thomas](mailto:73341653+naaive@users.noreply.github.com) | Protocol | Final |
| [REP-16](./REPs/REP-16.md) | Staking Rewards Taxation Adjustment | [Albert](mailto:iavl@proton.me), [HenryQW](mailto:hi@henry.wang) | Core | Final |
| [REP-20](./REPs/REP-20.md) | Data Availability Layer Integration | [Albert](mailto:iavl@proton.me), [HenryQW](mailto:hi@henry.wang) | Core | Final |
| [REP-26](./REPs/REP-26.md) | Chip Mechanism Upgrade | [BruceXC](mailto:xichang1510@gmail.com) | Core | Candidate |
| [REP-33](./REPs/REP-33.md) | Node State Transition | [KallyDev](mailto:kallydev@rss3.io), [BruceXC](mailto:xichang1510@gmail.com) | Core | Draft |
| [REP-38](./REPs/REP-38.md) | Demotion and Slashing Mechanism | [Polebug](mailto:polebug@rss3.io) | Core | Draft |
| [REP-40](./REPs/REP-40.md) | Whitepaper Updates | [pseudoyu](mailto:pseudoyu@connect.hku.hk) | Core | Draft |
| REP Number | Title | Proposer(s) | Type | Status |
| -------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------- |
| [REP-1](./REPs/REP-1.md) | Purpose and Guidelines | <henry@rss3.io> | Process | Living |
| [REP-11](./REPs/REP-11.md) | Protocol Upgrade | [BruceXC](mailto:xichang1510@gmail.com), [HenryQW](mailto:hi@henry.wang), [KallyDev](mailto:kallydev@gmail.com), [Nya Candy](mailto:github@candinya.com), [polebug](mailto:polebugfly@gmail.com), [pseudoyu](mailto:pseudoyu@connect.hku.hk), [Thomas](mailto:73341653+naaive@users.noreply.github.com) | Protocol | Final |
| [REP-16](./REPs/REP-16.md) | Staking Rewards Taxation Adjustment | [Albert](mailto:iavl@proton.me), [HenryQW](mailto:hi@henry.wang) | Core | Final |
| [REP-20](./REPs/REP-20.md) | Data Availability Layer Integration | [Albert](mailto:iavl@proton.me), [HenryQW](mailto:hi@henry.wang) | Core | Final |
| [REP-26](./REPs/REP-26.md) | Chip Mechanism Upgrade | [BruceXC](mailto:xichang1510@gmail.com) | Core | Candidate |
| [REP-33](./REPs/REP-33.md) | Node State Transition | [KallyDev](mailto:kallydev@rss3.io), [BruceXC](mailto:xichang1510@gmail.com) | Core | Draft |
| [REP-38](./REPs/REP-38.md) | Demotion and Slashing Mechanism | [Polebug](mailto:polebug@rss3.io) | Core | Draft |
| [REP-40](./REPs/REP-40.md) | Whitepaper Updates | [pseudoyu](mailto:pseudoyu@connect.hku.hk) | Core | Draft |
| [REP-43](./REPs/REP-43.md) | Introducing Payment Processor for Request Fees | [Nya Candy](mailto:dev@candinya.com) | Core | Draft |

## License

Expand Down
49 changes: 49 additions & 0 deletions REPs/REP-43.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
```
REP: REP-43
Title: Introducing Payment Processor for Request Fees
Status: Draft
Type: Core
Created: 26 Jul 2024
Author(s): Nya Candy <dev@candinya.com>
Description: This REP describes a request billing and reward distributing cycle of Ownership Economy.
Discussions: https://forum.rss3.io/t/rep-draft-on-request-fees/176
```

# REP-43: Introducing Payment Processor for Request Fees

## Table of Contents

- [Abstract](#abstract)
- [Motivation](#motivation)
- [Specification](#specification)
- [Request billing: the cycle](#request-billing-the-cycle)
- [Rationale](#rationale)

## Abstract

This proposal introduces a request billing and reward distribution mechanism for the RSS3 Network. Payment Processors (PPs) follow the mechanism to bill developers based on their usage and distribute the collected fees to Node Operators and content owners based on their contributions. The primary goal is to foster a healthy and sustainable Ownership Economy by assigning value to data production and consumption.

## Motivation

Currently, developers make requests at no cost, while Node Operators are covering a substantial infrastructure cost. Under the current setting where rewards are distributed to Node Operators by the network, there is no new inflow of funds, resulting in an economy that is not expanding and not sustainable. A solution to is to introduce reasonable request fees, which promotes an economic cycle. At the same time, free requests will remain available with a reasonable rate limit.

## Specification

This proposal introduces the Payment Processsor, which acts as load balancer for GIs to assist request distribution, request billing, and fee distribution.

Detailed technical implementations are outside the scope of this proposal, please refer to the relevant source code repositories and documentation, the focus here is on describing the mechanism.

![Specification](REP-43/Specification.png)

### Request billing: the cycle

The economic cycle consists of three stages: Deposit, Consumption and Withdraw.

1. Deposit is a way for developers to fund their requests, using a pre-paid mechanism. The developer can invoke the contract's deposit function at any time the Network is running, and PP will then update the usage limit after the corresponding deposit transaction is finalized on VSL. The deposit is temporarily stored in a pool controlled by PP.
2. Consumption refers to when the developer make requests with the assigned credentials, PP records total consumption. If a developer’s usage exceeds the deposit coverage, the requests will be rate limited.
3. Settlement refers to when PP deducts corresponding tokens from the deposit pool based on usage, which takes place at the end of each epoch. The collected fees are then sent to Node Operators and content owners based on their contributions.
4. Withdrawal refers to the process of refunding the remaining deposit to the developer after deducting their usage cost. Since it requires the deduction of actual spending, withdrawals are only settled at the end of each epoch when settlement is complete, and the refund is sent to the original depositor only.

## Rationale

The core of this proposal is the introduction of Payment Processor to foster a sustainable economic cycle on RSS3 Network. The mechanism will ensure Node Operators and content owners are rewarded for their contributions to RSS Network.
Binary file added REPs/REP-43/Specification.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 485ddff

Please sign in to comment.