Fund Terra Classic IBC Relaying Activity Q3/Q4 2026

Proposals
1

Fund Terra Classic IBC Relaying Activity

May–December 2026 Continuation Mandate by Bumeo Capital B.V. and LuncGoblins

Summary

This proposal requests Community Pool funding for the continued operation of Terra Classic IBC relaying infrastructure for the period from May 1, 2026, through December 31, 2026.

The mandate will be jointly delivered by:

  • Bumeo Capital B.V., responsible for providing the required server infrastructure, financial administration, fund management, business coordination and community communications.
  • LuncGoblins, operated by Till Ziegler, responsible for the full technical and operational management of the IBC relayer infrastructure.

This proposal is a continuation of Proposal #12198 — “Fund Terra Classic IBC Relaying Activity.”

The technical scope of the previous proposal remains unchanged. The relaying infrastructure will continue to support the existing IBC connections between Terra Classic and:

  • Osmosis
  • Noble
  • Axelar

The requested funding period covers eight months.

Part of the requested funding is retrospective because the relaying infrastructure continued to be operated after the previous funding mandate expired. The associated server, feed and relaying costs were carried privately during this funding gap.

No working hours or labor fees are requested under this proposal.

The total requested budget is:

  • €10,000 excluding VAT
  • €2,100 Dutch VAT at 21%
  • €12,100 total

The final Community Pool spend amount will be denominated in LUNC using the applicable LUNC/EUR market price when the on-chain Community Pool Spend Proposal is prepared.

Background

IBC relayers are essential infrastructure for communication between independent Cosmos-based blockchains.

IBC messages are not automatically transmitted between chains. Relayer infrastructure is required to monitor both chains, submit transactions and ensure that IBC packets are successfully delivered.

Without active and properly funded relayers:

  • IBC transfers may become delayed.
  • Packets may remain unrelayed.
  • Users may temporarily lose access to cross-chain liquidity.
  • Applications relying on bridged assets may be disrupted.
  • Terra Classic may become less accessible to the wider Cosmos ecosystem.

Proposal #12198 funded Terra Classic IBC relaying activity for an initial six-month period.

That mandate covered the continued operation of relayers connecting Terra Classic with Osmosis, Noble and Axelar.

After the funded period ended, the relaying infrastructure continued to be operated. The associated costs were not covered by a new Community Pool mandate and were therefore paid privately.

This proposal closes that funding gap and secures the continued operation of the same infrastructure until December 31, 2026.

Proposal Period

The requested mandate covers:

May 1, 2026, through December 31, 2026

This is a total period of eight months.

The portion between May 1, 2026, and the execution of this proposal represents retrospective reimbursement for infrastructure and relaying services that continued to be provided during the funding gap.

The remaining portion represents prospective funding through December 31, 2026.

Scope of the Mandate

The scope remains materially unchanged from Proposal #12198.

The mandate covers the continued operation and maintenance of Terra Classic IBC relaying infrastructure for the existing routes involving:

  1. Terra Classic and Osmosis
  2. Terra Classic and Noble
  3. Terra Classic and Axelar

The mandate includes:

  • Provisioning and maintaining the required server infrastructure
  • Operating the relevant IBC relayer software
  • Monitoring relayer activity
  • Maintaining sufficient operational balances for relaying transactions
  • Managing software updates and configuration changes
  • Responding to relayer incidents
  • Resolving operational issues affecting packet delivery
  • Communicating major outages or planned maintenance to the community
  • Coordinating with relevant infrastructure providers and ecosystem participants when necessary

This proposal does not request funding for the development of new bridges, new IBC implementations or additional IBC routes.

Any material expansion of the technical scope would require separate disclosure or a future governance proposal.

Responsibilities

Bumeo Capital B.V.

Bumeo Capital B.V. will act as the organizational and financial mandate holder.

Bumeo Capital will be responsible for:

  • Providing the server infrastructure required for the relayer operations
  • Paying server and infrastructure providers
  • Paying the required feed-service costs
  • Receiving and administering the Community Pool funding
  • Maintaining financial records for the mandate
  • Managing the separately reserved relaying-fee allocation
  • Supplying operational funds to the relevant relayer wallets
  • Coordinating the business and administrative aspects of the mandate
  • Publishing community communications concerning major outages or maintenance
  • Acting as the primary organizational contact for the Terra Classic community
  • Coordinating communication between LuncGoblins, validators, projects and other relevant stakeholders

