The Foundation Report

UnyKorn exists because most of what is sold as "digital transformation" is a pile of disconnected tools, each one asking for trust it has not earned. I wanted to build the opposite: systems that check each other, that write down what they did, and that a person or a machine can verify without taking anyone's word for it.

This edition is a founding report, not a victory lap. It describes what UnyKorn LLC has built, what is running on a public address today, what is still gated behind a plan or a key or a signature, and what we chose not to build. Every figure now resolves to a row in a published evidence ledger with the command that produced it. Where we could not measure something, we say so instead of estimating.

Three commitments run through every system in this report. Ownership: the person or company keeps their keys, their records, and their right to leave with their data. Receipts: every action that matters writes a record that can be recomputed. Flat fees: we charge for work, never a percentage of anyone's recovery, trade, or income.

One of those commitments needed sharpening this year, and it is worth saying plainly rather than quietly editing. Until September we also said we paid no referral commissions at all. We now do: the introducer network opened, and people who bring us business get paid for as long as that relationship keeps producing. What has not changed, and will not, is where the money comes from. Every commission is carved out of our own platform fee, already agreed with the client. None of it touches an investor's subscription or an issuer's proceeds, and because the shares are normalised across whatever chain exists, recruiting more people into the network cannot enlarge the pool or add a cent to what any client pays. A network funded out of client money is a network that eventually eats its clients. This one is funded out of ours.

This year the pieces became a network: a fraud desk that pays for itself, an athlete platform with real verification, a settlement rail a machine can pay, and a build discipline strict enough that our own mistakes are written up in the same document as our wins. You will find both here.

Kevan Burns
Managing Member, UnyKorn LLC

Published as the founder's statement for this edition and reviewed before each annual edition.

What UnyKorn LLC operates as of September 2026, counted from served responses, API calls, on-chain reads and repositories on the dates in the ledger. Counts of use (visitors, customers, revenue) are not published in this edition because no full reporting period exists yet.

UnyKorn is a small company. The problems it works on are not. This chapter places the work against what the Bank for International Settlements, the International Monetary Fund, the World Bank Group, the World Economic Forum and the FBI's complaint center publish about money, identity, fraud and trust. Each card quotes the source verbatim, in at most twenty-five words, with its URL and the date we retrieved it. The IMF paper is quoted from the PDF on the IMF eLibrary; the WEF tokenization report is quoted short and attributed in full, and none of its figures or charts are reproduced.

What each finding asks of a builder, and what UnyKorn does about it

We combine AI agents, autonomous workflows, blockchain infrastructure, tokenization standards, and human-centered product design to turn emerging technology into practical tools, platforms, and experiences. The distinguishing choice is architectural: every system writes a receipt that the next system can check, so the network compounds instead of fragmenting.

The operating model has five stages. Intelligence produces an answer or a screen. Automation carries it through workers, sweeps, and webhooks. Ownership binds it to a person's wallet, signature, or namespace. Settlement collects a flat fee from a person or a per-call price from a machine. Experiences put it in front of someone: a site, a desk, a Telegram bot, a print sheet with a QR code.

Seven product lines, each with its own companion report in this family. The status column uses the labels defined in the colophon.

Four categories, chosen because each can be evidenced by something a reader can open. We do not publish environmental figures in this edition: our compute is a rented edge network and a single workstation, and we have not measured it.

Here: the problem, the system, and where it stands, with each status line bound to its ledger row. The first seven have a companion report in this family carrying their architecture and full status table. The RWA Operating System and the Introducer Network do not yet — they arrived after the companion set was written, and until Edition 2027 their detail lives on the live surfaces themselves, where the counts, the compensation guard and the receipt-chain verifier can be exercised directly rather than read about.

Human approval where it matters

An assistant can answer; it cannot publish. Athlete profiles, endorsements and agreements are countersigned at a desk by a person before they appear anywhere. The desk itself requires a username, a password and a one-time code sent to the founder's phone.

Data minimization

The scam check runs entirely in the browser; nothing is uploaded unless the person chooses to open a case. Athlete profiles are private by default, exportable and withdrawable by the athlete, and never include biometrics. Profiles for children under thirteen are refused outright; minors require a guardian to act first.

Keys and secrets

Signing keys and API credentials live as worker secrets and are never logged or echoed. The verification signing key's public half is published at a well-known address so anyone can check an assertion without asking us. Client evidence is encrypted in the browser with envelope keys before it is stored.

Review before release

Every public surface passes a served-site test suite and a copy-accuracy sweep for phrases we have decided never to use, and this report passes a guard that rejects any figure without a ledger row. Contract code under test is labelled not audited and not deployed until it is.

Incidents, written down

Two incidents are recorded in the same receipts as our releases: a receipt-chain fork in the HEARTH runtime in August, where the stop rule fired correctly and a writer lock closed the defect class; the replacement of a live CRM in September, restored the same day.

Plain disclaimers

No recovery is promised. No token is sold. Assistant answers cite their sources or say they cannot. Nothing on our sites is legal, tax or investment advice, and the sites say so.

