DEV Community: Pound Eater

Redbelly Community DAO: What Is Actually In Force Right Now published: false tags: dao, governance, web3, blockchain

Pound Eater — Sat, 15 Aug 2026 12:07:25 +0000

Constitution v1.2 is nine months out of date. It was ratified in September 2025 and never touched again, while fifteen structural proposals passed after it and changed how the Redbelly Community DAO actually runs. This article is the answer to a simple question that nobody in the DAO could answer with one document: what rule is currently in force.

The short version, if you read nothing else:

Two governing documents are ratified: Constitution v1.2 (Snapshot proposal #2, 20 Sep 2025, 100% For) and Code of Conduct v1.0 (proposal #9, 6 Oct 2025, 92.97% For).
Of 30 Snapshot proposals on record for rbnt.eth, 18 passed, 8 were rejected, 3 were multi-choice elections with no single pass or reject label, 1 was a test proposal.
Standard voting runs 5 days. Elections still run 3 days, an unwritten convention the constitution never mentions.
The general-member voting whitelist passed removal on paper. It was not actually removed. The two proposals that followed it still carry a whitelist strategy on-chain.
Leadership structure changed twice in July 2026 alone, and both changes are ahead of what the constitution and the November 2025 leadership document describe.

Everything below explains how each of those five facts was checked, not assumed.

The problem with treating a Snapshot vote as the end of the story

A proposal passing on Snapshot answers one question: did enough RBNT-weighted votes say yes. It does not answer whether the DAO actually started doing the thing the proposal described. Those are two different events, and conflating them is where most of the confusion in the DAO's channels comes from. This review checked both, for every structural proposal, separately, using the Snapshot GraphQL API rather than relying on screenshots or Snapshot's own frontend labels.

It also treated Discord polls as real decisions. Snapshot is not the whole governance record. Some changes were decided and announced in Discord and never went to a formal vote. Excluding those from a changelog because they lack a Snapshot link would hide a decision the DAO is actually operating under, so they are included here, clearly marked as poll-only and unratified.

Current state, in force today

This is the part meant to be read on its own, without the history below it.

Governing documents. Constitution v1.2 and Code of Conduct v1.0 are both ratified by Snapshot vote, not by any Google Form process. The Constitution's own version history line confirms this: 1.0 retired, 1.1 retired, 1.2 ratified via Snapshot vote 20 September 2025.

Voting duration. Every proposal from September to October 2025 ran a 3 day window. From proposal #6 onward, the Snapshot Voting Duration proposal (3-6 Oct 2025, passed 92.97% For) set the standard to 5 days. Elections are the exception: DAO Leadership Elections (28-31 Jan 2026) and High Council Elections (21-24 Jul 2026) both ran 3 days, a convention that exists nowhere in the ratified text.

Voter eligibility. Proposal #28, "DAO Proposal: Increase Governance Accessibility and Protect Contributor Privacy," passed 5 July 2026 with 53.76% For. It states it removes the voting whitelist and lifts geographic restrictions for general members, keeping both restrictions only for High Council and DAO Leadership. Pulling the strategies field directly from Snapshot's GraphQL API for the two proposals created after it, Amendment to Leadership Structure (#29) and High Council Elections (#30), both still list a whitelist strategy, unchanged from every proposal before #28. The vote passed. The DAO's voting configuration was not updated to match it.

Leadership. "Amendment to Leadership Structure" passed in July 2026, and High Council Elections closed the same month. Both Constitution Section 2 (Governance Structure) and the November 2025 Leadership document are now behind the current position. The three winners of the High Council election by voting power, Buffy, NekoyaManeki, and Light, match the roster the DAO separately announced in Discord on 24 July 2026, independent confirmation that the handoff actually happened rather than just being voted on.

The full chronological record

Thirty Snapshot proposals exist for rbnt.eth, spanning 3 September 2025 to 24 July 2026. Fifteen of them are structural, meaning they changed governance process, the constitution, or the rulebook rather than funding a one-off initiative. Here is the structural set, oldest to newest, each one mapped to the constitution section it touches, with exact dates and margins pulled from the Snapshot GraphQL API:

#	Date	Proposal	Result	Section
2	17-20 Sep 2025	Constitution Ratification	Passed, 100% For	Ratifies the Constitution
3	17-20 Sep 2025	Proposal Submission Limit per Round	Passed, 100% For	Section 4
4	17-20 Sep 2025	Budget Allocation per Proposal	Passed, 80.89% For	Section 6
5	17-20 Sep 2025	DAO Guild Structure, Consolidation	Rejected, 42.95% For, Abstain plurality 56.71%	Section 3
6	3-6 Oct 2025	Snapshot Voting Duration	Passed, 92.97% For	Section 4
7	3-6 Oct 2025	Standardised Proposal Evaluation Criteria	Passed, 100% For	Section 4
8	3-6 Oct 2025	Update Proposal Submission Template	Passed, 100% For	Section 4
9	3-6 Oct 2025	Community Code of Conduct	Passed, 92.97% For	Ratifies Code of Conduct v1.0
11	7-12 Dec 2025	Community Consultation Policy	Passed, 99.99% For	Section 4
18	28-31 Jan 2026	DAO Leadership Elections	Closed, election	Section 2
24	1-5 Mar 2026	Community Task Board Initiative	Passed, 90.68% For	Sections 3 and 4
25	29 Jun-4 Jul 2026	Temporary Suspension of Treasury-Funded Activities	Passed, 100% For	Section 6
28	30 Jun-5 Jul 2026	Increase Governance Accessibility and Protect Contributor Privacy	Passed, 53.76% For	Section 2.3
29	11-16 Jul 2026	Amendment to Leadership Structure	Passed, 97.48% For	Sections 2 and 9
30	21-24 Jul 2026	High Council Elections	Closed, election	Section 2

Every link, exact percentage, per-voter RBNT power breakdown, and Applied status for all 30 proposals, structural and non-structural, is in the full changelog linked at the end of this article. This table is the summary, not the source.

One decision that passed and was never implemented

A Discord poll on 1 March 2026 approved quadratic voting at 75% and the DAO announced it as active. Checking the Snapshot archive against that claim: no proposal, before or after 1 March 2026, uses quadratic voting as a ballot type or as a voting strategy. Every round since ran ordinary weighted ballots on unchanged token-weighted voting power.

This is recorded as not applied, with the evidence being the absence of the strategy field on every subsequent proposal, not an assumption based on the poll result alone.

One disputed decision, reversed on reasoning

Proposal #5, "DAO Guild Structure, Consolidation," closed 20 September 2025 with 42.95% For against a 56.71% Abstain plurality and 0.34% Against.

The conclusion is rejected, not implemented, for two independent reasons. First, on a majority-of-all-votes-cast reading, Abstain outpolled For, so the proposal did not clear a majority. Second, Constitution Section 3, Working Groups (Pods), still lists all five original pods, Marketing, Builder/Develop, Researcher, Community, Partnerships, with no trace of the Partnerships-and-Research merger this proposal asked for. If the merge had taken effect, Section 3 would list fewer than five pods. It lists five, which is evidence the consolidation never happened, not evidence that it did.

Worth flagging directly: Snapshot's own frontend displays a "Passed" badge on this proposal's live page. Its UI compares only For against Against and treats Abstain as neutral, under which For (42.95%) beat Against (0.34%) by a wide margin. That is a different methodology, not a different set of facts, and this review applies the majority-of-all-votes-cast standard consistently across the whole record rather than switching standards proposal by proposal.

One dispute, resolved instead of left open

Proposal #28 removed the general-member voting whitelist on paper, passing 5 July 2026 with 53.76% For. The open question was whether that removal actually reached the DAO's live voting configuration.

It didn't. Pulling the strategies field directly from the Snapshot GraphQL API, no authentication required, for the two proposals created after #28, Amendment to Leadership Structure (#29) and High Council Elections (#30), both still list a whitelist strategy, unchanged in kind from every proposal before #28 back to the Constitution ratification. The vote passed. The configuration was never updated to match it.

A newer constitution surfaced mid-review, and it raises its own question

Constitution v1.3 turned up during this review, published 12 Aug 2026, after the Snapshot data window this piece is built from (proposals through #30, 24 July). It drops the Working Groups (Pods) section entirely, no three pods, no five, just gone, and renumbers every section after it down by one.

Its version history line gives no Snapshot proposal number: "Governance consolidation incorporating ratified constitutional questionnaire and meeting clarifications." No proposal for a v1.3 vote exists anywhere in the 30-proposal record. That phrasing, "constitutional questionnaire," is the same shape as the Feb 2026 Google Form this piece already excludes for not meeting the constitution's own 7-day-notice, 5-day-vote amendment process. Whether v1.3 was ratified the same way is not yet confirmed either way.

Separately, a Discord conversation obtained during this review dates the actual disappearance of guild channels and pod leadership to two points: guild leaders were replaced by General DAO Leaders during the January 2026 elections, and the Discord channels themselves came down roughly 2 August 2026. Both are months after proposal #5 closed, and neither matches what #5 specifically asked for, folding two of five pods into the other three. Pods are gone from the DAO today, just not the way, or on the timeline, that proposal ever described.

What this is not

Two things came up during this review that are explicitly excluded from the ratification record on purpose.

A Google Form titled "DAO Constitution Ratification, YES/NO Vote" ran 11-14 February 2026 with 9 to 10 respondents. It is not the Constitution's ratification event. The actual ratification is Snapshot proposal #2, closed 20 September 2025, which matches the version history embedded in the Constitution document itself. The form used a self-defined 60% adoption threshold that has no basis in Constitution Section 9's amendment process, which requires 7 day notice and a 5 day token-weighted vote open to all members plus High Council, Pod Leaders, and Genesis Leaders. Nothing decided on that form should be logged as a ratified constitutional change.

Proposal #28 also references "Redbelly Community DAO Constitution v1.3" as a supporting document. No v1.3 file exists anywhere in the source material this review had access to, and every governing-resource link available points to v1.2 as current. This is flagged as an open item rather than either assumed to exist or assumed not to.

Where the gaps are

Full transparency on what this record does and does not know:

Constitution v1.3 has been located, published 12 Aug 2026, after this review's Snapshot data window closed. It drops the Working Groups (Pods) section entirely and renumbers every later section down by one. How it was ratified is unverified: no matching Snapshot proposal exists in the 30-proposal record, and its own version history line references a "ratified constitutional questionnaire," the same pattern already excluded elsewhere in this piece for not meeting the constitution's own amendment rules.
Proposals 10, 18, and 30 are multi-choice or ranked-choice votes, not standard For/Against/Abstain, so they are reported as winner-by-power rather than passed or rejected.

The two gaps from the earlier version of this review, exact vote-choice percentages for ten proposals and day-level dates for eighteen proposals, are both closed. Every date and margin in the full changelog now comes from the Snapshot GraphQL API directly.

The full record

This article is the summary. The full deliverable has every one of the 30 proposals, the complete per-voter RBNT staking power breakdown for each one, an Applied column showing which passed decisions actually took effect, direct links to every source document, and an interactive changelog you can click through proposal by proposal.

Full interactive changelog website: https://redbellydaotask23-one.vercel.app/
Full PDF report: https://cdn.jsdelivr.net/gh/poundeater/23@main/website/Redbelly-DAO-Governance-Changelog.pdf
Full Word doc, readable in browser: https://docs.google.com/viewer?url=https://raw.githubusercontent.com/poundeater/23/main/website/Redbelly-DAO-Governance-Changelog.docx&embedded=true
Source repository, all 30 proposal PDFs and per-voter exports: https://github.com/poundeater/23
Constitution v1.3: https://drive.google.com/file/d/1luhxjVuhHsSi6hiYhKqcv9wwmZPOqJGF/view?pli=1

If you sit on the High Council or moderate the DAO and someone asks what was actually decided on any of this, this is the document to link.

One Governance Recap, Three Formats: Building the Redbelly DAO Monthly Digest published: true tags: web3, dao, react, frontend

Pound Eater — Thu, 13 Aug 2026 10:49:09 +0000

Every DAO writes its governance recap once and then rewrites it three times. Once for Discord, once for X, once for a PDF that goes into an archive nobody opens. Redbelly DAO Task Board's TASK-24 asked for a page that ends that pattern: one source, three formats, one page.

Live site: https://redbellydaotask24-one.vercel.app/
Source: https://github.com/poundeater/task24

The brief

The July 2026 governance cycle closed 6 Snapshot votes, reset a High Council election midmonth, and passed a Leadership Structure Amendment that replaces generic roles with 5 appointed positions. That is a lot to recap, and every channel wants it shaped differently. Discord wants full paragraphs. X wants short numbered posts, or for accounts with the long post feature, one flowing piece. Anyone doing due diligence wants a PDF they can cite and a DOCX they can read.

So the page has 4 sections that all describe the same 6 votes:

a long-form block with an inline PDF preview and a read-only DOCX link
a Discord-ready paragraph block
an 8-post X thread, numbered 1/8 through 8/8
a single long-form X premium post

Every card has a Copy button and a Download txt button, so whoever is posting the update never has to retype a number.

The design system

The page runs on Redbelly DAO Task Board's Kinetic Consensus tokens. Dark theme, one accent color, no pill buttons, and depth done tonally instead of with drop shadows, a card is a lighter slate than the page with a 1px border a shade lighter than its own fill. Be Vietnam Pro carries every heading and all body copy. JetBrains Mono is reserved for machine-generated values only, vote percentages, proposal identifiers, post-count labels like 1/8, never for prose.

The house copy rule that mattered most while writing this: plain hyphens only, never an em or en dash, and say the number. "6 votes," not "a few votes." It reads oddly plain at first and then it reads exact, which is the point for a governance record.

Two links, two jobs, one 403

The PDF and DOCX come from the same GitHub repo but they cannot use the same CDN, and that took one failed deploy to learn.

jsdelivr (cdn.jsdelivr.net/gh/...) is built for anything meant to render inline, so it powers the Read PDF button and the embedded viewer. It has returned a 403 on a .docx file specifically, so it never touches the DOCX link.

raw.githubusercontent.com serves files with a Content-Disposition header that forces a download, which is exactly wrong for a document someone just wants to skim. So the DOCX button opens read-only in a new tab through Google Docs Viewer, pointed at the raw GitHub URL:

https://docs.google.com/viewer?url=<url-encoded raw.githubusercontent.com link>&embedded=false

No download prompt, no Google account required, and it renders .docx the same way it renders .pdf, .xlsx, and half a dozen other formats, straight from a URL.

Copy and download, no backend

Every text block has a Copy button and a Download txt button, and neither one touches a server.

Copy uses the Clipboard API first, with a hidden textarea plus execCommand('copy') as a fallback for browsers that do not support it, then flips the button label to "Copied" with a checkmark for about 2 seconds before reverting.

Download txt is a Blob and a temporary anchor element:

function downloadTxt(filename, text) {
  const blob = new Blob([text], { type: "text/plain" });
  const url = URL.createObjectURL(blob);
  const a = document.createElement("a");
  a.href = url;
  a.download = filename;
  a.click();
  URL.revokeObjectURL(url);
}

For the X thread, the 8 posts combine into one file, each one preceded by its 1/8 through 8/8 label, so a download gives you the whole thread in the order it should be posted, not 8 separate files to reassemble.

Stack

React, TypeScript, and Vite, fully responsive down to a 16px mobile margin, single column throughout, no navigation, no second page. The DOCX, PDF, and every logo and favicon asset ship straight from the repo's public/ folder.

Where it lives

Site: https://redbellydaotask24-one.vercel.app/
Repo: https://github.com/poundeater/task24

Building the Redbelly DAO "Start Here" Onboarding Hub

Pound Eater — Wed, 12 Aug 2026 08:58:12 +0000

Live site: https://redbellydaotask17-one.vercel.app/
Source: https://github.com/poundeater/task17hub

The problem

Open the Redbelly DAO Discord on any given day and the same handful of questions surface on repeat. Someone new joins, connects a wallet, and immediately hits one of a small set of walls: their balance shows zero and they assume their funds are gone, they cannot tell mainnet from testnet in their wallet's network list, they do not know whether they need to complete KYC before they can do anything at all, or they get a DM from someone claiming to be Redbelly staff and are not sure if it is real.

A moderator answers. A different new user asks the same thing an hour later. Then again the next day. Multiply that across a growing community and the support queue is made almost entirely of repeat questions, each one answered from scratch or copy-pasted from an old message that is increasingly hard to find.

TASK-17 on the DAO's Community Task Board was written to close that loop: build one canonical page, get it right once, and give moderators a single link to paste instead of retyping an explanation for the hundredth time.

Scoping the deliverable

The task spec was specific about what counted as done: seven content sections, each covering one recurring question, an actual design pass rather than a plain FAQ dump, and cross-links to related resources so the page did not have to duplicate content that already existed elsewhere in the DAO's ecosystem.

The seven sections, in the order a new user actually needs them, are scam warning, KYC, network setup, the zero-balance explainer, where to buy and trade, staking basics, and the testnet faucet. Two constraints shaped almost every decision after that: nothing could be published without a source, and the page had to work on a phone, since nearly all of its traffic arrives as a link pasted into Discord and opened on mobile.

Sourcing before writing

Every factual claim on the page was checked against an official source before it was written: docs.redbelly.network, the Redbelly Individual Onboarding SDK overview, the Terms and Conditions, chainlist.org, and the ethereum-lists/chains repository for RPC and chain ID data. Where a claim could not be traced to a published document, it got a visible flag instead of a confident sentence pretending otherwise.

Two pieces of content ended up in that second category: the ten-wallet-per-identity activation limit and the typical three-to-five-minute KYC approval window, both confirmed firsthand and by a moderator in Discord but not written down anywhere official, and the entire zero-balance explainer below, which does not exist as a published troubleshooting guide anywhere. Both are marked directly in the content as community-verified rather than official, so a reader knows exactly which parts are backed by a doc and which parts are backed by someone who went and checked.

Section 1: Scam warning

Placed first, not buried, because it is the one piece of information that needs to reach someone before they click anything else. Redbelly staff, moderators, and official support never DM first. Any direct message claiming to be from Redbelly staff, offering support, or announcing a giveaway is a scam, no exceptions. The common patterns are unsolicited DMs offering help with a wallet or KYC issue, giveaway or airdrop claims requiring a wallet connection or seed phrase, and anyone asking for a seed phrase, private key, or wallet "verification" through a link. Official communication only happens through public channels: the site, official docs, and public Discord channels.

Section 2: KYC

KYC is required for native RBNT and mainnet activity: transactions, staking, and governance. It is not required to hold or trade wrapped RBNT on other chains. Redbelly gates its own Layer 1 behind identity verification through the Redbelly Access portal:

Access portal: https://access.redbelly.network/

Wrapped RBNT on Ethereum or other chains is a standard ERC-20 with no Redbelly-side identity check. One verified identity can activate up to ten wallets, and most submissions are approved in about three to five minutes, with manual review taking longer. That specific limit and timing are community-verified rather than published in an official doc.

Eighteen jurisdictions are currently restricted from accessing the platform, per Clause 15 of the Terms and Conditions: Afghanistan, Central African Republic, North Korea, Democratic Republic of the Congo, Guinea-Bissau, Iran, Iraq, Lebanon, Libya, Myanmar, Russia, Somalia, South Sudan, Sudan, Syria, Ukraine, Yemen, and Zimbabwe.

Section 3: Network setup

Two chains, never to be confused: Mainnet at Chain ID 151 and Testnet at Chain ID 153. Both are listed on the page with a one-tap "Add to wallet" button wired to wallet_addEthereumChain, so nobody has to copy-paste RPC fields by hand on a phone.

Network	Chain ID	RPC	Explorer
Mainnet	151	https://governors.mainnet.redbelly.network	https://redbelly.routescan.io
Testnet	153	https://governors.testnet.redbelly.network	https://redbelly.testnet.routescan.io

Chain ID 151 and 153 look close enough on a small screen that a copy-paste error between the two would be easy to make and hard to notice until something failed, so keeping the two cards structurally identical but visually and numerically distinct was as much a design decision as a content one.

Section 4: Wallet shows a zero balance

The task spec described this as a missing price-feed mapping issue, but that framing does not hold up against what actually happens in practice. In the overwhelming majority of cases, a wallet showing a zero balance for RBNT is a contract-recognition problem, not a price-feed problem, and it is almost always about wRBNT rather than native RBNT.

Native RBNT is the network's own gas token and does not need a contract address added anywhere to display correctly, the same way ETH does not need one on Ethereum. wRBNT is a wrapped ERC-20 on other chains, and if its contract address is missing or wrong in a given wallet, that wallet has no way to know what it is looking at, so it shows zero.

wRBNT contract addresses:

Ethereum: 0xb45ffb51984d626ee758b336c61cf20990c6bf13
Base: 0x020940df9f5e77338a094d55b5b5914122a804a5

The fix path on the page is a simple escalation: confirm the contract address is actually added, try a second wallet extension such as Rabby if it still shows zero, check the address directly on a block explorer if it is still not showing, and if it is genuinely not showing anywhere, confirm the original transfer or bridge transaction actually completed. The line that matters most is the last one on the page: a zero balance in your wallet does not mean lost funds. Almost every real case is a UI recognition gap, not a security incident.

Section 5: Where to buy and trade

Centralized exchanges:

MEXC: https://www.mexc.com/exchange/RBNT_USDT
Gate.io: https://www.gate.com/trade/RBNT_USDT
WhiteBit: https://whitebit.com/trade/RBNT-USDT
BYDFi: https://www.bydfi.com/en/spot/RBNT_USDT

Decentralized exchanges, Ethereum:

Decentralized exchanges, Base:

Decentralized exchanges, Solana:

Raydium: https://raydium.io/swap/?inputMint=2GBVt2ENvbHepuJMWYTPkkfpWUabAhsaXToYw8UphxS3&outputMint=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

Redbelly native:

Reddex: https://www.reddex.io/swap?chain=redbelly&inputCurrency=NATIVE&outputCurrency=0x8201c02d4AB2214471E8C3AD6475C8b0CD9F2D06

Bridges:

Lucid Labs Bridge: https://bridge.lucidlabs.fi/
Reddex Bridge: https://www.reddex.io/bridge

Native RBNT and wrapped RBNT are separate assets on different chains, so the page is explicit about checking which one a given venue actually lists before trading.

Section 6: Staking basics

RBNT can be staked to consensus or storage nodes to help secure the network and earn rewards. Staking is a mainnet action and requires KYC, the same as any other native transaction.

Stake on Reddex: https://www.reddex.io/stake

Available pools differ by lock period and reward rate, some with no lock and others locked for a fixed term at a higher rate. Rates and total value locked change constantly, so rather than hardcoding a snapshot that would be stale within days, the page points to the live staking dashboard for current numbers.

Section 7: Testnet faucet

Faucet: https://vine.redbelly.network/rbnt-faucet

FAUCETME-powered, 500 RBNT per claim, on Testnet Chain ID 153, with an effectively zero gas cost for deployment on testnet.

Design system

The page runs on the DAO Task Board's brand kit, called Kinetic Consensus: one accent color used consistently rather than a rotating palette, generous negative space, Be Vietnam Pro for every heading and body line, and JetBrains Mono reserved specifically for wallet addresses, chain IDs, and RPC URLs.

The build uses the brand kit's light theme: a near-white page background, white cards with a hairline border, and the accent color used for links and highlighted text rather than as a background fill anywhere near body copy, since a saturated red at small text sizes on a light background fails contrast checks fast. The solid brand red is reserved for primary button fills only.

Voice rules came with the brand kit as hard constraints rather than suggestions: no em dashes anywhere, no emoji, no filler verbs, plain and direct sentences. Writing an entire onboarding page without an em dash changes how you structure sentences, and by the end it reads more like a support document than marketing copy, which was the actual goal.

Closing thoughts

The most interesting part of this task was not the design work, it was deciding what belonged on the page at all. A Start Here hub only earns its name if it resists the urge to explain everything. Every section had a version that could have gone twice as long, and the harder edit was cutting it back to what someone standing at the front door of the DAO, wallet freshly connected, actually needs before doing anything else.

If you spot something wrong, especially in the zero-balance section since it is the one part without an official doc backing it yet, open an issue on the repo. That section in particular should get replaced with a link to a real docs page the moment one exists.

Where to Buy and Trade RBNT

Pound Eater — Tue, 11 Aug 2026 11:51:45 +0000

RBNT (Redbelly Network's native coin) trades across four centralized exchanges, one native chain DEX, and three separate wrapped-token markets. None of that was written down in one place, cross-checked, or kept up to date. This post covers TASK-20 for the Redbelly DAO Community Task Board: a canonical, dated reference document plus a live price feed built on top of it.

Live site: https://redbellydaotask20-one.vercel.app/
Source: https://github.com/poundeater/task20/

The problem

RBNT trades in two forms that get confused constantly. Native RBNT is the coin on Redbelly Network's own chain. Wrapped RBNT (wRBNT) is a separate, bridged token used for DeFi trading on other chains. A change to one does not mean the other has changed, and most public listings don't say which one they're actually quoting.

On top of that, aggregators disagree with each other, listings go stale within days, and at least one exchange that used to be listed (BitMart) didn't reconfirm as live in the latest pass and had to be dropped rather than carried forward out of habit.

The deliverable needed to be a snapshot that states its own limits: what was checked, how it was checked, and when.

What's in the reference doc

Four sections, each independently verified against the venue's own page and cross-checked against at least two independent sources (CoinGecko, CoinCodex, CoinMarketCap, and on-chain explorers):

Native RBNT, centralized exchanges: Gate, MEXC, BYDFi, WhiteBIT. WhiteBIT is flagged thin (listed, but no trades in the hours before verification) instead of being dropped or silently trusted.
Native RBNT, on-chain: Reddex, the official liquidity hub for Redbelly Network, the only venue confirmed for trading RBNT and wRBNT directly without bridging.
Wrapped RBNT, three chains: Ethereum, Base, and Solana, each with its own contract address, price-impact figures at real trade sizes, and DEX venues. The Base contract in particular got re-verified independently on BaseScan before shipping, because a canonical reference document is the wrong place to ship an unconfirmed address.
Bridges: the two official routes (Lucid Labs Bridge, Reddex Bridge) for moving RBNT and stablecoins in and out of the network.

No futures market is listed, on purpose. Several exchanges carry generic marketing copy referencing futures trading that appears on every token page regardless of whether a market exists. That's not evidence, so the doc says plainly that no futures market is confirmed instead of leaving the gap for someone to assume one exists.

The doc ships as both DOCX and PDF, built with the DAO Task Board's own brand kit (Kinetic Consensus): dark slate surfaces, one accent color, Be Vietnam Pro for text, JetBrains Mono for anything machine-generated like contract addresses and timestamps, status shown as a small dot plus a label rather than a colored pill.

The live price feed

The doc is a snapshot. The website needed something that doesn't go stale between snapshots, so the Spot table now carries a live price column.

A small Node backend on a VPS holds a WebSocket connection open to each exchange that actually exposes one, and republishes a unified feed:

{ "mexc": "0.003143", "gate": "0.003126", "whitebit": "0.003123", "bydfi": null, "ts": 1234567890 }

Three of the four venues work as expected. The fourth doesn't, and the honest answer mattered more than a workaround:

MEXC and WhiteBIT expose a public WebSocket. Straightforward push feed, no issues.
Gate dropped every WebSocket connection with a 1006 immediately after the handshake. Turned out to be a permessage-deflate compression negotiation that Gate's OpenResty-based server doesn't handle cleanly, hard-resetting the connection mid-handshake. Disabling client-side compression didn't fully resolve it, so Gate now runs on a REST poll every five seconds instead of a push connection. Same output shape to the frontend, slightly higher latency, but correct and stable.
BYDFi has no public price API. No REST ticker, no WebSocket, nothing. Their own trade page renders its price from an internal frontend API that isn't meant for third-party consumption, and reverse-engineering it would be both fragile and against their ToS. Rather than fake a number or scrape something undocumented, the frontend shows "Check exchange" for BYDFi, styled as informational, not an error state. Three out of four live is the honest, realistic ceiling here, and pretending otherwise would put a number on the page that nobody actually verified in real time.

On the frontend, each row prices in JetBrains Mono, right-aligned, and grays out to a "last known" state with automatic reconnect if the socket drops, rather than going blank.

What I'd flag to anyone building something similar

The two most useful lessons weren't about React or WebSockets:

A canonical reference document is a liability if it's wrong. Cross-checking every address and every listing against a second independent source, and catching your own mistake before shipping (an unverified contract address, a guessed URL format instead of the one actually established) is the actual job, not a nice-to-have on top of it.
"No" is a valid engineering answer. BYDFi genuinely does not have a way to get this data safely. Building a scraper against an undocumented internal API to fill in a fourth number would have looked more complete and been strictly worse: fragile, against the exchange's terms, and quietly wrong the first time their frontend changed.

Repo has the full build, including the price-feed server and the doc-generation script. Feedback and issues welcome.