Skip to content

Commit 995cd03

Browse files
freddiecolemanfreddiecoleman
committed
initial fee service spec
1 parent 7453da0 commit 995cd03

File tree

1 file changed

+188
-0
lines changed

1 file changed

+188
-0
lines changed

‎CHIPs/chip-0039.md‎

Lines changed: 188 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
1+
| CHIP Number | 0039 |
2+
| :----------- | :-------------------------------------------------------------------- |
3+
| Title | Fee Service Standard |
4+
| Description | A standard for fee services that attach fees when XCH isn't available |
5+
| Author | [Freddie Coleman](https://github.com/freddiecoleman) |
6+
| Editor | [Dan Perry](https://github.com/danieljperry) |
7+
| Comments-URI | [CHIPs repo, PR #39](https://github.com/Chia-Network/chips/pull/137) |
8+
| Status | Draft |
9+
| Category | Standards Track |
10+
| Sub-Category | Primitive |
11+
| Created | 2024-12-17 |
12+
13+
## Abstract
14+
15+
This proposal describes a standard for fee services that attach fees when the spender doesn't have access to XCH. This service allows any spend bundle to have fees attached through a standardized protocol.
16+
17+
## Motivation
18+
19+
There are scenarios where a valid transaction cannot be submitted or will take a long time to be included in a block because there is no XCH available to pay for fees. Common scenarios include:
20+
21+
- Coins controlled by wallets that don't have access to XCH
22+
- Multi-signature wallets that want to separate fee management from asset management
23+
- Wallets that hold CATs and NFTs but no XCH
24+
- Vaults that want to perform recovery or rekey operations without holding XCH
25+
26+
Currently, these systems either need to:
27+
28+
1. Hold XCH specifically for fees
29+
2. Rely on manual fee attachment
30+
3. Use custom, non-standardized fee services
31+
32+
A standardized fee service interface would allow any application to request fee attachment from any compatible service, improving interoperability and reducing complexity.
33+
34+
## Backwards Compatibility
35+
36+
This standard introduces new service definitions but does not modify existing blockchain behavior. It is fully backwards compatible with existing spend bundles and transaction mechanisms.
37+
38+
## Rationale
39+
40+
The design focuses on the core functionality needed to attach fees to transactions:
41+
42+
- Simple request/response protocol
43+
- Minimal required fields
44+
- Clear separation between fee attachment and transaction submission
45+
46+
## Specification
47+
48+
### Core Concepts
49+
50+
A fee service must provide the capability to attach fees to a spend bundle. This involves:
51+
52+
1. Receiving a spend bundle that requires fees
53+
2. Creating additional coin spends to provide the necessary fees
54+
3. Returning a new spend bundle that includes both the original spends and the fee spends
55+
56+
### Protocol
57+
58+
The fee attachment protocol consists of two main operations:
59+
60+
1. Fee Attachment Request
61+
2. Fee Attachment Response
62+
63+
#### Fee Attachment Request
64+
65+
A request to attach fees must include:
66+
67+
- Spend Bundle:
68+
- Network identifier (e.g. mainnet, testnet11)
69+
- Submit flag - whether to let the service submit the spend bundle or just return it
70+
71+
#### Fee Attachment Response
72+
73+
The response must include:
74+
75+
- Modified spend bundle with fees attached
76+
- Amount of fees added
77+
- Error information if the request failed
78+
79+
### Error Conditions
80+
81+
Services must handle and clearly indicate the following error conditions:
82+
83+
1. Invalid spend bundle format
84+
2. Unsupported network
85+
3. Fee calculation failures
86+
87+
### Implementation Requirements
88+
89+
Fee services should:
90+
91+
1. Never modify the intention or effect of the original spend bundle
92+
2. Only add coin spends necessary for fee payment
93+
3. Provide clear documentation of:
94+
- Supported networks
95+
- Any rate limits or restrictions
96+
- Error conditions and responses
97+
98+
### Security Requirements
99+
100+
Fee services should:
101+
102+
1. Validate all input spend bundles
103+
2. Use secure transport (e.g. TLS)
104+
3. Implement appropriate rate limiting
105+
106+
## Examples
107+
108+
### Basic Fee Attachment Flow
109+
110+
1. Client has a valid spend bundle without fees
111+
2. Client sends spend bundle to fee service
112+
3. Service calculates required fees
113+
4. Service creates new coin spends for fees
114+
5. Service combines original spend bundle with fee spends
115+
6. Service returns complete spend bundle to client
116+
7. Client can verify and submit the transaction
117+
118+
### Example Spend Bundle Modification
119+
120+
```
121+
# Original spend bundle:
122+
{
123+
"coin_spends": [
124+
{
125+
"coin": {
126+
"parent_coin_info": "0x...",
127+
"puzzle_hash": "0x...",
128+
"amount": 1000
129+
},
130+
"puzzle_reveal": "0x...",
131+
"solution": "0x..."
132+
}
133+
],
134+
"aggregated_signature": "0x..."
135+
}
136+
137+
# After fee service:
138+
{
139+
"coin_spends": [
140+
# Original spend
141+
{
142+
"coin": {
143+
"parent_coin_info": "0x...",
144+
"puzzle_hash": "0x...",
145+
"amount": 1000
146+
},
147+
"puzzle_reveal": "0x...",
148+
"solution": "0x..."
149+
},
150+
# Added fee spend
151+
{
152+
"coin": {
153+
"parent_coin_info": "0x...",
154+
"puzzle_hash": "0x...",
155+
"amount": 100
156+
},
157+
"puzzle_reveal": "0x...",
158+
"solution": "0x..."
159+
}
160+
],
161+
"aggregated_signature": "0x..." # Updated to include fee spend
162+
}
163+
```
164+
165+
## Test Cases
166+
167+
1. Basic fee attachment to a simple spend bundle
168+
2. Fee attachment to a multiple-coin-spend transaction
169+
3. Handling of invalid spend bundles
170+
4. Verification that original transaction intent is preserved
171+
5. Rate limit handling
172+
6. Network selection validation
173+
174+
## Security Considerations
175+
176+
Fee services introduce a trust relationship - the service must be trusted to:
177+
178+
1. Not front-run transactions
179+
2. Not leak transaction details
180+
3. Provide reliable fee attachment
181+
4. Maintain availability
182+
5. Not modify transaction intent
183+
184+
Implementations should clearly document their trust model and security properties.
185+
186+
## Copyright
187+
188+
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

0 commit comments

Comments
 (0)