FOR DISCUSSION: Potential updates to the Facet Compute Token (FCT) Mechanism

[RogerPodacter]

FCT Issuance: Current System, Challenges, and Potential Solutions

Hey everyone,

I want to open a discussion about our current FCT issuance system. As an early-stage protocol, we need to ensure our mechanisms are as straightforward and accessible as possible.

While many of these challenges could theoretically be addressed by a mature market over time, we're in a phase where simplicity and clarity are crucial for adoption and healthy market development.

Current System

FCT issuance is controlled by a dynamic rate adjustment mechanism that operates in 10,000-block periods (approximately 1.4 days). Here's how it works:

• The system targets 400,000 FCT per adjustment period
• Every period, the issuance rate adjusts based on how much FCT was minted in the previous period
• If more than the target amount was minted, the rate decreases proportionally (up to a maximum change of 50%)
• The target issuance rate halves every year to ensure a fixed total supply
• The amount of FCT minted per transaction is based on the gas used for calldata, multiplied by the current issuance rate

Issues We're Seeing (With Proposed Solutions)

Note: None of these solutions are final—we’re proposing them to give the community something to react to and get feedback on. Based on this feedback, we may implement one or more of them, or we might not.

Uncertain Supply Dynamics

Though the halving mechanism ensures FCT has a finite maximum supply, the current system makes it difficult to determine what this supply is. This creates uncertainty for token holders who can't accurately assess the value of their holdings in relation to the total supply.

Proposed Improvement: issuance-based halving

To address this, we propose an issuance-based halving mechanism. Instead of halving on a fixed schedule (e.g., once a year), the rate halves whenever the total FCT supply crosses specific thresholds—regardless of how long it takes to get there. This ensures a known, finite supply while responding to actual minting behavior.

1. Set a Max Supply Baseline

1. Start with 210M FCT as the “original target total supply.”
2. At the fork block, compare:
   • Actual issuance so far (“actual_issuance”)
   • Ideal issuance over that same period (“ideal_issuance,” calculated as blocks * 40 FCT)
3. Adjust the 210M target by the difference (i.e., if more than the target has been minted, increase the final supply; if less, decrease it).

Example:

• Current total issuance is 75M
• 500k blocks have passed
• Ideal issuance = 500k blocks * 40 FCT = 20M
• Difference = 75M - 20M = 55M
• Adjusted final supply = 210M + 55M = 265M

2. Determine the First Halving Threshold

From that new total, the first halving threshold is half of the adjusted supply.

• Using the example above, it’s 265M / 2 = 132.5M.

Once the total minted supply crosses this number, the first halving event triggers. Future thresholds keep halving the remaining supply.

• In the example, after crossing 132.5M, the next threshold adds another half of that bracket (132.5M / 2), bringing the next halving mark to 198.75M.

This approach clarifies the maximum possible supply and makes the timing of halvings directly dependent on how quickly (or slowly) new FCT is minted.

Dramatic Period-to-period Mint Rate Fluctuations

The current issuance mechanism creates a situation where the optimal strategy isn't simply "mint FCT when you think it's valuable relative to ETH." Instead, users must consider the mechanism itself and how others will interact with it, distorting the calculation. This leads to artificial patterns of issuance (e.g., the "seesaw effect") that aren't connected to any meaningful market signals or fundamental factors, introducing unnecessary volatility into the system.

Proposed Improvement: Overage Carry-Over

The Core Idea

Everything above 800,000 FCT in a period gets added to the next period's total.

How It Works

1. In each period:

   • First 800k FCT triggers maximum 0.5x rate reduction
   • Any amount above 800k “carries over”
   • Carried-over amount gets counted in next period's total

2. If next period's total (new minting + carry-over from previous period) exceeds 800k:

   • Rate decreases by 0.5x again
   • Excess carries forward again

Example

Period 1: Someone mints 10M FCT

• First 800k triggers 0.5x rate reduction
• Remaining 9.2M carries to Period 2

Period 2: No new minting, but we have 9.2M carried over

• First 800k triggers another 0.5x reduction
• Remaining 8.4M carries to Period 3

Period 3: No new minting, but we have 8.4M carried over

• First 800k triggers another 0.5x reduction
• Remaining 7.6M carries to Period 4

This continues until all excess minting has been accounted for.

Gas Price-driven Volatility