Bumeo Capital will provide the infrastructure and financial resources required for the mandate but will not interfere with day-to-day technical decisions made by LuncGoblins.

LuncGoblins / Till Ziegler

LuncGoblins, operated by Till Ziegler, will retain full technical and operational authority over the relayer infrastructure.

LuncGoblins will be responsible for:

  • Technical configuration of the relayers
  • Selection and management of relayer software
  • Deployment and software updates
  • Monitoring the relayer infrastructure
  • Operational key and wallet management where required
  • Client, connection and channel management
  • Incident response
  • Troubleshooting relayer failures
  • Managing packet-relaying issues and timeouts
  • Restoring services following technical interruptions
  • Making technical decisions necessary to maintain reliable relayer operations
  • Coordinating with external technical teams where required

LuncGoblins will have full authority over technical operations.

Bumeo Capital will not override technical or operational decisions made by LuncGoblins concerning the safe and reliable operation of the relayer infrastructure.

Cost Calculation

The previous proposal included server costs, feed-service costs and compensation for working hours.

Under this proposal:

  • Server costs are updated from €130 to €150 per server per month.
  • No working hours or labor compensation are requested.
  • A separate relaying-fee budget of €250 per month is introduced.

The relaying-fee allocation reflects the actual transaction and operational fees that have previously been paid privately by LuncGoblins.

These costs have generally been approximately €150 per month but can be higher depending on network activity, transaction fees and operational requirements.

A budget of €250 per month provides a reasonable operational buffer and reduces the risk that relayer activity must again be financed privately.

Monthly Budget

Cost item Monthly cost
Server infrastructure for four chains: 4 × €150 €600
Feed services: 4 × €100 €400
Separately reserved relaying fees €250
Working hours and labor €0
Monthly total excluding VAT €1,250

Eight-Month Budget

Cost item Eight-month cost
Server infrastructure €4,800
Feed services €3,200
Relaying-fee allocation €2,000
Working hours and labor €0
Total excluding VAT €10,000
Dutch VAT at 21% €2,100
Total requested funding €12,100

No Labor Compensation

No working hours, management fees or labor compensation are being charged under this proposal.

The requested funding is limited to:

  • Server infrastructure
  • Feed services
  • Relaying transaction and operational fees
  • Applicable Dutch VAT

The technical operation performed by LuncGoblins and the business, administrative and communications work performed by Bumeo Capital are not included as separate labor-cost positions.

Separate Management of Relaying Fees

The €250 monthly relaying-fee allocation will be managed separately from the general infrastructure funds.

For the full proposal period, a total of €2,000 will be reserved for relaying fees.

These funds will be used exclusively for:

  • IBC relayer transaction fees
  • Gas costs
  • Funding designated relayer wallets
  • Directly related operational blockchain fees required to maintain relaying activity

The relaying-fee allocation will not be used for:

  • Server invoices
  • Feed-service invoices
  • Salaries
  • Contractor compensation
  • General Bumeo Capital expenses
  • Unrelated protocol development
  • Marketing
  • Other business expenses

Bumeo Capital will maintain a separate accounting record for these funds.

Where technically and operationally practical, the relaying-fee allocation will also be held in a separate designated wallet or account to prevent commingling with other funds.

Any unused amount will remain restricted to future relaying costs during the mandate period.

The remaining balance will be transparently disclosed at the conclusion of the mandate.

Retrospective Funding

The previous Community Pool mandate expired before the beginning of the period covered by this proposal.

However, the relayer infrastructure continued to operate.

The retrospective portion of this proposal is therefore not a request for payment for services that were suspended or not delivered.

It is a request to reimburse the infrastructure and operational costs that continued to be incurred from May 1, 2026, while no active Community Pool funding mandate was in place.

During this period:

  • Required infrastructure remained active.
  • Server costs continued to be incurred.
  • Feed-service costs continued to be incurred.
  • Relaying fees were funded privately.
  • Technical oversight continued to be provided by LuncGoblins.

Approving the retrospective portion prevents essential public infrastructure from remaining dependent on indefinite private funding.

It also establishes a clear and transparent mandate for the remaining period through December 31, 2026.

