how many cryptographers does it take to design sustainable economics? apparently
more or less than labs had. this is proposal about introducingartificial scarcity to the
system with governance-led policy.
abstract
penumbra currently operates as a charity. users pay $0.000009 for private ibc
while relayers subsidize their exits 2,200x. this proposal examines penumbra’s
4-dimensional fee structure and proposes targeting ibc withdrawals specifically -
our primary service to the external world - while keeping internal usage cheap.
the product we sell
to internal users: private transactions, swaps, staking, governance.
to the external world: privacy-as-a-service for ibc assets. bridge in,
hold privately, withdraw when ready. that’s the core product. currently free.
relayer fees considered, our community pays for it.
how penumbra fees work
the four dimensions
gas {
block_space: u64, // bytes in blocks
compact_block_space: u64, // light client data
verification: u64, // zk-snark verification
execution: u64, // state machine ops
}
current prices: block_space: 60, compact_block: 1556, verification: 1, execution: 1
fee = sum of (price × gas) / 1000 per dimension.
per-action gas costs
| action | block | compact | verif | exec |
|---|---|---|---|---|
| spend | 352 | 34 | 1000 | 10 |
| output | 560 | 240 | 1000 | 10 |
| swap | ~800 | 272 | 1000 | 10 |
| delegate | ~150 | 0 | 0 | 10 |
| ics20_withdrawal | ~250 | 0 | 0 | 10 |
ibc withdrawals are the cheapest action - zero verification, zero compact block.
where fees go
fees are burned. more usage = scarcer supply = sound money.
crypto adoption runs on number-go-up technology.
burns → scarcity → price → attention → adoption. a well-funded penumbra does
more for privacy than a technically-pure ghost chain.
think eberhard/tesla phasing: roadster → model s → model 3. start premium,
scale to mass adoption.
now we are selling the gucci of privacy, and our fees should match that luxury.
well, as long as our user base is limited. and in success case scaling to larger
user bases would be just reducing fees via governance. some perks of having the
most scalable design in all of the crypto.
tokenomics
| metric | value |
|---|---|
| total supply | 100.5m um |
| annual issuance | ~2.0m um/year |
| total burned (all time) | 75.5k um |
| current price | ~$0.02 |
we issue max 2 million um/year but have only burned 75,500 um total. we’re
printing 26x faster than burning. currently the burn mechanism in its function
is decorative. fees are so low that we would be better off not charging them
than status quo(i do belive that calculating proofs would allow feeless usage
due to assymetry in our favor in proving/verifying).
current state
a withdrawal costs ~500 upenumbra = $0.000009.
| chain | withdrawal fee | service |
|---|---|---|
| noble | $0.01-0.02 | transparent ibc |
| osmosis | $0.002 | transparent ibc |
| penumbra | $0.000009 | private ibc |
we charge 1000x less than noble for infinitely more privacy.
the relayer subsidy
user pays $0.000009, relayer pays ~$0.04 on noble. subsidy ratio: 4,000x.
at 1,500 monthly withdrawals: $0.15/year burned. we literally pay people to
extract value.
the asymmetry argument
| action | economic impact | optimal fee |
|---|---|---|
| deposit | value flows in | low/free |
| internal tx | neutral | moderate |
| withdrawal | value flows out | higher |
deposits bring liquidity. withdrawals extract it after using our privacy.
we charge the same near-zero fee for both. this utterly lacks any economic
design and is solely calculated to enable maximum usage of the chain. well the
usage is not there yet so we should charge accordingly.
the problem
governance can only change prices (global multipliers). all actions have
execution: 10, so increasing execution_price affects everything equally.
we can’t target withdrawals without code changes.
proposed solution
phase 1: governance signal
raise execution_price: 1 -> 100 via governance.
context: fee parameters were last tuned when um traded at ~$1.50. now at ~$0.015,
that’s a 100x price drop. a 100x increase in execution_price just restores original
usd-equivalent fees.
effect on all actions:
| action | current fee | after 100x exec_price | usd change |
|---|---|---|---|
| send (spend+output) | ~500 upen | ~510 upen | +$0.00000015 |
| swap | ~530 upen | ~540 upen | +$0.00000015 |
| delegate | ~150 upen | ~160 upen | +$0.00000015 |
| withdrawal | ~500 upen | ~510 upen | +$0.00000015 |
all actions have execution: 10, so 100x price increase adds ~10 upen per action.
at current um price: +$0.00000015 per tx. still unnoticeable.
purpose: tests community willingness for sustainable economics before investing
dev time. if governance rejects even this minimal change, no point proceeding.
phase 2: code upgrade
change ics20_withdrawal.execution: 10 -> 5_000_000:
// crates/core/transaction/src/gas.rs
impl gas_cost for ics20_withdrawal {
fn gas_cost(&self) -> gas {
gas {
block_space: self.encode_to_vec().len() as u64,
compact_block_space: 0,
verification: 0,
execution: 5_000_000, // was 10
}
}
}
with execution_price at 100 from phase 1:
| action | before | after | change |
|---|---|---|---|
| send | ~510 upen | ~510 upen | - |
| swap | ~540 upen | ~540 upen | - |
| withdrawal | ~510 upen | ~500,000 upen | +1000x |
withdrawal fee: $0.000009 → $0.0075. internal usage unchanged.
governance can tune execution_price further (lower = cheaper withdrawals, higher = more burn).
burn projections
| scenario | annual burn | % of issuance |
|---|---|---|
| current | ~900 um | 0.045% |
| phase 1 only | ~1,000 um | 0.05% |
| phase 1+2 @ 1.5k/mo | ~9,000 um | 0.45% |
| phase 1+2 @ 15k/mo | ~90,000 um | 4.5% |
| at scale (150k/mo) | ~900,000 um | 45% |
phase 3: the 5th dimension
hacking execution conflates resource cost with policy. proper solution: add a
5th “policy” dimension, governance-tunable per-action:
policy_costs: Map<ActionType, u64> { // in chain state, not code
ics20_withdrawal: 5_000_000,
position_close: 100_000,
spend: 0, output: 0, swap: 0, ...
}
no code changes ever needed for fee adjustments - pure governance.
to show that we are actually alive and well, we should drive for more active
onchain governance. enabling more actions for the community to vote on should be
positive. there’s always bitcoin for stagnant economics.
implementation: ~1 week. backwards compatible (proto3 defaults to 0). we do seem
to lack a bit expertise nowadays so more likely to be bottlenecked by reviews
and broader testing.
why this matters
- hyperdeflation protection: if burns exceed issuance, governance can lower
fees without code changes - governance purpose: with labs gone, what’s there to vote on? this gives
delegators real economic decisions - complete toolkit: handles both current charity problem and future success
counterarguments
“higher fees reduce usage” - users choose penumbra for privacy, not because
it’s free. $0.01 won’t change that.
“wait for higher um price” - might not happen, and more likely to happen
with more sound economics. circular. burns support price.
“hurts adoption” - subsidized usage isn’t adoption. freeloaders aren’t users.
conclusion
penumbra is one of the only privacy solutions for ibc. we charge nothing for it.
instead we’ve been running a charity to the point of bankruptcy.
tldr proposed changes:
- increase withdrawal fees: $0.000009 → $0.001-0.01 (still cheap at level that
should not hinder adoption) - internal usage: essentially unchanged
- burn revenue: 1000x improvement
- governance tunability preserved
this is rfc to look for some discussion on subject before proposal or possible UIP.
