Chat. Connect. Trade.

1. Product overview

Kivo is designed as a social application first, with wallet identity and trading built into the experience instead of existing as separate products.

2. Architecture

Kivo has two primary clients and a shared domain model. Security-sensitive infrastructure is deliberately separated from presentation.

Design principle

The client can render and preview state, but authority must eventually live server-side for anything that can affect money, moderation, reputation, permissions or account state.

3. Identity & wallets

Kivo uses wallet-based identity. A public wallet address can anchor a profile without making private wallet information part of the social graph.

• Public profile data is separate from private balances and recovery material.
• Kivo never asks users to submit seed phrases or private keys to the web application.
• Web users authorize transactions through their own external wallet.
• Display names, avatars, posts and usernames never grant administrative authority.
• Account, wallet, profile and community-admin permissions are separate concepts.

4. Social layer

The social model covers profiles, posts, follows, groups, memberships, reactions and conversations. Social content is validated before it enters the local domain state.

5. Channels & creator reputation

Channels are broadcast-first. They can be public or private, and the owner is the only account permitted to publish.

Reputation

Kivo's channel reputation ranges from 0–1000 and combines useful behavior rather than follower count alone.

• Quality — 25%
• Consistency — 15%
• Engagement — 18%
• Retention — 16%
• Trust — 14%
• Growth — 12%

The model applies safety penalties, diminishing returns for reach, score smoothing and progression tiers: New → Rising → Established → Trusted → Notable → Elite.

Discovery

Discovery ranks channels using reputation, freshness, activity and measured growth signals. Raw clicks or follower count alone should never determine reputation.

6. Trading architecture

Kivo's trading experience is built behind a product-neutral adapter. The UI should expose the user-facing trade flow without exposing internal routing infrastructure.

Important boundary

Kivo must not present a trade as successful merely because a quote was obtained. A production trade requires signing, submission and on-chain confirmation.

7. Security model

• Non-custodial web: no seed phrases or private keys are accepted.
• Transaction validation: chain, target, transaction shape and signer intent are checked before authorization.
• Trade safety: slippage, price impact, quote age and minimum output are validated.
• Social safety: content limits, media validation and anti-gaming rules are part of the domain model.
• Backend authority: future production services must recompute reputation, permissions, moderation and abuse signals server-side.
• Secrets: credentials must never be embedded in client bundles or public repositories.

8. Data, privacy & media

Kivo follows a local-first direction for lightweight chat state while keeping security-critical authority outside the client.

• Social posts are limited in size and media URLs are treated as untrusted presentation data.
• Images should be resized and compressed before upload rather than sending originals by default.
• Inline data: media is rejected by the social validation boundary.
• Production media infrastructure should enforce content type, byte limits, malware scanning, retention and deletion policies.

9. Web & mobile

Web

The web client runs on Cloudflare Pages and supports external browser wallets through the browser provider. Wallet sessions are ephemeral and transaction authorization remains with the user's wallet.

Mobile

The mobile application is React Native with a native Android shell. Its current navigation covers onboarding, wallet setup, chats, discovery, trade, profiles, groups, channels and settings.

Branding

Kivo is the only user-facing brand. Internal trading implementation names, source-project references and unrelated logos must never appear in the product UI.

10. Current status

11. Roadmap

1. Finish social persistence and real wallet/profile identity.
2. Implement channel subscriptions, notifications, moderation and creator analytics.
3. Introduce authoritative backend reputation and abuse prevention.
4. Complete production wallet signing and trade E2E tests.
5. Verify supported chain/token configuration independently.
6. Complete Android release signing, store compliance and production observability.
7. Harden media processing, privacy controls and account lifecycle operations.

12. Development rules

Every architecture-changing implementation should update the corresponding documentation in the same change. Security-critical changes require tests or an explicit release gate. Never replace a missing production integration with fabricated balances, quotes, trade confirmations or backend state.

Kivo
├── mobile/       React Native application
├── web/          Cloudflare Pages web client
├── docs/         Product and engineering documentation
└── trading/      Trading integration boundary