VAT Treatment

Bumeo Capital B.V. is a company established in the Netherlands.

This proposal applies the Dutch standard VAT rate of 21% on a precautionary basis.

The total VAT allocation is:

€2,100

The VAT amount is included because the Community Pool payment may be treated as consideration for identifiable infrastructure and operational services provided by Bumeo Capital B.V.

However, the final VAT treatment depends on the applicable Dutch tax and accounting assessment.

If Bumeo Capital’s accountant, tax adviser or the Dutch tax authorities determine that VAT is not payable on this Community Pool funding, Bumeo Capital will return the corresponding VAT allocation to the Terra Classic Community Pool.

The amount to be returned will be the LUNC amount originally allocated to the €2,100 VAT component when the final Community Pool Spend Proposal is calculated.

Any VAT correction and return will be publicly documented.

Financial Administration

The Community Pool funding will be received and administered by Bumeo Capital B.V.

Recipient wallet:

[RECIPIENT WALLET TO BE PROVIDED]

Bumeo Capital will be responsible for:

  • Recording the received LUNC
  • Recording its EUR value using the applicable accounting method
  • Allocating funds according to the approved budget
  • Paying infrastructure and feed-service providers
  • Reserving the relaying-fee allocation separately
  • Maintaining supporting financial records
  • Documenting any VAT payment, adjustment or return
  • Providing a concluding financial summary for the mandate

The final on-chain Community Pool Spend Proposal will specify the exact LUNC amount requested.

The LUNC amount will be calculated based on the approved total budget of €12,100 and a clearly disclosed LUNC/EUR reference price used immediately before the on-chain proposal is submitted.

Communications and Transparency

Bumeo Capital will serve as the primary communications contact for the mandate.

The community will be informed of:

  • Major relayer outages
  • Material service interruptions
  • Significant planned maintenance
  • Material changes affecting the covered IBC routes
  • Any situation that prevents the infrastructure from operating as intended
  • Material financial deviations from the approved mandate

Routine technical interventions that do not materially affect users do not require separate public announcements.

At the conclusion of the mandate, Bumeo Capital and LuncGoblins will provide a summary covering:

  • The period of operation
  • The routes maintained
  • Major incidents or outages
  • Material maintenance activity
  • Infrastructure costs
  • Feed-service costs
  • Relaying-fee expenditure
  • Remaining restricted relaying-fee balances
  • VAT treatment
  • Any funds returned to the Community Pool

Why the Community Pool Should Fund This Infrastructure

IBC relayers provide shared infrastructure that benefits Terra Classic as a whole.

Reliable relaying supports:

  • Access to Cosmos liquidity
  • Movement of assets between Terra Classic and connected chains
  • USDC availability through Noble
  • Liquidity access through Osmosis
  • Cross-chain applications
  • Wallet and user interoperability
  • DeFi applications that depend on IBC assets
  • Future ecosystem development

The benefits are not limited to one validator, one protocol or one company.

The infrastructure is publicly available and supports users and applications across the Terra Classic ecosystem.

Without sustainable funding, the costs of maintaining this public infrastructure fall on individual operators.

This creates unnecessary operational risk and makes Terra Classic dependent on private parties indefinitely subsidizing essential infrastructure.

This proposal provides a defined, transparent and time-limited mandate while removing labor compensation from the Community Pool request.

Changes Compared With Proposal #12198

The underlying technical mandate remains unchanged.

The principal changes are:

  1. The mandate covers May 1 through December 31, 2026.
  2. The proposal includes retrospective reimbursement for the funding gap.
  3. Server costs increase from €130 to €150 per server per month.
  4. No working hours or labor costs are charged.
  5. A separately managed relaying-fee budget of €250 per month is introduced.
  6. Bumeo Capital B.V. provides the server infrastructure.
  7. Bumeo Capital B.V. manages the financial administration.
  8. Bumeo Capital B.V. manages business coordination and community communications.
  9. LuncGoblins retains full technical and operational authority.
  10. Dutch VAT at 21% is included on a precautionary basis.
  11. If VAT is determined not to be payable, the corresponding allocation will be returned to the Community Pool.

No expansion of the covered IBC routes is requested.

Requested Governance Action

