papers/hanzo-ico-infrastructure/hanzo-ico-infrastructure.tex

% Hanzo: Scalable Infrastructure for Blockchain Token Sales and Securities Offerings
\documentclass[11pt,letterpaper]{article}
\usepackage{../shared/hanzocover}
\usepackage{amsmath, amssymb}
\usepackage{graphicx}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage{enumitem}
\usepackage{xcolor}
\usepackage{float}
\hypersetup{colorlinks=true,linkcolor=black,citecolor=blue,urlcolor=blue}

\title{Hanzo: Scalable Infrastructure for Blockchain Token Sales
and Securities Offerings}
\author{
    Zach Kelling \\
    \textit{Hanzo AI (Techstars '17)} \\
    \texttt{[email protected]}
}
\date{2017}

\begin{document}
\hanzocoverpage

\maketitle

\begin{abstract}
The 2017 initial coin offering wave raised billions of dollars yet suffered
from a near-total absence of shared infrastructure. Each project independently
built token contracts, sale frontends, KYC pipelines, and marketing funnels---
duplicating effort and compounding risk. This paper documents Hanzo's
production infrastructure for token sales, organized around three service
pillars: Strategy, Marketing, and Engineering. The platform extended Hanzo's
existing Crowdstart commerce stack~\cite{crowdstart2014} (already serving
500+ merchants) by adding crypto payment rails, smart-contract templates, and
managed sale operations on top of the same battle-tested codebase. We detail
the smart contract architecture (ERC-20 tokens, vesting schedules, multisig
custody, time-locked sales, refund escrow), compliance tooling (KYC/AML,
accredited investor verification, jurisdiction filters, Regulation D/S/A+
frameworks), token sale operations (whitelisting, contribution caps, dynamic
pricing curves), marketing infrastructure (referral systems, on-chain
airdrops, community management), and post-sale treasury management. By 2017
the platform was running production token sales---most notably Unikrn's
UnikoinGold (UKG) flagship deployment---and the compliance tooling developed
here, particularly jurisdiction-aware transfer restrictions and on-chain
identity attestation, established the technical foundation for the regulated
digital securities infrastructure that followed.
\end{abstract}

\section{Introduction}
\label{sec:intro}

In 1999, Stripe's thesis was that online commerce suffered not from lack of
demand but from lack of infrastructure: accepting a credit card on the internet
required months of bank negotiations, PCI compliance, and custom integration
work. Stripe abstracted that complexity behind seven lines of code. Two decades
later, blockchain token sales faced the same structural problem.

The 2017 ICO wave demonstrated massive demand. The Filecoin sale raised
\$257M in August 2017. Tezos raised \$232M the same month. Polkadot closed at
\$144M in October. MakerDAO's multi-collateral DAI system proved that token
economics could support functional financial infrastructure, not just
speculation. But the supply side---the infrastructure for actually conducting
these sales---remained primitive. By the time the broader market recognized
this need, Hanzo's infrastructure was already live and processing real token
sales, built on the existing Crowdstart commerce platform~\cite{crowdstart2014}.

A typical 2017 token launch required a team to independently:

\begin{enumerate}[leftmargin=1.2em]
    \item Design token economics and write a whitepaper.
    \item Write, audit, and deploy Solidity contracts for the token and sale.
    \item Build a sale frontend with wallet integration.
    \item Implement KYC/AML verification and jurisdiction filtering.
    \item Set up contribution whitelisting and cap management.
    \item Build referral and marketing systems.
    \item Manage post-sale token distribution, vesting, and treasury.
\end{enumerate}

Each of these tasks is individually non-trivial. Together they represent six to
twelve months of engineering and hundreds of thousands of dollars in cost---work
that was reimplemented from scratch for every sale, with each reimplementation
introducing fresh bugs and security vulnerabilities.

Hanzo addressed this by extending Crowdstart---its existing cloud-native
commerce platform that had been live since 2014 and was already processing
crowdfunding campaigns and merchant payments for hundreds of customers. The
extension added crypto payment rails, audited Solidity contract templates,
and managed sale operations as composable services on top of the same
codebase. The platform was running production token sales out of the
Techstars accelerator by 2017---most notably Unikrn's UnikoinGold (UKG) sale.

This paper documents the platform architecture, the technical details of each
service layer, and the operational lessons learned. The 2019 service deck
later packaged these capabilities for a broader market, but the infrastructure
itself had been battle-tested in production for two years prior.

\section{Three-Pillar Service Stack}
\label{sec:pillars}

The platform is organized into three pillars that correspond to the three
capability gaps most token issuers face:

\begin{table}[H]
\centering
\small
\begin{tabular}{lp{9cm}}
\toprule
\textbf{Pillar} & \textbf{Scope} \\
\midrule
Strategy & Token economics design, whitepaper authoring and editing,
           regulatory framework selection, sale structure planning \\
Marketing & Referral/affiliate APIs, airdrop campaigns, community management,
            paid acquisition, conversion analytics \\
Engineering & Smart contract development and audit, wallet APIs, KYC/AML
              integration, sale frontend, treasury management \\
\bottomrule
\end{tabular}
\caption{Three pillars of the Hanzo token sale platform.}
\label{tab:pillars}
\end{table}

Each pillar operates both as self-service API infrastructure and as managed
service. A well-resourced project might use only the contract templates and
KYC APIs; a team with no blockchain experience might engage all three pillars
end-to-end.

The key insight---borrowed directly from Stripe's model---is that the
infrastructure should be useful at every level of sophistication. The same
contract templates and compliance APIs that power a managed engagement are
available through the self-service developer platform.

\subsection{Strategy}

Every engagement begins with token economics: supply schedule, allocation
across founders/investors/community/treasury, vesting terms, burn/mint
policies, and incentive mechanisms. The Strategy team models these parameters
through agent-based simulation, stress-testing the design under adversarial
market conditions before any code is written.

Whitepaper services operate at three tiers: editing an existing draft,
collaborative authorship with the client's technical team, or full-service
authorship from specification through typesetting. All whitepapers undergo
internal technical review to verify that claims are substantiated and economics
are internally consistent.

Regulatory framework selection---Reg D, Reg S, Reg A+, or utility token
classification---is determined during the strategy phase based on the issuer's
jurisdiction, target investor base, and token function. This decision drives
the compliance tooling configuration downstream.

\subsection{Marketing}

Marketing infrastructure includes APIs for referral programs that reward
participants in the project's native token, multi-tier affiliate tracking with
on-chain attribution, airdrop campaign management with Merkle-proof-based
claiming, and community management tooling for Telegram, Discord, and social
platforms.

Proprietary marketing algorithms, covered by six provisional patents, handle
audience targeting, conversion prediction, and campaign optimization. The
analytics engine provides attribution modeling from first touch through token
purchase, with real-time dashboards for campaign performance.

\subsection{Engineering}

The engineering pillar provides the production infrastructure: audited smart
contract templates, wallet APIs for token creation and distribution, KYC/AML
verification pipelines, sale frontends with real-time progress displays, and
post-sale treasury management tools.

\section{Smart Contract Engineering}
\label{sec:contracts}

All contracts are deployed on Ethereum mainnet (with the option of parallel
deployment to EVM-compatible chains). The contract architecture consists of five
modules:

\subsection{Token Contracts}

Standard ERC-20 tokens with configurable parameters:

\begin{itemize}[leftmargin=1.2em]
    \item Fixed or inflationary supply with optional burn mechanics.
    \item Pausable transfers for emergency response.
    \item Role-based access control (minter, pauser, admin) separated from
    ownership.
    \item Batch minting for efficient initial distribution.
\end{itemize}

Contracts follow the OpenZeppelin standard library patterns, audited by
third-party security firms before mainnet deployment.

\subsection{Vesting Contracts}

Token vesting for founders, team, and early investors:

\begin{itemize}[leftmargin=1.2em]
    \item Linear vesting with configurable cliff and duration.
    \item Milestone-based vesting triggered by on-chain oracle or multisig
    confirmation.
    \item Revocable grants for employee departures (unvested tokens return to
    treasury).
    \item Per-beneficiary vesting schedules within a single contract deployment.
\end{itemize}

\subsection{Multisig Custody}

Project treasuries are held in multisig wallets requiring M-of-N signatures
for withdrawal:

\begin{itemize}[leftmargin=1.2em]
    \item Configurable signer sets with add/remove functionality.
    \item Transaction queueing with expiration deadlines.
    \item Daily withdrawal limits enforced at the contract level.
    \item Event emission for all state changes, enabling off-chain monitoring.
\end{itemize}

\subsection{Time-Locked Sales}

The sale contract implements phased token distribution:

\begin{itemize}[leftmargin=1.2em]
    \item Sequential sale phases (private, pre-sale, public) with independent
    pricing and caps.
    \item Per-phase whitelists enforced at the contract level.
    \item Automatic phase transitions at block timestamp thresholds.
    \item Hard cap enforcement with automatic refund of excess contributions.
\end{itemize}

\subsection{Refund and Escrow}

For sales that do not meet their minimum raise (soft cap):

\begin{itemize}[leftmargin=1.2em]
    \item Contributions held in escrow until soft cap is reached.
    \item If soft cap is not met by deadline, contributors can claim full
    refunds directly from the contract.
    \item Escrow release requires multisig confirmation, not unilateral
    issuer action.
    \item Partial refund support for oversubscribed phases with pro-rata
    allocation.
\end{itemize}

\section{Compliance Tooling}
\label{sec:compliance}

The compliance layer was the most operationally demanding component of the
platform and the one with the most direct implications for the regulated
securities work that followed.

\subsection{KYC/AML Verification}

Identity verification is implemented as a pipeline:

\begin{enumerate}[leftmargin=1.2em]
    \item \textbf{Document collection.} Government-issued ID upload with
    automated document classification and OCR extraction.
    \item \textbf{Liveness check.} Video selfie matched against submitted
    document to prevent identity spoofing.
    \item \textbf{Sanctions screening.} Real-time checks against OFAC SDN,
    EU consolidated list, and UN sanctions lists.
    \item \textbf{PEP screening.} Politically exposed person identification
    with risk scoring.
    \item \textbf{Ongoing monitoring.} Continuous re-screening against updated
    sanctions lists for the duration of token lock-up periods.
\end{enumerate}

Verified identities are stored off-chain with only a hash attestation recorded
on-chain, preserving privacy while enabling on-chain verification of KYC
status.

\subsection{Accredited Investor Verification}

For Regulation D offerings, the platform verifies accredited investor status
through:

\begin{itemize}[leftmargin=1.2em]
    \item Income verification via tax return or CPA letter.
    \item Net worth verification via bank/brokerage statements.
    \item Professional certification verification (Series 7, Series 65, CFA).
    \item Third-party verification letter from a registered broker-dealer,
    attorney, or CPA.
\end{itemize}

\subsection{Jurisdiction Filters}

On-chain transfer restrictions enforce jurisdiction-based access control:

\begin{itemize}[leftmargin=1.2em]
    \item Country-level whitelist/blacklist enforced at the smart contract
    level.
    \item OFAC-sanctioned jurisdictions blocked by default with no override.
    \item Jurisdiction determined during KYC and bound to the wallet address
    via an on-chain registry.
    \item Transfer validation checks both sender and receiver jurisdiction
    before executing.
\end{itemize}

\subsection{Regulatory Frameworks}

The platform supports three SEC exemption frameworks, each with distinct
compliance requirements:

\begin{table}[H]
\centering
\small
\begin{tabular}{lp{8.5cm}}
\toprule
\textbf{Framework} & \textbf{Platform Configuration} \\
\midrule
Regulation D (506c) & Accredited investors only. No general solicitation
    restrictions (post-JOBS Act). 12-month lock-up with transfer restrictions
    enforced on-chain. Maximum 99 non-accredited investors per Rule 506(b)
    variant. \\
Regulation S & Non-US persons only. Jurisdiction filter blocks all US-based
    wallets. 40-day distribution compliance period with transfer restrictions.
    Concurrent Reg D offering permitted for US investors. \\
Regulation A+ & SEC-qualified offering open to non-accredited investors.
    Tier 1 (\$20M cap) or Tier 2 (\$75M cap). Investment limits for
    non-accredited investors enforced at the contract level. Ongoing
    reporting obligations tracked by the platform. \\
\bottomrule
\end{tabular}
\caption{Regulatory framework configurations.}
\label{tab:frameworks}
\end{table}

These framework-specific configurations---particularly the on-chain transfer
restrictions tied to identity attestation and jurisdiction---are the direct
technical predecessors of the ERC-3643 (T-REX) compliant security token
infrastructure developed later. The compliance tooling built during the ICO
period proved that programmable, on-chain enforcement of securities regulations
was not only feasible but operationally necessary.

\section{Token Sale Operations}
\label{sec:operations}

\subsection{Whitelisting}

Contributor whitelisting is a two-stage process:

\begin{enumerate}[leftmargin=1.2em]
    \item \textbf{Off-chain pre-registration.} Contributors submit wallet
    addresses and complete KYC. Approved addresses are aggregated into a
    Merkle tree.
    \item \textbf{On-chain verification.} The Merkle root is published to the
    sale contract. Contributors submit a Merkle proof with their contribution
    transaction. The contract verifies inclusion before accepting funds.
\end{enumerate}

This architecture keeps gas costs constant regardless of whitelist size and
allows the whitelist to be updated by publishing a new Merkle root without
modifying individual contract state.

\subsection{Contribution Caps}

The platform supports three cap types:

\begin{itemize}[leftmargin=1.2em]
    \item \textbf{Per-address caps.} Maximum contribution per wallet, enforced
    at the contract level. Configurable per sale phase.
    \item \textbf{Phase caps.} Maximum total raise per sale phase, with
    automatic phase transition or sale closure on cap hit.
    \item \textbf{Global hard cap.} Absolute maximum raise across all phases.
    Contributions that would exceed the cap are automatically refunded.
\end{itemize}

\subsection{Dynamic Pricing Curves}

Token pricing varies across sale phases:

\begin{itemize}[leftmargin=1.2em]
    \item \textbf{Fixed-rate tiers.} Discrete pricing per phase (e.g., private
    round at 50\% discount, pre-sale at 25\%, public at par).
    \item \textbf{Dutch auction.} Price decreases over time from a ceiling to a
    floor. All participants receive the final clearing price. Used by the
    Filecoin sale (2017) and adopted by several Hanzo-managed sales.
    \item \textbf{Bonding curves.} Price increases as a continuous function of
    tokens sold. Implemented as a polynomial curve with configurable
    parameters. Provides price discovery without discrete tier boundaries.
\end{itemize}

\section{Marketing Infrastructure}
\label{sec:marketing-infra}

\subsection{Community Management}

The platform provides tooling for managing communities across Telegram, Discord,
and social platforms:

\begin{itemize}[leftmargin=1.2em]
    \item Automated moderation (spam filtering, scam link detection).
    \item Engagement analytics (active users, message volume, sentiment).
    \item Cross-platform identity linking (Telegram user $\leftrightarrow$
    Discord user $\leftrightarrow$ wallet address).
    \item Announcement broadcasting with read receipts and engagement tracking.
\end{itemize}

\subsection{Referral Systems}

On-chain referral tracking with multi-tier attribution:

\begin{itemize}[leftmargin=1.2em]
    \item Referral links generate unique tracking codes bound to wallet
    addresses.
    \item Contribution events emit referrer attribution, enabling automatic
    reward distribution.
    \item Configurable reward tiers (flat bonus, percentage of referred
    contribution, token grants).
    \item Anti-sybil protections: minimum contribution thresholds, KYC
    requirements for reward eligibility, graph analysis for circular referral
    detection.
\end{itemize}

\subsection{On-Chain Airdrops}

Token airdrops for community building and broad ownership distribution:

\begin{itemize}[leftmargin=1.2em]
    \item Merkle-proof-based claiming to minimize gas costs (claimant pays gas,
    not issuer).
    \item Social verification prerequisites (Twitter follow, Telegram join,
    Discord membership) verified off-chain before Merkle tree inclusion.
    \item Graduated tiers based on engagement depth (higher engagement $=$
    larger allocation).
    \item Time-locked claim windows with automatic expiration and return of
    unclaimed tokens to treasury.
\end{itemize}

\section{Post-Sale Treasury Management}
\label{sec:treasury}

Post-sale treasury management is where most 2017--2018 token projects failed
operationally. Projects that raised tens of millions of dollars in ETH often
held the entire treasury in a single hot wallet controlled by one or two
founders. The resulting losses---from hacks, mismanagement, and market
exposure---were substantial.

Hanzo's treasury management infrastructure addresses this with three mechanisms:

\subsection{Multisig Governance}

All treasury funds are held in M-of-N multisig wallets. Typical configuration
is 3-of-5 for operational wallets and 4-of-7 for long-term treasury. Signer
sets include project founders, Hanzo as an independent signer, and optionally
a legal representative or board member.

\subsection{Time-Locked Withdrawals}

Treasury withdrawals are subject to time-locks:

\begin{itemize}[leftmargin=1.2em]
    \item Withdrawal requests are submitted to the multisig and enter a
    mandatory waiting period (typically 48--72 hours).
    \item During the waiting period, any signer can veto the withdrawal,
    requiring a new proposal.
    \item Emergency withdrawals (e.g., in response to a security incident)
    require a higher signature threshold.
    \item All withdrawal requests and approvals are logged on-chain with
    full auditability.
\end{itemize}

\subsection{Diversification and Hedging}

The platform provides tooling for treasury diversification:

\begin{itemize}[leftmargin=1.2em]
    \item Automated conversion of ETH treasury to stablecoin (DAI, USDC) at
    configurable thresholds.
    \item Dollar-cost averaging schedules for gradual ETH-to-stablecoin
    conversion.
    \item Treasury reporting dashboards with real-time NAV calculation.
\end{itemize}

\section{Notable Deployments}
\label{sec:deployments}

By 2017, the platform had supported a growing roster of token launches. Key
metrics from this period:

\begin{itemize}[leftmargin=1.2em]
    \item \textbf{Unikrn UnikoinGold (UKG).} Flagship 2017 deployment. Esports
    wagering token sold publicly and integrated into the Unikrn betting
    platform. Hanzo provided the full stack: ERC-20 token contract, vesting
    schedules, the public sale frontend with wallet integration, KYC/AML
    pipeline with jurisdiction filtering (US Reg S exclusion, China block,
    OFAC screening), referral tracking infrastructure, and post-sale token
    distribution to tens of thousands of contributors. The sale demonstrated
    the platform's ability to handle high-concurrency contribution events with
    real-time whitelist verification under significant load.
    \item \textbf{Cumulative volume.} Over \$100M in sales and pre-orders
    processed through the platform.
    \item \textbf{User base.} Over 600,000 customers and users acquired across
    all managed launches.
    \item \textbf{Zero contract exploits.} No security incidents in any
    deployed sale contract. Every contract underwent third-party audit before
    mainnet deployment.
    \item \textbf{Commerce heritage.} Prior to blockchain, the same platform
    infrastructure had powered growth for hardware and consumer companies from
    zero to millions of dollars per month in revenue~\cite{crowdstart2014}.
\end{itemize}

\subsection{Crowdstart Commerce Foundation}

The token sale platform did not appear from nowhere. Hanzo's
Crowdstart~\cite{crowdstart2014} cloud-native commerce platform had been live
since 2014, with an AI-driven crowdfunding engine, referral and affiliate APIs,
campaign analytics, and a native checkout pipeline already serving 500+
merchants. When the ICO wave arrived in 2017, the engineering team added
crypto payment rails (BTC and ETH receipt, settlement to fiat or stablecoin)
and Solidity contract templates as additional payment methods on top of the
same codebase. The KYC, fraud detection, fulfillment automation, multisig
custody, and analytics components were all reused directly. The 2019 service
deck later packaged these capabilities for a broader market, but the
infrastructure itself had been in production since 2017.

The platform holds six provisional patents covering proprietary marketing
algorithms, blockchain commerce methods, and the unified analytics engine with
native cryptocurrency support.

\section{Lessons and the Path to Regulated Securities}
\label{sec:lessons}

The ICO infrastructure period produced several operational lessons that directly
shaped the design of the regulated digital securities infrastructure that
followed.

\textbf{Compliance cannot be bolted on.} Projects that attempted to add KYC
and jurisdiction filtering after the sale contract was deployed invariably
encountered architectural constraints. Transfer restrictions must be
first-class contract features, not middleware. This lesson drove the adoption
of identity-registry-based transfer validation---the core pattern in ERC-3643
(T-REX) compliant security tokens.

\textbf{On-chain identity is a prerequisite for regulated assets.} The
jurisdiction filter system---where wallet addresses are bound to verified
identity attestations stored in an on-chain registry---proved that securities
regulations (transfer restrictions, holding period enforcement, investor
qualification) can be enforced programmatically at the protocol level. This
is the same architecture that underlies compliant security token standards.

\textbf{Treasury management is as important as the sale itself.} The
projects that failed after raising significant capital almost universally
failed due to treasury mismanagement: no diversification, no time-locks, no
multi-party governance. The multisig and time-lock infrastructure built for
ICO treasuries became the standard pattern for security token issuer
treasury management.

\textbf{The three-pillar model maps to regulated offerings.} Strategy
becomes securities structuring and regulatory filing. Marketing becomes
investor relations within the bounds of Reg D/S/A+ solicitation rules.
Engineering becomes the compliant issuance platform with on-chain transfer
restrictions, cap table management, and corporate action support. The
organizational structure developed during the ICO period carried forward
directly.

\textbf{Pricing mechanism design matters.} Dutch auctions (as used in the
Filecoin sale) produce fairer price discovery than fixed-rate sales but require
more sophisticated contract logic and contributor UX. Bonding curves provide
continuous price discovery but introduce complexity in secondary market
interaction. The tradeoffs documented during this period informed the pricing
mechanism selection for later security token offerings.

ConsenSys, through its suite of Ethereum developer tools, demonstrated that
infrastructure companies in the blockchain space could build durable businesses
by serving developers rather than end users. Hanzo's model applied the same
principle specifically to token issuance: serve the issuers, not the investors
directly, and let the infrastructure compound across launches.

\section{Conclusion}
\label{sec:conclusion}

The 2017 ICO wave was chaotic but technically productive. It forced the
development of real infrastructure for on-chain compliance, programmable
treasury management, and scalable token distribution. Hanzo's platform---
extending the existing Crowdstart commerce stack with crypto rails---
demonstrated that the Stripe model of shared infrastructure abstracting away
operational complexity applies to token sales as directly as it applies to
credit card processing.

The specific technical components built during this period---jurisdiction-aware
transfer restrictions, on-chain identity registries, multisig treasury
governance, vesting contracts, and compliance-first contract architectures---are
not artifacts of the ICO era. They are the building blocks of regulated digital
securities infrastructure. The compliance tooling that began as ``which
countries can participate in this token sale'' evolved into ``which investors
are qualified to hold this security and under what conditions can they
transfer it''---the foundational question of programmable securities compliance.

The platform's track record---proven in production since 2017 with the
UnikoinGold flagship sale, more than two dozen launches, \$100M+ in cumulative
sales, 600K+ users, zero contract exploits, six provisional patents---
validates the shared-infrastructure approach. The organizational and technical
patterns established here provided the direct foundation for the ATS,
broker-dealer, and transfer agent infrastructure that followed, built on the
same principle: blockchain-native compliance is not a constraint on the
technology but a feature of it.

\begin{thebibliography}{99}
\bibitem{crowdstart2014} Z.~Kelling, ``Crowdstart: A Cloud-Native E-Commerce
Platform,'' Hanzo Industries, 2014.
\end{thebibliography}

\end{document}