UnyKorn LLC is founder-led. What substitutes for a board at this stage is a written constitution that binds the founder as much as anyone else, plus a list of decisions only the founder may make, kept in the open inside each repository.

Everything below is a target unless labelled otherwise. Dates are intentions, not promises.

Definitions

• Ledger row: a record in data/ledger with an id, a kind, a claim, a label, evidence (method, reference, command, retrieval date) and optional metrics.
• Served check: an HTTP request to the live site whose response is compared with an expected value; never a read of source code.
• Receipt: a stored record with a recomputable digest and a link to the previous record.
• Verification assertion: a JSON document signed with ES256 whose public key is published at a well-known address.
• Flat fee: a price fixed before work begins, independent of any amount recovered, traded or earned.

Methodology for every metric

• Repositories: the GitHub REST API listing of repositories owned by the account, public and private counted separately; public non-archived repositories shallow-cloned and counted by a script that records lines of code by language and the number of Rust test attributes (a static count, never "tests passing").
• Zones and hosts: the estate inventory snapshot of the Cloudflare account, with each host classified by what it actually serves.
• Served checks: tests/fulltest.py issues requests to the live domains and records pass, fail and warn; warns are external quota limits, not defects.
• On-chain reads: Stellar Horizon and Solana JSON-RPC calls recorded verbatim in the ledger rows; anything a document asserts that the chain does not show is labelled ABSENT.
• Research: the ORCID public API for the works count and DOI registry content negotiation for citations; where a registry did not answer on retrieval day the row says so.
• Documents: each internal document hashed with SHA-256 and carried as a dated artifact, never as a source of truth for a figure.
• External sources: fetched from the institution's own site or PDF, quoted verbatim in at most twenty-five words, with URL and retrieval date.

Technical stack

Cloudflare Workers, Static Assets, D1, KV, Email Routing, service bindings; JavaScript and Python tooling; Rust for research chains and the simulation engine; Node.js for the HEARTH runtime; ES256 and EIP-4361 for signatures; x402 v2 with USDC on Base; local image generation on a single workstation; this report rendered from YAML ledgers by a Python generator, guarded before deploy.

Risk disclosures

• Plan limits. Several systems run on free tiers with daily quotas and a CPU ceiling; intermittent errors on the heaviest requests are known and listed as gated.
• Single operator. The company is founder-led with contract collaborators; continuity depends on the written receipts, the ledger and the source-of-truth repositories described here.
• Regulatory. Athlete compensation, digital assets and payments are regulated differently by jurisdiction; the platforms publish a sourced jurisdiction table and route regulated strings to counsel, but no statement here is legal advice.
• Third parties. Payments, email, identity and settlement depend on outside providers; a change by any of them changes what is gated.
• Security. Keys and secrets are held as worker secrets; a compromise of the founder's accounts would be a compromise of the estate. Incidents are recorded; there is no external audit yet.
• Legacy material. Older documents in the estate make claims that measured rows do not support; they are carried as hashed artifacts and superseded by the measured rows.
• Research code. Layer-1 workspaces and contract standards are research and test code unless a report says otherwise; none is deployed to a public mainnet.

Contact and partnerships

Partners: partners@blockchainfraud.org. Press and corrections: hello@blockchainfraud.org. Security: security@blockchainfraud.org. Athletes and brands: nil33.com/apply.

This is the "it is more than what is showing" chapter. The Cloudflare account behind UnyKorn holds the zones below. Not all of them are UnyKorn RWA products: the off-thesis properties are listed with what they actually are, so the breadth of the estate is honest rather than implied. Counts come from the DNS inventory because the platform site publishes no machine-readable registry.

Zones

Live properties probed for this edition

Each host was requested over HTTPS on the retrieval date; the status and the title it served are recorded as they were.

Every repository owned by the FTHTrading GitHub account, from the GitHub API. Public repositories are listed by name with language, licence, lines of code and last push; private repositories are aggregated to counts and never named. Lines of code are counted by a script in the ledger tooling, excluding documentation, data and generated directories. The Rust test column is a static count of test attributes, not a passing-test count. Two Layer-1 workspaces that were once suspected of being the same artifact were checked by their git remotes and are different repositories; nothing is summed across them.

Private repositories by language

Public repositories

Every DOI-registered work, with the concept record and its versions kept separate and the citation pulled from the DOI registry rather than typed. The ORCID public API lists the works count used in this report; a profile surface in the estate states a larger number, and that discrepancy is recorded rather than hidden.

Discrepancy on record: A profile surface in the estate states 38 research entries against this ORCID iD; the ORCID public API returns 3 works. The report renders the API count and lists this discrepancy rather than the larger number.

Entities and identifiers, with the open items visible rather than papered over. Publishing the gap is stronger than publishing nothing.

Internal documents carried as hashed artifacts

Each document is identified by its SHA-256 so a reader can ask which version a statement came from. None of them is a source of truth for a figure in this report.