This proposal asks the Terra Classic community to approve:

  • The continued funding of Terra Classic IBC relaying infrastructure for Osmosis, Noble and Axelar
  • The mandate period from May 1, 2026, through December 31, 2026
  • Retrospective reimbursement for the portion of the mandate already completed
  • Prospective funding through December 31, 2026
  • A net operational budget of €10,000
  • A precautionary Dutch VAT allocation of €2,100
  • Total Community Pool funding equivalent to €12,100 in LUNC
  • Bumeo Capital B.V. as the infrastructure provider, financial administrator and communications representative
  • LuncGoblins, operated by Till Ziegler, as the technical and operational authority
  • Separate and restricted management of the €2,000 relaying-fee allocation

Voting Options

YES

Approve the proposed IBC relaying mandate and authorize Community Pool funding equivalent to €12,100 in LUNC for the period from May 1 through December 31, 2026.

NO

Do not approve the proposed mandate or Community Pool funding.

NO WITH VETO

The proposal is considered harmful, fraudulent or an abuse of the governance process, and the proposal deposit should be burned.

ABSTAIN

Participate in governance without expressing support or opposition.

Conclusion

IBC relaying is essential infrastructure for Terra Classic’s connection to the wider Cosmos ecosystem.

The infrastructure continued to operate after the previous mandate expired, with costs being covered privately during the funding gap.

This proposal provides a transparent continuation mandate through December 31, 2026.

It maintains the technical scope of Proposal #12198 while improving the operational structure:

  • Bumeo Capital provides and finances the server infrastructure.
  • Bumeo Capital manages funds, accounting and communications.
  • LuncGoblins retains full authority over technical operations.
  • No labor costs are charged.
  • Relaying fees are reserved and managed separately.
  • VAT is handled conservatively and returned if it is ultimately not payable.

The requested total is the LUNC equivalent of €12,100, including precautionary Dutch VAT.

1 Like
2

On the retrospective funding:
1Why wasn’t a renewal proposal submitted before Proposal #12198 expired, to avoid the funding gap entirely?
2Can you provide invoices or records for the server, feed, and relaying costs incurred during the unfunded period, to substantiate the retrospective claim?
3What steps will you take going forward to ensure funding requests are submitted with enough lead time to avoid future retrospective gaps?
On cost details: 4. What specifically justifies the server cost increase from €130 to €150/month per server — provider price increase, added capacity, or something else?

  1. Can you share the actual invoices/quotes from the feed-service and server providers to verify the €150 and €100 monthly figures?

On accountability and wallets:

  1. Please confirm and publish the recipient wallet address before this goes to an on-chain vote.

  2. Will the separate relaying-fee wallet address also be published on-chain or otherwise made publicly verifiable, so the community can audit fund usage in real time rather than only at mandate-end?

  3. Is there any interim (e.g. monthly or quarterly) reporting planned, or only a summary at the end of the 8-month mandate?

On governance/oversight:

  1. Given Bumeo Capital handles the funds and LuncGoblins handles the technical work, what mechanism exists for either party — or the community — to flag concerns about the other’s performance during the mandate?

  2. Were there any delays, disputes, or unmet commitments under Proposal #12198 that the community should be aware of?

On VAT:

  1. What is the expected timeline for determining whether VAT is actually payable, and how/when will any refund to the Community Pool be executed and disclosed?
3

Thank you @Murik33 for your exhaustive set of questions.

Answers below follow the order and grouping of the questions as asked. Where a
question asks for documents or addresses, those are listed explicitly rather
than promised in general terms.

On the retrospective funding

1. Why wasn’t a renewal proposal submitted before Proposal #12198 expired, to avoid the funding gap entirely?

Because there was no renewal process in place — only an operating relayer.

Proposal #12198 funded a fixed six-month period. It did not include a renewal
trigger, a deadline, or a named party responsible for preparing a successor
proposal. When the funded period ended, the infrastructure kept running because
stopping it would have broken IBC transfers for users; the paperwork simply had
no owner. In parallel, the organizational side of the mandate was being moved to
Bumeo Capital B.V. so that infrastructure procurement, accounting and community
communication would no longer sit with a single individual. That restructuring
is what this proposal formalizes, and it is the reason the renewal arrived after
the expiry rather than before it.

