Skip to content

docs(ward): add MiCAR white paper#1883

Merged
jjheywood merged 1 commit intomainfrom
micar-whitepaper
May 7, 2026
Merged

docs(ward): add MiCAR white paper#1883
jjheywood merged 1 commit intomainfrom
micar-whitepaper

Conversation

@luisvae
Copy link
Copy Markdown
Contributor

@luisvae luisvae commented May 7, 2026

Summary

  • Add the WARD Token MiCAR white paper to the developer docs under the $WARD section
  • Lives at docs/developer-docs/docs/ward/micar-whitepaper.md; appears in the autogenerated ward sidebar at position 7 (after Supply)
  • Source: WARD MiCAR White Paper v1.0 (January 2026). The "not approved by any competent authority" notice is rendered as a Docusaurus :::warning admonition; numbered MiCAR fields are preserved as bold labels and tables for readability

Notes for reviewers

  • Source document lists Decimals: 6 for WARD; existing introduction.md lists Decimals: 18. Preserved the source's value here verbatim — flagging the discrepancy for someone to reconcile in a follow-up if needed.

Add the WARD Token MiCAR white paper as a new page under the $WARD
section of the developer docs, drawn up in accordance with Regulation
(EU) 2023/1114.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 7, 2026

Review Change Stack

📝 Walkthrough

Walkthrough

This PR introduces a complete MiCAR white paper for the WARD token. The document details regulatory compliance, token characteristics, issuer information, offering mechanics, technical architecture, governance structure, underlying technology, and comprehensive risk disclosures across nine regulatory sections (Parts A–I).

Changes

MiCAR White Paper Documentation

Layer / File(s) Summary
Document Setup & Structure
docs/developer-docs/docs/ward/micar-whitepaper.md
Docusaurus frontmatter (sidebar position, title, description) and document heading with table of contents covering compliance, summary, and MiCAR Parts A–J.
Regulatory Compliance & Warnings
docs/developer-docs/docs/ward/micar-whitepaper.md
MiCAR notification date, approval disclaimer, Article 6 compliance assertions, and regulatory warnings regarding potential value loss and token limitations.
Token Overview & Summary
docs/developer-docs/docs/ward/micar-whitepaper.md
Executive summary describing WARD token version, core characteristics (utility, gas, access, governance, staking), supply/inflation/burn model, and admission-to-trading intent with distribution and staking incentives.
Issuer, Operator & Project Details (Parts A–D)
docs/developer-docs/docs/ward/micar-whitepaper.md
Offeror/issuer legal form, addresses, registration identifiers, management body, business activity, operator/white-paper preparer sections marked not applicable, and comprehensive project details (naming, description, components, classification, milestones, resource allocation).
Offering & Technical Specifications (Parts E–F)
docs/developer-docs/docs/ward/micar-whitepaper.md
Admission-to-trading rationale, absence of fundraising, targeted holders/restrictions, transfer/payment methods and schedules, token functionality classification, native token technical characteristics (decimals, chain, explorer, bridges), interoperability standards, and websites/identifiers.
Holder Rights & Governance (Part G)
docs/developer-docs/docs/ward/micar-whitepaper.md
Purchaser rights/obligations, exercise mechanisms, modification procedures (governance, smart-contract upgrades, issuer patches), future public offers, issuer-retained assets, redemption rules, transfer restrictions, and supply adjustment mechanisms.
Technology & Infrastructure (Part H)
docs/developer-docs/docs/ward/micar-whitepaper.md
Underlying technology (Cosmos SDK with EVM module, IBC/Hyperlane interoperability), consensus and staking parameters, incentive/fee mechanisms, and audit history with named audits, outcomes, and verification links.
Risk Disclosures & Sustainability (Part I)
docs/developer-docs/docs/ward/micar-whitepaper.md
Comprehensive risk categories (offer-related, issuer-related, crypto-asset, implementation, technology), mitigation measures, and due diligence disclaimers.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Suggested labels

docs

