ProductStocksPortfolioDashboardDocsAboutSettings
Stockfolk Docs

Build ownership into everyday activity.

This documentation describes the Stockfolk product model, intended architecture, user flows and production considerations.

Getting started

Stockfolk is designed around a clear flow: connect an account and wallet, select a portfolio allocation, generate eligible reward value, and claim supported assets onchain.

  1. Connect. Link a compatible wallet and create your Stockfolk profile.
  2. Allocate. Choose how supported assets should be weighted.
  3. Earn. Eligible partner activity can generate reward value.
  4. Review. See pending rewards and allocation.
  5. Claim. Settle supported assets to your wallet once production settlement is enabled.

How it works

User activity and asset settlement are separate. Reward events first enter a ledger. Portfolio rules determine allocation. Settlement occurs only after an authorized claim.

FlowEligible activity → Reward ledger → Allocation engine → Settlement → User wallet

Architecture

A production deployment should keep client code lightweight and move partner verification, reward calculations, rate limits and settlement orchestration into auditable services.

ArchitectureClient → Reward API → Ledger → Allocation service → Settlement contract

Public client code should never contain private keys or privileged settlement credentials.

Tokenized stocks

“Tokenized stock” is an umbrella term. The rights attached to a token depend on the issuer, legal structure and jurisdiction. A production Stockfolk deployment should disclose the exact asset issuer, contract address, pricing source, custody or redemption model, and user rights for each supported market.

Portfolio system

Users can set allocation across supported assets. New finalized reward value can be assigned according to the active allocation. Changes should apply prospectively and be recorded in account history.

User-directed by designStockfolk should provide controls and information, not personalized investment recommendations.

Security

Production architecture should use wallet signatures for authorization, server-side verification for reward events, rate limits, replay protection, audit logs, asset allowlists and monitored settlement queues.

Private keysStockfolk should never request or store user seed phrases or private keys.

Risk

Tokenized assets can lose value and may involve market, liquidity, issuer, counterparty, bridge, custody and smart-contract risk. Availability and legal treatment may differ by jurisdiction.

Privacy

A production browser integration should minimize collection, process only data necessary for reward attribution, and publish a clear data-retention policy. Sensitive browsing content should not be collected merely because an extension can access it.

FAQ

Where do rewards come from?

Reward value can be funded by eligible commercial activity such as partner or affiliate economics. Production sources should be disclosed clearly.

Can I change my allocation?

Yes. The interface is designed to let users update portfolio weights for future reward allocation.

Can stock prices fall?

Yes. Any market-linked asset can move up or down.

Does Stockfolk control my wallet?

The intended model is user-authorized and non-custodial. Production behavior should be verified against deployed contracts.

Is Stockfolk investment advice?

No. The product should provide information and user controls, not personalized investment recommendations.

Roadmap

01

Product shell

Core website, dashboard, portfolio and documentation.

02

Wallet layer

Supported-wallet connection and account authorization.

03

Reward ledger

Verified event ingestion and transparent reward accounting.

04

Settlement

Asset allowlists, claim routing and production monitoring.