The honest summary: the technical work was continuous, the governance process
around it was not. It is worth noting who carried the consequence of that — the
service continued, the community paid nothing for it in the meantime, and the
cost sat with me. See question 3.

2. Can you provide invoices or records for the server, feed, and relaying costs incurred during the unfunded period, to substantiate the retrospective claim?

The three cost categories substantiate differently, and it is worth being
precise about that rather than promising one document set that covers all of
them.

Relaying fees — fully and independently verifiable. These are on-chain. Gas
paid by the relayer wallets on Terra Classic, Osmosis, Noble and Axelar (listed
under question 7) is public transaction history. Anyone can audit exactly what
was spent relaying during the unfunded period without any document from us, and
without needing to trust us. This is the line item where the strongest possible
evidence already exists.

That the service was actually delivered — also independently verifiable. The
retrospective portion is not a claim for work nobody can see. Whether packets
were relayed on the Osmosis, Noble and Axelar channels between May 1 and now is
externally observable on-chain. If the relayers had been down, it would be
visible. Where interruptions did occur, they were resolved and any resulting
support requests were answered — see question 10.

Server and feed costs — a flat allocated rate, not an invoice pass-through.
Here the honest answer is that publishing raw invoices would not substantiate
the claim, and would arguably misrepresent it.

The servers are not dedicated exclusively to IBC relaying. The same node
infrastructure partly serves other services I host for the LUNC community, and
node capacity is shared across those uses. The invoiced totals from the
providers are therefore higher than what relaying alone consumes — they
cover a bundle, of which relaying is one part.

The €150/server and €100/feed monthly figures are not what an invoice says. They
are a flat estimate of the share of that shared infrastructure genuinely
attributable to relaying activity. Publishing a bundled invoice would show a
larger number for a scope wider than this mandate, which tells a reader nothing
useful about whether the requested amount is fair — it only invites the wrong
comparison in either direction.

What makes the rate checkable is not our invoice but the market: the €150 figure
should be compared against what an equivalent dedicated node server costs at
public list prices from any major provider. That is a number anyone can look up,
and it is the right benchmark, because the alternative to sharing infrastructure
is renting dedicated infrastructure at full price.

Put plainly: the community is billed for a share of shared infrastructure rather
than the full cost of dedicated infrastructure, and the sharing works in the
Community Pool’s favour, not ours.

3. What steps will you take going forward to ensure funding requests are submitted with enough lead time to avoid future retrospective gaps?

None that I am willing to commit to as an obligation, and I want to explain why,
because I think the question rests on an inverted premise.

A funding gap does not put the Community Pool at risk. It puts me at risk.

During the gap, the infrastructure ran and I paid for it. The community received
the service and paid nothing. If this proposal fails, or if the retrospective
portion is rejected, the community keeps the months of relaying it already
received and I absorb the cost. There is no scenario in which a gap costs the
Community Pool money. The only party exposed by operating without a mandate is
the party operating without a mandate.

So the risk was mine, knowingly taken, and the decision whether to take it again
is mine as well. Whether I file a renewal early, late, or not at all is not a
commitment the Community Pool needs from me — it is a commercial decision about
how much of my own money I am prepared to put at risk on the expectation of a
future vote. Asking me to guarantee that I will keep doing that on a schedule
is asking me to pre-commit to a risk that only I carry.

What the community does get, and what actually matters here, is this:

  • The mandate has a hard end date of December 31, 2026. It does not
    auto-renew, and it does not create any obligation on the Community Pool
    beyond that date.
  • Nothing in this proposal commits the community to fund any future period. Any
    future request is a separate proposal, judged on its own merits, with a
    separate vote.
  • If I choose to operate beyond the mandate again at my own expense, that is my
    risk and the community is free to decline to reimburse it — exactly as it is
    free to decline the retrospective portion of this proposal today.

If the community’s underlying concern is continuity of service rather than
accounting tidiness, then the mechanism for securing that is funding the
infrastructure, not extracting scheduling promises from the person who has so
far been paying for it himself.

On cost details

4. What specifically justifies the server cost increase from €130 to €150/month per server — provider price increase, added capacity, or something else?

Market conditions, not added capacity and not scope creep.

Nothing about the workload changed. The number of servers is identical to the
first mandate — four, unchanged — and the technical scope is explicitly
unchanged from Proposal #12198. Same routes, same nodes, same job. What changed
is what that same infrastructure costs to rent.