Suggested reviewers

  • jlehtimaki
  • deiu
  • jjheywood
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title 'docs(ward): add MiCAR white paper' directly and clearly summarizes the main change: adding documentation for the WARD Token MiCAR white paper.
Description check ✅ Passed The description is fully related to the changeset, providing relevant context about the new document's location, structure, purpose, and noting a discrepancy for follow-up.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch micar-whitepaper

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/developer-docs/docs/ward/micar-whitepaper.md`:
- Line 470: The table row showing "Decimals: 6" in micar-whitepaper.md needs an
explicit cross-reference noting the discrepancy with other docs that show
"Decimals: 18"; update the "Decimals" table row (the table cell labeled
Decimals) to include a short inline note like "See note: decimals differ in
other docs (18) — tracking issue #<ID>" or a link to the tracking issue/PR so
readers aren't confused; ensure the note appears adjacent to the "Decimals"
value and use a consistent wording so automated docs checks can find it.
- Line 96: The document contains three conflicting dates for the same event
("June 1st, 2026", "February 3, 2026", "2026-01-06"); pick a single canonical
date model (e.g., Listing Date vs Publication Date vs Admission Date), decide
which exact date should apply to each label, and update every occurrence to that
canonical label and format (choose one format such as "YYYY-MM-DD" or "Month D,
YYYY") so all references match; ensure the phrases around the tokens (e.g.,
"Token Listing Date for EU", any timeline entries mentioning February 3 and
2026-01-06, and the whitepaper summary paragraph about admission/listing) are
relabeled explicitly (publication vs listing vs admission) and harmonized across
the document.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 53be5359-1b3a-42e9-9dc9-8cdece75c76b

📥 Commits

Reviewing files that changed from the base of the PR and between e5b181d and 7af5f72.

📒 Files selected for processing (1)
  • docs/developer-docs/docs/ward/micar-whitepaper.md


Admission to trading is sought to enable WARD to be admitted to trading on platforms for crypto-assets in the EU.

The initial total supply is 1,000,000,000 WARD. The circulating supply at listing will represent approximately 25.03% of the total supply (250,320,000 WARD), with a fully diluted valuation of approximately USD 2,270,000. Token Listing Date for EU: June 1st, 2026. Distribution will occur via direct listing on centralized and decentralized exchanges; no public sale, IDO or IEO has been conducted. An airdrop program is available through the Warden App for eligible users based on activity and social engagement, with vested allocations automatically staked and bonus incentives of up to 500% for users who lock rather than immediately withdraw. ProtoWardo Ltd expects the token to be admitted to trading on leading EU-based crypto-asset platforms that operate in full compliance with MiCAR.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Resolve contradictory listing/admission dates before publishing.

The document currently states three different dates for the same event timeline (Line 96: June 1, 2026, Line 284: February 3, 2026, Line 491/495: 2026-01-06). This is a material correctness issue in a regulatory white paper and needs one canonical date model (e.g., publication vs listing vs admission), with labels made explicit.

Suggested edit pattern
- Token Listing Date for EU: June 1st, 2026.
+ Planned EU listing date: 2026-06-01.

- - **Q1 2026**: token listing event (February 3rd, 2026) on major CEXs and DEXs; ...
+ - **Q1 2026**: token listing preparations on major CEXs and DEXs; ...

- **9. Starting date of offer to the public or admission to trading**
- 2026-01-06.
+ **9. Starting date of admission to trading (planned)**
+ 2026-06-01.

- **10. Publication date**
- 2026-01-06.
+ **10. Publication date**
+ 2026-01-06.

As per coding guidelines, "**/*.md: Assess the documentation for misspellings, grammatical errors, missing documentation and correctness".

Also applies to: 284-284, 491-495

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/developer-docs/docs/ward/micar-whitepaper.md` at line 96, The document
contains three conflicting dates for the same event ("June 1st, 2026", "February
3, 2026", "2026-01-06"); pick a single canonical date model (e.g., Listing Date
vs Publication Date vs Admission Date), decide which exact date should apply to
each label, and update every occurrence to that canonical label and format
(choose one format such as "YYYY-MM-DD" or "Month D, YYYY") so all references
match; ensure the phrases around the tokens (e.g., "Token Listing Date for EU",
any timeline entries mentioning February 3 and 2026-01-06, and the whitepaper
summary paragraph about admission/listing) are relabeled explicitly (publication
vs listing vs admission) and harmonized across the document.

| Blockchain | Warden Chain (Cosmos SDK with EVM module) |
| Token Standard | Native chain token (not ERC-20) |
| Total Initial Supply | 1,000,000,000 WARD |
| Decimals | 6 |
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add an explicit cross-reference note for the decimals discrepancy.

This page states Decimals: 6 (Line 470), but the PR context indicates another page still shows 18. Add an inline note or link to a tracking issue so readers don’t get conflicting token metadata.

As per coding guidelines, "**/*.md: Assess the documentation for misspellings, grammatical errors, missing documentation and correctness".

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/developer-docs/docs/ward/micar-whitepaper.md` at line 470, The table row
showing "Decimals: 6" in micar-whitepaper.md needs an explicit cross-reference
noting the discrepancy with other docs that show "Decimals: 18"; update the
"Decimals" table row (the table cell labeled Decimals) to include a short inline
note like "See note: decimals differ in other docs (18) — tracking issue #<ID>"
or a link to the tracking issue/PR so readers aren't confused; ensure the note
appears adjacent to the "Decimals" value and use a consistent wording so
automated docs checks can find it.

@jjheywood jjheywood merged commit 3455054 into main May 7, 2026
7 checks passed
@jjheywood jjheywood deleted the micar-whitepaper branch May 7, 2026 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants