Fee grant via RPGF funding to support IBC relayer operators until phase 5 of mainnet

PGF Ops Proposal 🗳️
1

Hey everyone!

As Mandragora is leading IBC channels creation and maintenance for Namada’s mainnet (along with collaboration for supporters information collection with @CosmicValidator), I have detected a problem, but I found out a temporary potential solution that may even be used in the future.

Problem

We have detected that indeed genesis accounts are needed to be used as relayer accounts, just like in Housefire testnet, but that could be problematic when it comes to mainnet. We have had to inevitably use a genesis account to proceed in our case, but we have been thinking of a workaround for the rest of the supporters that are going to join forces for IBC relayer operations in Namada.

Solution

It consists in funding supporters’ Namada relayer accounts via a PGF proposal - as a fee grant to support them and to avoid using genesis accounts as relayer accounts on mainnet. Retroactive funding (RPGF) would let to directly send them a fee grant in NAM from the PGF Treasury account.

We would propose an initial amount of 5-10k NAM per each supporter Namada relayer account to effectively sustain/maintain IBC relayer operations until phase 5 of mainnet.

Comments

These funds couldn’t be used for other purposes, and supporters’ relayer accounts would be monitored from time to time - I do think that all operators with the IBC relayer role at Discord are enough trusted in Namada’s community and/or within the Interchain ecosystem, so a priori there’s no need to worry about it.

We plan to put this proposal on-chain as soon as possible, so we would appreciate thoughts on it, especially in regard to NAM token amount per each supporter.

@cwgoes @adrian @Gavin @brentstone @Fraccaman @yito88

14 Likes
2

I agree, this would be best for avoiding the use of genesis accounts. I think it should be put to a vote :+1:

3 Likes
3

We support this initiative!

3 Likes
4

I like this idea. I’m supporting it.

3 Likes
5

Support this proposal!

  1. But we should to collect relay addresses more securely than in an open google-table.

  2. And I think 5k NAM per address will be enough for the first time ( if I understood this part of proposal correctly). The main problem with addresses is that there is no way to transfer funds. I don’t want to use the main wallet for the relayer.

3 Likes
6

  1. Agree - let’s first collect relayer addresses, and then have a final check for operators to verify if they are correct before proceeding with the on-chain proposal.

  2. That’s correct. On the other hand, you can just set a new transparent address, RPGF distribution mechanism can make the job even though native token transfers aren’t enabled yet, so no worries.

3 Likes
7

We support funding a separate account for relaying. Going to add our wallet info on spreadsheet soon.

1 Like
8

Good idea @Daniel!

Support this as well. I’ll add my info to the sheet today!

2 Likes
9

good idea, supporting this

1 Like
10

Thanks for raising the issue! If it’s helpful, I (on behalf of Luminara) am happy to champion this proposal.

We should be clear about the purpose of the NAM–is this purely to pay relayer fees? Are we intending to reward operators in a separate PGF proposal?

@Daniel, @brentstone, if you’d like us to draft the proposal, could you please collect the list of addresses (along with any other info about these recipients that you think voters should know)? And could you find a bit of consensus around the number of NAM for each address?

1 Like
11

We also Support this.

1 Like
12

This proposal would be just to cover relayer fees until phase 5, aiming to have a strong relaying efforts since the beginning of phase 3, which is crucial for a smooth UX at early stages. In regard to reward operators in a separate PGF proposal, well, not sure to be honest, as it wasn’t the idea behind this one :sweat_smile:

We are already collecting addresses in the spreadsheet above - my idea is that once few more operators are onboarded, we can move forward. I will wait until tomorrow morning (Barcelona’s timezone) to collect the addresses, double-check if they are correct by tagging respective operators at Discord, and then proceed with submitting the proposal on-chain perhaps on late night once operators finally confirm their addresses.

I do believe that having close to 10 operators and funding them with 5k NAM each would be enough to cover fees until phase 5 of mainnet, and probably more, so once we reach out such a phase we can revisit the same or similar fee grant funding model in case we consider it necessary to keep things rolling smoothly.

4 Likes
13

hey @Daniel are relayer costs that high on Namada? do we have a metric?

wondering if there’s an issue with compute (gas consumption) or cost (gas fee rate)

14

You can see in here that e.g. every IBC client update transaction costs like 0.10-12 NAM. As we can’t replicate yet mainnet conditions with constant flow of transactions coming in and out, we can’t have an exact metric, but a vague estimation instead. In Housefire testnet, without having a constant flow of transactions - i.e. most of them being IBC client update transactions, it took like 700-800 NAM in less than a month. So, taking that into account, I opted to have a “better a bit too much than not enough” vision.

2 Likes
15

I agree and support this idea.

1 Like
16

We will support this proposal for sure , with the cost of ibc , feegrant is the best option to run smooth operations