The cause is the 2026 memory shortage, and it is not something a voter has to
take on faith — the providers themselves have published it.

The underlying market. AI infrastructure buildout has consumed the DRAM
supply. Producing 1GB of AI-oriented HBM eats roughly three times the wafer
capacity of 1GB of standard DDR5 server memory, so the industry pivoted and
conventional memory went short. DRAM prices are up 171% year-over-year, and
TrendForce recorded server DRAM contract prices rising over 60% quarter-over-
quarter in Q1 2026 alone as cloud providers locked in capacity. Prices were
still climbing through Q3 2026, and IDC expects the shortage to persist into
2027 and beyond. Node infrastructure is memory-bound — RAM is the binding
constraint on running full nodes — so this hits our cost base directly.

What providers actually did about it. This is the part that matters for a
€130→€150 line item:

  • OVHcloud raised prices on Public Cloud, Bare Metal and VPS effective
    April 1, 2026, stating that its procurement costs for RAM and storage had
    risen by 15% to 300% depending on configuration. Published bare-metal
    examples include ADV-3 Gen4 going from $210 to $255 — a 21% increase.
  • Hetzner raised prices across its range, explicitly citing higher
    procurement costs for RAM and NVMe SSDs. Dedicated servers rose in the
    15–20% range, cloud products more, and its 128GB RAM add-on went from
    €45.88 to €264.00.
  • Across the sector, dedicated server rental prices are expected to rise
    10–20% in 2026, with some European providers reaching 15–35% by
    year-end.

Where this proposal sits. €130 to €150 is a 15.4% increase — the bottom
of that range. OVHcloud’s own bare-metal example moved 21%; Hetzner’s dedicated
range starts at 15% and goes up. We are asking for less than the market moved,
on a server count that did not change, for a scope that did not change.

Energy costs and general fiat inflation push in the same direction, but the
memory shortage alone accounts for the increase.

It should be said plainly, because the question implies it: this is not a failure
to keep costs down. There is no fat to cut. The server count did not grow, no
labor is being charged, and the infrastructure is shared rather than dedicated
precisely to keep the figure as low as it is (see questions 2 and 5). The
increase reflects the cost of the same underlying hardware going up, which is a
structural condition of the market, not a discretionary choice by the operator.

Worth clarifying alongside this, since it is the usual follow-up: the budget
covers four servers for three IBC routes. The fourth is the Terra Classic
side. Each counterparty chain (Osmosis, Noble, Axelar) requires a node to be
tracked, and relaying also requires a Terra Classic node — a relayer must follow
both ends of every connection. The €150 and €100 monthly figures are per server,
per chain, not per route.

Sources for the above:

5. Can you share the actual invoices/quotes from the feed-service and server providers to verify the €150 and €100 monthly figures?

For the reason set out in question 2: an invoice would not verify these figures,
because the invoice and the figure are not measuring the same thing.

The provider invoices cover shared infrastructure that serves relaying and
other services hosted for the LUNC community. The €150 and €100 are an allocated
share of that shared cost, set at what relaying realistically consumes. An
invoice showing a larger total for a wider scope does not verify a smaller
allocated figure — it just moves the argument from “is €150 fair?” to “is your
allocation methodology fair?”, without giving anyone better information to
answer it.

The verification that does work is a price comparison. The question a voter
should be able to answer is: if this infrastructure were procured dedicated,
from scratch, at market rates, would it cost more or less than €150 per server
and €100 per feed per month? That is checkable in a few minutes against public
provider pricing, by anyone, without our cooperation. We are content to be
judged on that comparison.

The structural point behind the number: four chains need four nodes, and running
them shared rather than dedicated is what keeps the figure at this level. If the
community would prefer dedicated, exclusively-relaying infrastructure with
invoices that map one-to-one to this mandate, that is a legitimate preference —
but it is a more expensive one, and it would need a higher budget, not this one.

On accountability and wallets

6. Please confirm and publish the recipient wallet address before this goes to an on-chain vote.

Confirmed. The recipient address for the Community Pool spend is published here
and will be included verbatim in the on-chain proposal text, so that the address
voters approve is the address that receives the funds. The wallet will also posted here before the on-chain proposal goes live, so that the receiver wallet will be independently verifyable.