The volatility of Ethereum gas prices directly affects FCT minting costs—sometimes an order of magnitude more than the parameters of the FCT mechanism itself. While a mature market might develop ways to hedge or price in this risk, currently this volatility is passed directly to users, adding another layer of complexity to minting decisions.

Proposed Improvement: Base mint on ETH burn

We plan to base the FCT minting calculation on the amount of ETH burned, rather than directly on raw gas units. Specifically:

1. Measure “Data Gas” the Same Way: continue counting only the data-related gas (i.e., ignoring the initial 21,000 gas overhead and contract execution costs), just as we do today.

2. Incorporate the Block Base Fee: instead of simply multiplying these data gas units by the dynamic mint rate, we first multiply the data gas units by the block’s base fee. This yields the total ETH burned for the data portion of the transaction.

3. Derive FCT Mint from ETH Burned: that ETH-burn figure is then fed into the mint rate calculation. If gas prices spike and base fees are high, it costs more ETH to send data—but more FCT is also minted. Conversely, if gas prices are low, the mint output decreases in proportion.

By tying minted FCT to the actual ETH burn, we neutralize the wild swings in gas prices. Users no longer have to worry about timing their transactions to avoid expensive gas intervals; if they do pay more in ETH due to higher base fees, they’ll proportionally receive more FCT in return.

Technical Constraints

As we think about addressing these issues, there are some important technical constraints to keep in mind:

1. The amount of FCT minted in a transaction must be predictable before the transaction is included in a block (so that users can pre-calculate their transaction hashes)
2. The issuance rate cannot go to zero, as some FCT must always be available for gas fees
3. Any changes need to be forward-looking to protect existing holders

Community Input Needed

We'd appreciate your thoughts on:

1. Supply Dynamics

   • Is issuance-based halving clearer than time-based?
   • Are the threshold calculations intuitive?

2. Rate Mechanism

   • Should we keep 0.5x/2x adjustment limits?
   • Is 10,000-block period still appropriate?

3. Gas Price Impact

4. General

   • How do these issues affect your FCT interaction?
   • What aspects of the current system should we preserve?
   • Which improvements should we prioritize?

Please share your thoughts and experiences in the comments below. We want to ensure any future improvements are informed by the needs and insights of our community!

[tunnckoCore]

The carry-over strategy makes sense, definitely. Plus introducing the block base fee.

But I'm for time/block-based halvings. There's nothing more clear and based than TIME.

Introduction above two things (carry-over and block base fee) would fix the aggressive fluctuations between adjusting periods.

[alex-home-0x]

FCT Issuance: Current System, Challenges, and Potential Solutions

Hey everyone,

I want to open a discussion about our current FCT issuance system. As an early-stage protocol, we need to ensure our mechanisms are as straightforward and accessible as possible.

While many of these challenges could theoretically be addressed by a mature market over time, we're in a phase where simplicity and clarity are crucial for adoption and healthy market development.

Current System

FCT issuance is controlled by a dynamic rate adjustment mechanism that operates in 10,000-block periods (approximately 1.4 days). Here's how it works:

• The system targets 400,000 FCT per adjustment period
• Every period, the issuance rate adjusts based on how much FCT was minted in the previous period
• If more than the target amount was minted, the rate decreases proportionally (up to a maximum change of 50%)
• The target issuance rate halves every year to ensure a fixed total supply
• The amount of FCT minted per transaction is based on the gas used for calldata, multiplied by the current issuance rate

Issues We're Seeing (With Proposed Solutions)

Note: None of these solutions are final—we’re proposing them to give the community something to react to and get feedback on. Based on this feedback, we may implement one or more of them, or we might not.

Uncertain Supply Dynamics

Though the halving mechanism ensures FCT has a finite maximum supply, the current system makes it difficult to determine what this supply is. This creates uncertainty for token holders who can't accurately assess the value of their holdings in relation to the total supply.

Proposed Improvement: issuance-based halving

To address this, we propose an issuance-based halving mechanism. Instead of halving on a fixed schedule (e.g., once a year), the rate halves whenever the total FCT supply crosses specific thresholds—regardless of how long it takes to get there. This ensures a known, finite supply while responding to actual minting behavior.

1. Set a Max Supply Baseline

2. Start with 210M FCT as the “original target total supply.”

3. At the fork block, compare:

   • Actual issuance so far (“actual_issuance”)
   • Ideal issuance over that same period (“ideal_issuance,” calculated as blocks * 40 FCT)