1 Like
17

We will definitely support this proposal and contribute to the operation of IBC infrastructure for Namada.

1 Like
18

so much is spent on IBC fees in namada… 5k-10k seems like a lot

19

Thanks for your feedback!

The final amount that will be proposed per IBC relayer operator willing to join forces (13 in total, which is a signal of the strongness of IBC relaying efforts) is 3,850 NAM, distributing a total of 50,050 NAM. The on-chain proposal will be live soon.

1 Like
20

Proposal with ID 7 is now submitted on-chain. Voting period starts at epoch 303 and ends at epoch 315 (activation at epoch 316).

namadac query-proposal --proposal-id 7 --node https://namada-rpc.mandragora.io
Last committed epoch: 302
Proposal Id: 7
Type: PGF funding
Author: tnam1q8sjkutd5kqwcc555wr77p9fjn66nuuqfuzzc3yc
Content: {"abstract": "PGF proposal to distribute total of 50,050 NAM so as to fund 13 Namada IBC relayer operators operations - 3,850 NAM each.", "authors": "Daniel (Mandragora)", "created": "2025-02-17", "details": "## Author\nDaniel from Mandragora validator is submitting this proposal.\n\n## Context\nAs Mandragora is leading IBC channels creation and maintenance for Namada’s mainnet (along with collaboration for supporters information collection with Cosmic Validator), I have detected a problem, but I found out a potential.\n\n## Problem\nWe have detected that indeed genesis accounts are needed to be used as relayer accounts, just like in Housefire testnet, but that could be problematic when it comes to mainnet.\n\n## Solution\nIt consists in funding supporters’ Namada relayer accounts via a PGF proposal - as a fee grant to support them and to avoid using genesis accounts as relayer accounts on mainnet. Retroactive Public Goods Funding (RPGF) mechanism lets to directly send them the fee grant from the PGF Treasury.\n\n## Proposed amount\nWe are proposing to distribute total of 50,050 NAM, i.e. 3,850 NAM to 13 IBC relayer operators.\n\n##Comments\nThese funds couldn’t be used for other purposes, and relayer accounts would be monitored from time to time.\n\n## IBC Relayer Operators\nThese are Mandragora, Cosmic Validator, Sproutstake, max-02, pro-nodes75, Architect Nodes, OriginStake, Stake&Relax, anodeofzen, ContributionDAO, ValidatorVN, Inter Blockchain Services and Citizen Web3.", "discussions-to": "https://forum.namada.net/t/fee-grant-via-rpgf-funding-to-support-ibc-relayer-operators-until-phase-5-of-mainnet/1527", "motivation": "(see abstract)", "requires": "", "title": "PGF - Fee grant to support Namada IBC relayer operators"}
Start Epoch: 303
End Epoch: 315
Activation Epoch: 316
Status: pending
Data: Actions:
  Retroactive: Internal address=tnam1qp467577tlh0r3kl8xekxrj8ea3r898ffszn7q4d, amount=3850000000
  Retroactive: Internal address=tnam1qp6cxlnl97xaxk9ey7tqtz0605gqgjz2hvcnfgt2, amount=3850000000
  Retroactive: Internal address=tnam1qp8ctrxp62eqw6hnnm2q42zpl8js2pk8f5jxtzgt, amount=3850000000
  Retroactive: Internal address=tnam1qp8fnu6nqwprcd25pl44mv0qmkvxt0gj9qcptehl, amount=3850000000
  Retroactive: Internal address=tnam1qqwv4vmsec0870tha6vzw4mmwfq6h0sv4gpnz29n, amount=3850000000
  Retroactive: Internal address=tnam1qqxnkp7spz6xs3er6xw9k3rjm9lxl78k95vxrnfd, amount=3850000000
  Retroactive: Internal address=tnam1qr4fn9smk8hh2s3nm4rqq93wh2exf32gpu6spl7q, amount=3850000000
  Retroactive: Internal address=tnam1qr4xqmsrnzsh7xnkzykvrm6f2nw0eps2l5zvudts, amount=3850000000
  Retroactive: Internal address=tnam1qr6nhs8mjj2n9ra5n2ukw32068qw2w3y45wlk8tc, amount=3850000000
  Retroactive: Internal address=tnam1qr8z58egh28eh5k7ed4jwt646acerlzs0q6r2u0n, amount=3850000000
  Retroactive: Internal address=tnam1qrz2z0urlywgh23crnm7jjhs0y9sy43rq5xnny82, amount=3850000000
  Retroactive: Internal address=tnam1qz4349xxw53a2hhnnejvth048xx0dgzgz5q2pckd, amount=3850000000
  Retroactive: Internal address=tnam1qzxw2ls5vene79qlelves5ukaqykldm00gec8xt0, amount=3850000000
6 Likes