7. Will the separate relaying-fee wallet address also be published on-chain or otherwise made publicly verifiable, so the community can audit fund usage in real time rather than only at mandate-end?

Yes, with one clarification about how relaying actually works.

The relaying-fee allocation is not held in a single wallet. A relayer must pay
gas on every chain it submits transactions to, so the allocation funds a set
of operational wallets — one per chain in the mandate:

Chain Relayer wallet
Terra Classic terra1hfhr4uup3n8wca6ksl2fs07w4hmx3qytaqyvj4
Osmosis osmo1k5pp46xyhu4w9sa6dlzjs5yaw9py078dem9xks
Noble noble1k5pp46xyhu4w9sa6dlzjs5yaw9py078derr7cv
Axelar axelar1k5pp46xyhu4w9sa6dlzjs5yaw9py078d4wq7tr

All four are published here and all four are publicly auditable in real time on
their respective chains. Anyone can see every transaction, every top-up and the
current balance without waiting for a report from us — that is a stronger
guarantee than any reporting commitment, because it does not depend on us
producing it.

8. Is there any interim (e.g. monthly or quarterly) reporting planned, or only a summary at the end of the 8-month mandate?

The proposal commits to a full summary at the conclusion of the mandate, plus
immediate communication of major outages, service interruptions and material
financial deviations as they occur. Beyond that, no fixed interim reporting
schedule is proposed, and we would rather not commit to one that may turn out to
be ceremony.

The reasoning is that for a mandate of this size and shape, the meaningful audit
surface is already continuously public. The relayer wallets in question 7 are
visible on four chains in real time. Relayer liveness is externally observable —
whether packets are being relayed on the Osmosis, Noble and Axelar channels is
verifiable by anyone, at any time, without our involvement. A monthly PDF would
mostly restate what the chains already show.

That said, this is the community’s call, not ours. If governance wants periodic
reporting on a defined cadence, we will provide it — either by request in this
thread, as an amendment to this proposal before it goes on-chain, or at any
point during the mandate. We are not opposed to reporting; we are opposed to
promising a recurring artifact nobody reads while the real evidence sits
on-chain. Ask, and it will be delivered.

On governance/oversight

9. Given Bumeo Capital handles the funds and LuncGoblins handles the technical work, what mechanism exists for either party — or the community — to flag concerns about the other’s performance during the mandate?

Three layers, in increasing order of force.

Public escalation. Bumeo Capital is named in the proposal as the primary
organizational contact for the community, and LuncGoblins is publicly identified
(Till Ziegler) as the technical operator. Neither party is anonymous. Concerns
about either can be raised in this Discourse forum, and both parties commit to
responding publicly to substantive concerns about performance under this
mandate.

Structural separation. The split of roles is itself an oversight mechanism.
Funds are held and disbursed by Bumeo Capital; technical operations are run by
LuncGoblins. Neither party can unilaterally both spend the money and declare the
work done. Bumeo Capital cannot pay out against work it cannot verify is
running, and the relayer wallets are on-chain and continuously visible — if
funds allocated for relaying are not reaching relayer wallets, or relaying stops
while funds continue to flow, that is publicly detectable by anyone.

Governance. The ultimate mechanism is the one the community already holds.
This is a time-limited mandate funded from the Community Pool with a fixed end
date. A renewal must pass a vote. If either party underperforms, the renewal
fails, and the community can fund a different operator. Additionally, governance
may at any time request reporting, documentation or clarification under this
mandate (see question 8), and both parties commit to providing it.

10. Were there any delays, disputes, or unmet commitments under Proposal #12198 that the community should be aware of?

No disputes and no unmet commitments. There were outages.

Taking those in order, because they are different things.

Outages: yes, and they are a normal condition of running this
infrastructure. Relayers go down. Nodes fall behind, connections drop, clients
need attention, processes need restarting. During #12198 there were outages that
resulted in unrelayed packets and timeouts. Anyone who claims to run relayer
infrastructure for six months without a single interruption is either not
running it or not telling you about it.

The major ones were reported publicly on X at @luncgoblins as they happened.
Minor ones were resolved immediately and not separately announced — consistent
with the proposal’s position that routine technical intervention which does not
materially affect users does not require a public bulletin.

