Several messages in the Redbelly community channels, all asking some version of the same five questions:

#crypto #security #tutorial #webdev

When does KYC actually apply?
How many wallets can one identity cover?
How long does approval take?
Are regional restrictions still in place?
Does staking need KYC too?

That repetition is what TASK-18 on the Redbelly DAO Task Board set out to fix: one plain-language page that answers all five, with each claim either sourced to an official source or clearly marked as unconfirmed.

The instinct with a task like this is to write what sounds right and move on. Five questions, five answers, ship it. But the task spec was explicit about what counts as a failure: any claim stated as fact with no source, and not marked unconfirmed, fails review outright. That single rule shaped how the whole thing got built.

Starting with what could actually be verified

The first question, when KYC applies, had a clean answer sitting in Redbelly's own developer documentation. KYC gates native mainnet activity, transactions, staking, governance, all of it runs through the Redbelly Access identity layer, and that scope covers Redbelly's own chain specifically. Wrapped RBNT already exists on multiple external chains, Ethereum (ERC-20) and Solana (SPL, bridged via Router Protocol's Nitro), both confirmed through Redbelly Network's own official X account, and any token living outside Redbelly's own chain sits outside that stated scope by definition, so trading it on an external DEX needs no Redbelly-side verification at all. That conclusion follows directly from the onboarding documentation's own scope, not a chain-by-chain guess. What is not separately checked is the token standard on any chain beyond those two confirmed deployments, so the piece does not assume a specific format for a chain it has not named.

Regional restrictions were more interesting, because the task brief assumed something the evidence did not support. The brief stated restrictions had been removed. Checking Redbelly's own Terms and Conditions told a different story: Clause 15 lists eighteen jurisdictions still restricted from the platform, Afghanistan through Zimbabwe, with no indication anywhere of a reduction from a prior, larger list. This is the same pattern that showed up on an earlier Redbelly DAO task, where a brief's assumption about a listing status turned out to be outdated by the time anyone actually checked. The fix here was the same instinct: verify directly rather than trust the brief, then report what is actually true even when it contradicts what was expected.

So the explainer states the current restricted list as fact, cited to Clause 15, and does not repeat the removal claim. No source existed for removal, so it does not appear as one. An early draft also implied that residency outside the eighteen listed jurisdictions was itself enough to guarantee KYC approval. The Terms only name who is excluded, they do not separately confirm who is cleared, so that implication was removed too.

Staking followed the same logic, backed up with a second source after review feedback pushed for something more direct than a whitepaper inference. Redbelly's whitepaper lists staking as one of RBNT's five core uses, running entirely on Redbelly's own chain rather than through a wrapped token. The developer portal adds the direct link: gaining access to the network at all requires an access credential, proved with a photo ID and biometric checks, before a user can self-enable write access through a specific network smart contract, and staking is executed by calling exactly that kind of write function. Two sources, not one whitepaper line stretched to cover it.

The two claims with no official document

Two of the five questions turned out to have no trace anywhere in official documentation. The ten-wallet-per-identity limit and the typical approval wait time simply do not appear in any published Redbelly source, not the docs site, not the Access portal, not any dev reference.

The task spec anticipated exactly this situation. Its own language allows a claim to be marked as community-reported and unconfirmed rather than dropped outright, as long as it is labeled honestly. That is where Discord came in. Both figures came from two Redbelly moderators, Appie and Daniel Bressoud, answering directly in the support channel, and the ten-wallet figure specifically was verified firsthand by registering ten wallets under a single identity and confirming the limit holds. Both claims went into the explainer tagged as community-reported and unconfirmed with no published document behind them, a label revised after review pointed out that the original mod-verified tag read as more certain than an informal Discord answer supports on its own. Each tag now sits next to the actual Discord screenshot and a direct link to the message, so a reader can check the source firsthand rather than take the label's word for it.

That distinction matters more than it might look. A reader skimming the page should be able to tell, at a glance, which numbers came from Redbelly's own documentation and which came from a community channel with a screenshot attached. Blurring that line to make the page look more authoritative would have been easy and would have failed the task's own stated bar. The approval-time figure got a similar tightening on review: it originally read as "most submissions," a phrasing that sounds like a Redbelly-published statistic. It is not one, so the wording now attributes it explicitly to what community members report, not to Redbelly.

Building it to be read in under ten seconds

The task's quality benchmark was specific: a reader should be able to find their own answer for a stated scenario in under ten seconds. That ruled out long paragraphs up front. Each of the five sections leads with a single bolded sentence carrying the actual answer, then two or three sentences of supporting detail, then the source line in italics below it. Someone scanning for just the wallet limit or just the wait time does not need to read the whole page to find it.

The deliverable itself stayed to one page on purpose, PDF and DOCX both, plus a markdown source file for the companion site. Getting genuinely five sections of sourced content onto a single printed page took a few passes of tightening margins and spacing rather than cutting content, since the goal was density without losing readability.

The companion website

A site went up following the DAO Task Board's own brand kit: deep slate background, slightly lighter slate content cards, one red accent reserved for brand moments, and a separate amber status colour for anything pending or unconfirmed. The PDF sits embedded directly on the page through a proper iframe rather than a link that forces a download, so a reader can open the explainer without leaving the site or triggering an unwanted file save. All five sections render as full formatted content below it, not a collapsed accordion, with the two community-reported claims visibly tagged in amber, each paired with its Discord screenshot and message link, so the distinction from officially sourced claims stays visible and checkable on the page itself, not just described in the source document.

The logo followed the same fix that has come up on every one of these builds. Referencing an image by its GitHub raw URL works fine in the editor preview and then loads inconsistently once deployed to the production domain, so the image gets uploaded directly into the project's own public folder instead and referenced locally. Small detail, but it is the difference between a logo that shows up for every visitor and one that shows up half the time depending on caching.

What this task actually tested

Underneath the formatting, TASK-18 was really testing one thing: whether a contributor will report an inconvenient finding honestly rather than smoothing it over to match what the brief expected. The brief said restrictions were removed. They were not, at least not verifiably. The brief implied five clean answers were sitting somewhere waiting to be written up. Three were. Two needed a Discord conversation with a moderator and firsthand verification instead.

The honest version of the page is more useful than a confident version would have been, because someone reading it under real confusion about their own KYC status needs to know which parts of the answer are documented fact and which parts are the best information currently available. Both have value. Only one should be presented as certain.

DEV Community