"Resolving KYC Confusion for Redbelly Network"

Thirty-three separate messages in the Redbelly community channels, all asking some version of the same five questions. 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. Wrapped RBNT sitting on Ethereum or another chain is just a standard ERC-20 token outside that layer, so trading it on an external DEX needs no Redbelly-side verification at all. That distinction came straight from the individual onboarding SDK overview, no interpretation required.

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.

Staking followed the same logic in reverse. Redbelly's whitepaper lists staking as one of RBNT's five core uses, and it runs entirely on Redbelly's own chain rather than through a wrapped token. Since mainnet access already requires identity verification, and staking is a mainnet action, the KYC requirement follows directly from architecture already established in the whitepaper. Cited, not guessed.

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 a Redbelly moderator confirming them 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 in the accent color as mod-verified through Discord with no published document behind them, rather than presented with the same confidence as the cited claims sitting next to them.

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 no paper trail. Blurring that line to make the page look more authoritative would have been easy and would have failed the task's own stated bar.

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 at the usual verification-dossier theme this project has used across previous Redbelly DAO tasks: ink-navy background, paper-white content cards, the same red stamp accent used only where something is genuinely verified. 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 Discord-verified claims visibly tagged in the accent red so the distinction from officially sourced claims stays visible on the page, not just 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.

Repo: https://github.com/0xDarkSeidBull/dao-redbelly/tree/main/task18-kyc-explainer

Live site: https://daotask18.test-hub.xyz/