4. Adjust the 210M target by the difference (i.e., if more than the target has been minted, increase the final supply; if less, decrease it).

Example:

• Current total issuance is 75M
• 500k blocks have passed
• Ideal issuance = 500k blocks * 40 FCT = 20M
• Difference = 75M - 20M = 55M
• Adjusted final supply = 210M + 55M = 265M

2. Determine the First Halving Threshold

From that new total, the first halving threshold is half of the adjusted supply.

• Using the example above, it’s 265M / 2 = 132.5M.

Once the total minted supply crosses this number, the first halving event triggers. Future thresholds keep halving the remaining supply.

• In the example, after crossing 132.5M, the next threshold adds another half of that bracket (132.5M / 2), bringing the next halving mark to 198.75M.

This approach clarifies the maximum possible supply and makes the timing of halvings directly dependent on how quickly (or slowly) new FCT is minted.

Dramatic Period-to-period Mint Rate Fluctuations

The current issuance mechanism creates a situation where the optimal strategy isn't simply "mint FCT when you think it's valuable relative to ETH." Instead, users must consider the mechanism itself and how others will interact with it, distorting the calculation. This leads to artificial patterns of issuance (e.g., the "seesaw effect") that aren't connected to any meaningful market signals or fundamental factors, introducing unnecessary volatility into the system.

Proposed Improvement: Overage Carry-Over

The Core Idea

Everything above 800,000 FCT in a period gets added to the next period's total.

How It Works

1. In each period:

   • First 800k FCT triggers maximum 0.5x rate reduction
   • Any amount above 800k “carries over”
   • Carried-over amount gets counted in next period's total

2. If next period's total (new minting + carry-over from previous period) exceeds 800k:

   • Rate decreases by 0.5x again
   • Excess carries forward again

Example

Period 1: Someone mints 10M FCT

• First 800k triggers 0.5x rate reduction
• Remaining 9.2M carries to Period 2

Period 2: No new minting, but we have 9.2M carried over

• First 800k triggers another 0.5x reduction
• Remaining 8.4M carries to Period 3

Period 3: No new minting, but we have 8.4M carried over

• First 800k triggers another 0.5x reduction
• Remaining 7.6M carries to Period 4

This continues until all excess minting has been accounted for.

Gas Price-driven Volatility

The volatility of Ethereum gas prices directly affects FCT minting costs—sometimes an order of magnitude more than the parameters of the FCT mechanism itself. While a mature market might develop ways to hedge or price in this risk, currently this volatility is passed directly to users, adding another layer of complexity to minting decisions.

Proposed Improvement: Base mint on ETH burn

We plan to base the FCT minting calculation on the amount of ETH burned, rather than directly on raw gas units. Specifically:

1. Measure “Data Gas” the Same Way: continue counting only the data-related gas (i.e., ignoring the initial 21,000 gas overhead and contract execution costs), just as we do today.
2. Incorporate the Block Base Fee: instead of simply multiplying these data gas units by the dynamic mint rate, we first multiply the data gas units by the block’s base fee. This yields the total ETH burned for the data portion of the transaction.
3. Derive FCT Mint from ETH Burned: that ETH-burn figure is then fed into the mint rate calculation. If gas prices spike and base fees are high, it costs more ETH to send data—but more FCT is also minted. Conversely, if gas prices are low, the mint output decreases in proportion.

By tying minted FCT to the actual ETH burn, we neutralize the wild swings in gas prices. Users no longer have to worry about timing their transactions to avoid expensive gas intervals; if they do pay more in ETH due to higher base fees, they’ll proportionally receive more FCT in return.

Technical Constraints

As we think about addressing these issues, there are some important technical constraints to keep in mind:

1. The amount of FCT minted in a transaction must be predictable before the transaction is included in a block (so that users can pre-calculate their transaction hashes)
2. The issuance rate cannot go to zero, as some FCT must always be available for gas fees
3. Any changes need to be forward-looking to protect existing holders

Community Input Needed

We'd appreciate your thoughts on:

1. Supply Dynamics

   • Is issuance-based halving clearer than time-based?
   • Are the threshold calculations intuitive?

2. Rate Mechanism

   • Should we keep 0.5x/2x adjustment limits?
   • Is 10,000-block period still appropriate?

3. Gas Price Impact

4. General

   • How do these issues affect your FCT interaction?
   • What aspects of the current system should we preserve?
   • Which improvements should we prioritize?