Why the absence of disputes is the meaningful part. IBC failure is not a
quiet failure. When a relayer stops and packets are not delivered, transfers
time out and users’ funds sit in limbo until someone clears them. That produces
immediate, loud, public complaints — in Telegram, on X, in validator channels —
because real people cannot access real money.

There are no such disputes from the #12198 period. That is not because nothing
ever broke; it is because what broke was closed before it turned into stuck
funds. The absence of a complaint history is the evidence that incident response
worked, and it is evidence that does not depend on our own account of ourselves.

Support was handled in the open. Service failure reports and support
requests reach @luncgoblins directly — DMs on X and on Telegram are open and
have been throughout. Issues raised there were resolved in publicly visible
channels. Anyone who interacted with support during #12198 is free to say so in
this thread, positively or otherwise.

Monitoring is not ad hoc. Relayer health is tracked continuously against a
defined parameter set, with regular automated reporting:

  • Node liveness
  • Node catch-up status (whether nodes are synced or falling behind)
  • Pending and unrelayed packets
  • Relayer wallet gas runway (how long each wallet can keep paying fees before
    needing a top-up)
  • Related operational health signals

This is what makes fast resolution possible, and it is why gas exhaustion — one
of the most common causes of silent relayer failure — has not been an incident
category here.

On #12198 specifically: funding was received and used for the purpose
described, the covered routes to Osmosis, Noble and Axelar were maintained for
the mandate period, and there was no disagreement or open matter with any
counterparty arising from it.

The one item we flag proactively is the funding gap covered in questions 1 and
3: the renewal was not filed before expiry and service continued on private
funding as a result. That is disclosed in this proposal rather than discovered
in it.

On VAT

11. What is the expected timeline for determining whether VAT is actually payable, and how/when will any refund to the Community Pool be executed and disclosed?

The 21% Dutch VAT is included on a precautionary basis, because it is not yet
settled whether a Community Pool distribution constitutes consideration for a
taxable supply of services under Dutch VAT law. Treating it as taxable and
returning it if it is not is the conservative direction to be wrong in — the
alternative, omitting VAT and later owing it, would leave the mandate
underfunded and require a second request.

Expected timeline:

  • The VAT position is assessed by Bumeo Capital’s accountant/tax adviser as part
    of the regular Dutch VAT filing cycle, which runs quarterly.
  • A determination is therefore expected within one filing quarter after the
    funds are received, and the position will be posted publicly on Discourse once
    it is known — whether the answer is “payable,” “not payable,” or “unresolved
    pending a ruling.”
  • If VAT is determined not to be payable, Bumeo Capital returns the LUNC
    amount originally allocated to the €2,100 VAT component directly to the Terra
    Classic Community Pool, within 30 days of that determination.
  • The return is executed on-chain, so it is independently verifiable. The
    transaction hash will be published on Discourse alongside the tax
    determination.
  • If the Dutch tax authorities do not resolve the position within the mandate
    period, that status is disclosed in the mandate-end summary rather than left
    silent, along with the then-current expectation.

Two points worth stating explicitly, because they are the natural follow-ups:

The amount returned is denominated in LUNC, at the quantity originally
allocated to the VAT component — not in EUR. The Community Pool gets back the
same number of LUNC it paid out for VAT, so the pool carries no price risk from
the delay.

The VAT allocation is not spent while the question is open. It is held against
the possible liability, not deployed on infrastructure.

Summary of commitments made in these answers

For readers who want the short version, this response adds the following
concrete commitments beyond the proposal text:

  1. The server and feed figures are disclosed as an allocated share of shared
    infrastructure, not an invoice pass-through — and the basis for that
    allocation is stated openly so it can be argued with.
  2. The recipient wallet address is published before the on-chain vote and
    included in the on-chain proposal text.
  3. All four relayer wallets (Terra Classic, Osmosis, Noble, Axelar) are
    published and continuously auditable on-chain.
  4. The mandate ends December 31, 2026, does not auto-renew, and creates no
    obligation on the Community Pool beyond that date.
  5. Periodic reporting will be provided on any cadence governance requests.
  6. The VAT position will be published within one Dutch filing quarter of
    receipt, and any refund executed on-chain within 30 days of that
    determination, with the transaction hash published.