This whitepaper describes a system in development. It is not a live product, investment offer, or claim of return.
Whitepaper
Design document for Chicago's planned community blockchain — from vision to a phased implementation roadmap.
Executive Summary
The CUHS design replaces the failed 155-token model with a planned 3-contract architecture. Three smart contracts — a collateral-backed stablecoin (cUHSD), an ERC-1155 community investment vault system with 77 token IDs, and a governance reserve token — are designed to support a data-driven community economy for Chicago's 77 neighborhoods. None of this is live, and none of it is a return.
3
Smart Contracts
77
Community Vaults
77M
Reserve Supply
The Problem
Community token designs often fail when they lack real utility, real collateral, or real data. Speculative tokens without backing collapse. Algorithmic stablecoins without collateral can death-spiral. The CUHS design targets those three failure modes — it does not claim a live deployment yet.
No Utility
Tokens with no real use case become purely speculative. When hype fades, value goes to zero.
No Collateral
Algorithmic stablecoins with no backing assets death-spiral the moment confidence breaks.
No Data
Without real-world data anchoring, token values disconnect from community outcomes entirely.
3-Contract Architecture
The planned CUHS ecosystem rests on three interdependent smart contracts. The cUHSD stablecoin is designed as a stable medium of exchange. Community Investment Vaults are designed to represent shared equity in each of Chicago's 77 neighborhoods, and that equity is not a return. The CUHS Reserve Token is intended to govern the system. Marketplace fee handling is being designed. No distribution or return to holders is offered.
cUHSD Stablecoin
A 1:1 USD peg is being designed. Multi-collateral backing is planned. Intended as a medium of exchange for marketplace transactions. Not live.
Investment Vaults
77 token IDs are planned. Oracle-scored community health is the design input. Shared equity is being designed, and it is not a return.
CUHS Reserve
A 77M fixed supply is the design. DAO governance is planned. Marketplace fee handling is being designed, and it is not a return.
Contract Interfaces
// Contract 1: cUHSD Stablecoin (ERC-20)
interface IcUHSD {
function mint(address to, uint256 amount) external;
function burn(address from, uint256 amount) external;
function collateralRatio() external view returns (uint256);
}
// Contract 2: Community Investment Vaults (ERC-1155)
interface ICommunityVault {
function deposit(uint256 areaId, uint256 amount) external;
function withdraw(uint256 areaId, uint256 shares) external;
function oracleScore(uint256 areaId) external view returns (uint256);
}
// Contract 3: CUHS Reserve Token (ERC-20)
interface ICUHSReserve {
function vote(uint256 proposalId, bool support) external;
function claimFees() external returns (uint256);
function totalSupply() external view returns (uint256); // 77,000,000
}cUHSD Stablecoin
cUHSD is designed as Chicago's digital dollar — an ERC-20 token that would be pegged 1:1 to USD. It is planned as a medium of exchange for marketplace transactions within the CUHS ecosystem. It is not live.
Multi-Collateral Vault
Unlike algorithmic stablecoins that rely on market confidence alone, cUHSD is designed to be backed by a diversified vault of real assets: USDC, DAI, and eventually real-world assets (RWAs). The collateral ratio is designed to stay at or above 150%. No collateral is held today.
Mint / Burn Mechanism
A holder would deposit collateral to mint cUHSD. Redemption is designed to burn cUHSD and release the collateral that backed it. A one-dollar collateral floor is the design target. Redemption is not live, and no dollar value is promised.
Stability Mechanisms
Over-Collateralization
The vault is designed to hold a minimum 150% collateral ratio. For every dollar of cUHSD that would circulate, one and a half dollars of collateral would be held in reserve. That reserve is not live, and no dollar value is promised.
Circuit Breakers
If collateral ratios were to drop below safety thresholds, minting would pause, redemptions would be prioritized, and the DAO would be alerted for governance action. Redemption is not live.
Algorithmic Rebalancing
If the peg were to drift beyond a narrow band, the design would mint or burn cUHSD to pull it back. No interest or yield is part of that plan.
Governance Override
Reserve token holders would be able to vote to trigger emergency measures, adjust collateral parameters, or approve new vault asset types via DAO proposal. That vote is not live.
Community Investment Vaults
The investment vault system is designed as an ERC-1155 contract with 77 token IDs — one for each of Chicago's community areas. Each vault's value would be scored from an oracle-aggregated community health score, not from speculation. No vault is live, and no return is promised.
How it would work
- 1Deposit cUHSD — A holder would choose a community area and deposit cUHSD into its vault. Deposits are not live.
- 2Vault shares — The design would issue ERC-1155 tokens meant to represent a proportional share of that area's vault. No share is issued today, and none is a return.
- 3Score and price — How a vault price would be set is being designed around the oracle score (property values, crime, employment). No price change or return is promised.
7 Data Sources
Each vault's value would be scored from 7 weighted data feeds:
CUHS Reserve Token
The CUHS Reserve is designed as an ERC-20 token with a fixed supply of 77,000,000 — the governance and utility backbone of the ecosystem. It is not live.
Governance
Holders would vote on DAO proposals, elect community councils, and shape protocol parameters across all 77 areas. Voting is not live.
Fee Distribution
Designed to receive a proportional share of marketplace transaction fees once the system is live — not a current yield offer.
Gas Token
Intended for internal operations, proposal staking, and transaction fee payment within the ecosystem. Staking would not pay a yield or a return.
Total Fixed Supply
77,000,000
The design calls for a fixed supply: no inflation and no additional minting.
Oracle System
The oracle system is designed as the bridge between real-world community data and on-chain vault valuations. It would aggregate 7 data sources into a single health score per community area that would inform vault values. It is not live, and it does not promise a return.
Data Integration
Primary data source is the Chicago Data Portal, supplemented by county property records, Bureau of Labor Statistics employment data, local business registries, and Chicago Public Schools performance data. All sources are public, auditable, and updated on known schedules.
Weighted Scoring Formula
HealthScore(area) =
0.20 * PropertyIndex(area) +
0.20 * SafetyIndex(area) +
0.15 * EmploymentRate(area) +
0.15 * SpendingVelocity(area) +
0.15 * EducationScore(area) +
0.10 * BusinessGrowth(area) +
0.05 * DAOCompletionRate(area)Update Frequency & Dispute Resolution
Oracle scores are designed to update weekly for most data sources, with property values updating quarterly. A community member would lock CUHS tokens to challenge an oracle score, which would open a 48-hour review in which the data committee would audit the source data. A successful challenge is designed to release that lock. It would not pay the challenger. A frivolous challenge would forfeit the lock. No payout is part of this design.
Whale Protection
Five interlocking layers are designed so no single actor could dominate the ecosystem. Economic power would be distributed by design, not by hoping large holders would behave. None of these limits are live.
1. Identity & Sybil Prevention
Community-area residency verification and KYC checks are being designed so one person could not operate multiple wallets to concentrate voting power or economic influence. Those checks are not live.
2. Bicameral Governance
Two-chamber voting is planned: token-weighted for economic decisions, one-person-one-vote for community policies. The design would keep a large holder from dominating both chambers. Voting is not live.
3. Economic Deterrents
A progressive fee for large transactions, maximum wallet caps, and anti-flash-loan cooldowns are being designed so large-scale manipulation would be economically irrational. None of these limits are live.
4. Commitment Alignment
Governance voting is planned to use time-locked staking. A longer lock would be designed to carry more voting weight, favoring long-term commitment over quick accumulation. It would not pay a yield or a return.
5. Enforcement
Smart-contract limits on single-wallet holdings, publicly visible large transactions, and community watchdog committees are being designed. A committee would be able to flag suspicious activity for DAO review. None of this is live.
Governance
Each of Chicago's 77 community areas is planned to operate its own DAO. Decisions would be made by the people who live there, not by a central authority. No DAO is live.
Per-Area DAO Structure
Each community area is designed to have its own DAO with an elected council, a treasury, and decision-making power. Area DAOs would direct local spending, project prioritization, and proposals to protocol-level governance. No treasury is live.
Proposal Lifecycle
Draft
An author would submit a proposal with a rationale and a budget. Submitting is not live.
Discussion
A 7-day community discussion is planned. It is not live.
Vote
A 5-day voting window and a 10% quorum are planned. Voting is not live.
Execute
Passed proposals would be executed on-chain. Execution is not live.
Quorum & Treasury
A minimum of 10% of area token holders would need to participate for a vote to be valid. That quorum is designed to keep low-turnout decisions from overriding community consensus. Each area's treasury is designed to be funded by transaction fees. The design does not include a staking payout or a return. Treasury allocation would be decided through the same proposal and voting process. No treasury is live.
Roadmap
A phased approach ensures each layer is built on a solid foundation before moving to the next.
Phase 1: Website + Community Engagement
CompleteNext.js website with 13 pages, community area explorer, tokenomics explainers, and user signup for all 77 community areas.
Phase 2: Mobile App Shells + Admin Tools
CurrentKMP mobile apps (Android + iOS) with 5-tab navigation, admin map editor, portal CRUD, and shared data layer across platforms.
Phase 3: Backend Integration + Smart Contracts
NextKtor backend, real authentication, smart contract development, oracle data pipeline, and testnet deployment of the 3-contract architecture.
Phase 4: Mainnet Deployment + Marketplace
FutureThis phase is planned to cover production smart contract deployment, cUHSD minting, community investment vaults, a marketplace, and DAO governance across 77 areas. None of that is live.
Ready to be part of the future?
Sign up and pick a community area. The blockchain on this page is being designed. It is not live, and it is not a return.
Join CUHS