Please share your thoughts and experiences in the comments below. We want to ensure any future improvements are informed by the needs and insights of our community!

I completely agree with the above improvements, they are excellent optimizations. Additionally, it would be even better if a release cap for FCT could be set for a single address during a single minting event. This would further help in activating on-chain data.

[mikeahirsch]

The carry-over strategy makes sense, definitely. Plus introducing the block base fee.

But I'm for time/block-based halvings. There's nothing more clear and based than TIME.

Introduction above two things (carry-over and block base fee) would fix the aggressive fluctuations between adjusting periods.

The reason to still have issuance based halving cycles is because that forces a max supply. The other changes as you pointed out will help it stay on target time wise.

[rong888i]

Based on a Strict Total Supply Cap of 210M FCT and Introducing a Progressive Excess Carryover Mechanism

Progressive Excess Decay Mechanism
Excess Decay Rules

50% of the excess in each period is carried over to the next period, while the remaining 50% is permanently burned.

This mechanism avoids the infinite propagation of excess and accelerates the market's return to equilibrium.

[wzr980702]

Tom, can you guys mint some fct and syndicate it to exchanges or cryptocurrency news outlets to send out news. Give a sunny airdrop to ethereum ogs (vitalik, etc), blue chip nft holders (pudgy, ape), ethereum popular meme holders (pepe, etc), ethscriptions active traders, and the community (eths). the fct holdings are too small, exchanges value holdings very much, and the fct is now simply It's not worth anything, you can mine a lot with just a little gas fee, and for you guys, for a few e's (a few thousand dollars) or even less, you can do sunshine airdrops. It's the free ones that are the most expensive, and giving exposure to facet and fct in this way is one of those things that is a lot of money for a little money. I hope you guys will take a serious look at what I am suggesting. facet needs marketing, biance is going to be on tens and hundreds of tokens a year for spot and 100s of contracts leveraged. Other exchanges have even more torrents coming online, and facet is really something no one cares about if they don't market it.

[wzr980702]

There are tens of millions of virtual currencies in existence, pump.fun produces a lot of junk every day, fct is just an insignificant one of the tens of millions of currencies. fct is nothing spectacular either in terms of issuance mechanism or otherwise. We've got to step up our marketing efforts, and I hope Jeremy goes and looks at more tokens from other exchanges that have gone live on biance, coinbase, etc., and their token economics and marketing methods. Switch your thinking, you don't want all the fct you spent real money on mining to turn into a bunch of useless code, do you?

[mikeahirsch]

This discussion is for the mentioned changes to the protocol, not ways to market FCT or Facet. Let’s move those conversations outside of this forum.

[hecochaincom]

Either set a total amount and strictly enforce it, or cancel the total amount

[RogerPodacter]

Updated FCT Issuance Proposal: Dual-Threshold Period Adjustments

Following community feedback on our previous proposals, we'd like to present an alternative approach to managing FCT issuance that we believe better addresses the period-to-period mint rate fluctuations.

Instead of implementing the previously proposed overage carry-over mechanism, we're considering a dual-threshold adjustment system that we believe will create more predictable and stable issuance patterns.

NOTE: This is a replacement only for the "Proposed Improvement: Overage Carry-Over" section of the original post. The other two proposed changes in that post (issuance-based halving and moving from gas units to Ether burned as the input to minting) are not affected by this new post.

The Core Idea

Rather than having fixed-length periods with carry-over mechanics, we propose a system where each adjustment period can end in one of two ways:

1. After 10,000 blocks have passed (the "block threshold")
2. After 400,000 FCT have been minted (the "issuance threshold")

Whichever threshold is hit first triggers the end of the period and a rate adjustment for the next period.

How It Works

Period Endings

Each period starts with a target issuance rate and can end in one of two ways:

1. Block Threshold (10,000 blocks)

   • If 10,000 blocks pass before 400,000 FCT is minted
   • Compare actual FCT minted to 400,000 target
   • Adjust rate up proportionally (capped at 2x increase)

2. Issuance Threshold (400,000 FCT)

   • If 400,000 FCT is minted before 10,000 blocks pass
   • Compare actual blocks taken to 10,000 target
   • Adjust rate down proportionally (capped at 0.5x decrease)

Example Scenarios

Scenario 1: Under-issuance

• Period ends after 10,000 blocks
• Only 200,000 FCT minted (half the target)
• Next period's rate increases by 2x

Scenario 2: Over-issuance

• 400,000 FCT minted in just 5,000 blocks
• Period ends early at issuance threshold
• Rate decreases by 0.5x for next period (as period took half the target time)

Scenario 3: Extreme Over-issuance

• 400,000 FCT minted in just 1,000 blocks
• Period ends very early
• Rate still only decreases by 0.5x (capped from theoretical 0.1x)

Benefits Over Overage Carry-Over

Previously, we considered carry-over—rolling any over-minted amount from one period into the next, progressively lowering the rate until the surplus was “paid back.” While that did curtail runaway issuance, it introduced complexities:

1. Delayed Punishment

   • Large over-minting in a given 10,000-block window wouldn’t affect the rate within that same window, potentially enabling bursts of “unlimited” mint at the old rate.

2. Extended Suppression

   • One big overage could suppress rates for weeks afterward, even if demand changed.

By contrast, dual-threshold logic responds immediately when overshooting occurs. If 400,000 FCT are minted long before 10,000 blocks, that period ends early and the rate is lowered right away for the new period. No leftover “hangover” from previous periods.

Potential Issue: Unpredictable mints amounts

1. Unpredictable Mint Amounts

   • Because periods can end prematurely, you might not know exactly which period your transaction will fall into at the time you send it. A single large transaction could flip the period boundary mid-block, changing the rate for transactions that follow.
   • Solution Needed: We must ensure this doesn’t break transaction hash predictability.

2. ETH Burn Tie-In

   • We’ve also proposed basing minted FCT on ETH burned rather than raw gas units. This also introduces unpredictability (users don’t know the exact base fee or block number they’ll land in).
   • Good News: The same fix that solves dynamic period unpredictability can address dynamic base fee unpredictability.

Questions for the Community

Please share your thoughts and feedback on this alternative approach. We believe it maintains the core benefits we were seeking with the carry-over mechanism while providing a cleaner, more predictable system for all participants.

Here are some “thought starters”:

• Are 10,000 blocks and 400,000 FCT per period still the right targets?
• Is the 2× or 0.5× rate change bound correct?
• Do you find this system simpler and clearer than carry-over?
• Are there any edge cases (extreme overshoot, multiple transactions in one block, etc.) that concern you?

Thank you!

[xunfa2019]

FCT Issuance: Current System, Challenges, and Potential Solutions

Hey everyone,

I want to open a discussion about our current FCT issuance system. As an early-stage protocol, we need to ensure our mechanisms are as straightforward and accessible as possible.

While many of these challenges could theoretically be addressed by a mature market over time, we're in a phase where simplicity and clarity are crucial for adoption and healthy market development.

Current System

FCT issuance is controlled by a dynamic rate adjustment mechanism that operates in 10,000-block periods (approximately 1.4 days). Here's how it works:

• The system targets 400,000 FCT per adjustment period
• Every period, the issuance rate adjusts based on how much FCT was minted in the previous period
• If more than the target amount was minted, the rate decreases proportionally (up to a maximum change of 50%)
• The target issuance rate halves every year to ensure a fixed total supply
• The amount of FCT minted per transaction is based on the gas used for calldata, multiplied by the current issuance rate

Issues We're Seeing (With Proposed Solutions)

Note: None of these solutions are final—we’re proposing them to give the community something to react to and get feedback on. Based on this feedback, we may implement one or more of them, or we might not.

Uncertain Supply Dynamics

Though the halving mechanism ensures FCT has a finite maximum supply, the current system makes it difficult to determine what this supply is. This creates uncertainty for token holders who can't accurately assess the value of their holdings in relation to the total supply.

Proposed Improvement: issuance-based halving

To address this, we propose an issuance-based halving mechanism. Instead of halving on a fixed schedule (e.g., once a year), the rate halves whenever the total FCT supply crosses specific thresholds—regardless of how long it takes to get there. This ensures a known, finite supply while responding to actual minting behavior.

1. Set a Max Supply Baseline

2. Start with 210M FCT as the “original target total supply.”

3. At the fork block, compare:

   • Actual issuance so far (“actual_issuance”)
   • Ideal issuance over that same period (“ideal_issuance,” calculated as blocks * 40 FCT)

4. Adjust the 210M target by the difference (i.e., if more than the target has been minted, increase the final supply; if less, decrease it).

Example:

• Current total issuance is 75M
• 500k blocks have passed
• Ideal issuance = 500k blocks * 40 FCT = 20M
• Difference = 75M - 20M = 55M
• Adjusted final supply = 210M + 55M = 265M

2. Determine the First Halving Threshold

From that new total, the first halving threshold is half of the adjusted supply.

• Using the example above, it’s 265M / 2 = 132.5M.

Once the total minted supply crosses this number, the first halving event triggers. Future thresholds keep halving the remaining supply.

• In the example, after crossing 132.5M, the next threshold adds another half of that bracket (132.5M / 2), bringing the next halving mark to 198.75M.

This approach clarifies the maximum possible supply and makes the timing of halvings directly dependent on how quickly (or slowly) new FCT is minted.

Dramatic Period-to-period Mint Rate Fluctuations

The current issuance mechanism creates a situation where the optimal strategy isn't simply "mint FCT when you think it's valuable relative to ETH." Instead, users must consider the mechanism itself and how others will interact with it, distorting the calculation. This leads to artificial patterns of issuance (e.g., the "seesaw effect") that aren't connected to any meaningful market signals or fundamental factors, introducing unnecessary volatility into the system.

Proposed Improvement: Overage Carry-Over

The Core Idea

Everything above 800,000 FCT in a period gets added to the next period's total.

How It Works

1. In each period:

   • First 800k FCT triggers maximum 0.5x rate reduction
   • Any amount above 800k “carries over”
   • Carried-over amount gets counted in next period's total

2. If next period's total (new minting + carry-over from previous period) exceeds 800k:

   • Rate decreases by 0.5x again
   • Excess carries forward again

Example

Period 1: Someone mints 10M FCT

• First 800k triggers 0.5x rate reduction
• Remaining 9.2M carries to Period 2

Period 2: No new minting, but we have 9.2M carried over

• First 800k triggers another 0.5x reduction
• Remaining 8.4M carries to Period 3

Period 3: No new minting, but we have 8.4M carried over

• First 800k triggers another 0.5x reduction
• Remaining 7.6M carries to Period 4

This continues until all excess minting has been accounted for.

Gas Price-driven Volatility

The volatility of Ethereum gas prices directly affects FCT minting costs—sometimes an order of magnitude more than the parameters of the FCT mechanism itself. While a mature market might develop ways to hedge or price in this risk, currently this volatility is passed directly to users, adding another layer of complexity to minting decisions.

Proposed Improvement: Base mint on ETH burn

We plan to base the FCT minting calculation on the amount of ETH burned, rather than directly on raw gas units. Specifically:

1. Measure “Data Gas” the Same Way: continue counting only the data-related gas (i.e., ignoring the initial 21,000 gas overhead and contract execution costs), just as we do today.
2. Incorporate the Block Base Fee: instead of simply multiplying these data gas units by the dynamic mint rate, we first multiply the data gas units by the block’s base fee. This yields the total ETH burned for the data portion of the transaction.
3. Derive FCT Mint from ETH Burned: that ETH-burn figure is then fed into the mint rate calculation. If gas prices spike and base fees are high, it costs more ETH to send data—but more FCT is also minted. Conversely, if gas prices are low, the mint output decreases in proportion.

By tying minted FCT to the actual ETH burn, we neutralize the wild swings in gas prices. Users no longer have to worry about timing their transactions to avoid expensive gas intervals; if they do pay more in ETH due to higher base fees, they’ll proportionally receive more FCT in return.

Technical Constraints

As we think about addressing these issues, there are some important technical constraints to keep in mind:

1. The amount of FCT minted in a transaction must be predictable before the transaction is included in a block (so that users can pre-calculate their transaction hashes)
2. The issuance rate cannot go to zero, as some FCT must always be available for gas fees
3. Any changes need to be forward-looking to protect existing holders

Community Input Needed

We'd appreciate your thoughts on:

1. Supply Dynamics

   • Is issuance-based halving clearer than time-based?
   • Are the threshold calculations intuitive?

2. Rate Mechanism

   • Should we keep 0.5x/2x adjustment limits?
   • Is 10,000-block period still appropriate?

3. Gas Price Impact

4. General

   • How do these issues affect your FCT interaction?
   • What aspects of the current system should we preserve?
   • Which improvements should we prioritize?

Please share your thoughts and experiences in the comments below. We want to ensure any future improvements are informed by the needs and insights of our community!

The model based on halving the issue has a more controllable casting rate than the model based on halving the time.
I've noticed that people have already minted 75M FTC, and at that rate more will soon be mined, while halving by time effectively loses its meaning. Also, if we go with the new casting method, what happens to the original mined FCT, fork the new chain?

[tunnckoCore]

@xunfa2019: what happens to the original mined FCT, fork the new chain?

Nothing. It will only apply to new transactions. The supply and what people hold will remain.

[RogerPodacter]

@xunfa2019: This is a great question and one of the aspects of the mechanism we'd like feedback on! One way of aligning the new system with the old is laid out above:

1. Set a Max Supply Baseline

Start with 210M FCT as the “original target total supply.”
At the fork block, compare:
Actual issuance so far (“actual_issuance”)
Ideal issuance over that same period (“ideal_issuance,” calculated as blocks * 40 FCT)
Adjust the 210M target by the difference (i.e., if more than the target has been minted, increase the final supply; if less, decrease it).
Example:

Current total issuance is 75M
500k blocks have passed
Ideal issuance = 500k blocks * 40 FCT = 20M
Difference = 75M - 20M = 55M
Adjusted final supply = 210M + 55M = 265M

But this is just an idea to get the conversation going. There are other ways we could do this. What do you think?

[xunfa2019]

@xunfa2019: This is a great question and one of the aspects of the mechanism we'd like feedback on! One way of aligning the new system with the old is laid out above:

1. Set a Max Supply Baseline

Start with 210M FCT as the “original target total supply.” At the fork block, compare: Actual issuance so far (“actual_issuance”) Ideal issuance over that same period (“ideal_issuance,” calculated as blocks * 40 FCT) Adjust the 210M target by the difference (i.e., if more than the target has been minted, increase the final supply; if less, decrease it). Example:

Current total issuance is 75M 500k blocks have passed Ideal issuance = 500k blocks * 40 FCT = 20M Difference = 75M - 20M = 55M Adjusted final supply = 210M + 55M = 265M

But this is just an idea to get the conversation going. There are other ways we could do this. What do you think?

@RogerPodacter
Potential Concerns
While I support this approach, there are a couple of points to consider:

1.Perception of Inflation:
Increasing the total supply from 210M to 265M might concern some stakeholders who expected a firmer cap. Clear communication about why this adjustment reflects the network’s history (e.g., higher early rewards) could mitigate this.

2.Assumption of Intent:
The method assumes the original intent was to issue 40 FCT per block until reaching 210M over 5,250,000 blocks. If Factom’s original model was different (e.g., uncapped or inflationary), this adjustment might not fully align with that vision. Clarifying the historical context would strengthen the proposal.

Alternative Approaches
While I think your method is solid, here are some other ways to handle this alignment, along with their pros and cons:
Fix Total Supply at 210M and Adjust Future Issuance:
Keep the max supply at 210M, so remaining issuance = 210M - 75M = 135M FCT.
Distribute this over the future blocks according to a new schedule.
Pros: Maintains the original cap, appealing to those who value a fixed supply.
Cons: Reduces future issuance below the planned 190M, potentially seen as unfair or a rule change mid-game.
Ignore Past Discrepancies and Set a New Schedule:
Accept the current 75M FCT as is and define a new total supply (e.g., 250M) or issuance rate going forward, independent of past ideal targets.
Pros: Simplifies the transition by focusing only on the future.
Cons: Creates a discontinuity with the original plan, possibly disrupting expectations.
Adjust Issuance Rate to Converge to 210M:
Calculate a reduced issuance rate moving forward (e.g., less than 40 FCT per block) to reach 210M over the remaining blocks.
Pros: Preserves the original cap without immediate supply changes.
Cons: Complicates the issuance schedule and lowers future rewards, which might be unpopular.
One-Time Token Burn:
Burn excess FCT (e.g., 55M) to align actual issuance with the ideal (20M), then proceed with the original 210M target.
Pros: Restores the original plan exactly.
Cons: Highly controversial, technically challenging, and could upset holders of existing FCT.

Recommendation
I believe your proposed method—adjusting the final supply based on the difference between actual and ideal issuance—is the best approach. It:
Maintains the intended future issuance (190M FCT in the example).
Fairly accounts for past over-issuance without penalizing future participants.
Is simple to implement and explain.
Compared to alternatives, it avoids abrupt changes (like burns or rate adjustments) that could disrupt the community or network dynamics. My only suggestion is to clearly explain the historical context (e.g., why actual issuance exceeded the ideal) to ensure stakeholder buy-in.
What do you think about this feedback? I’d be happy to discuss further!