Why Our Loyalty Token Doesn’t Have an ICO (And Why You Can’t Buy It)

Most blockchain loyalty programs come with the same pitch: “What if your supermarket points were also an investment that could go up in value?”

We did not build that.

CoinPort Loyalty Points (CPP) launched this week on five EVM blockchains: Ethereum mainnet (canonical), BNB Smart Chain, Arbitrum One, Polygon, and Avalanche C-Chain — same contract, same address on each. CPP is the loyalty rewards token for members of CoinPort Exchange, an AUSTRAC-registered Virtual Asset Service Provider (VASP) operating in Australia. Members earn CPP by trading, holding qualifying assets, and engaging with the platform. They redeem CPP inside the CoinPort ecosystem for free airdrop allocations, trading rebates, priority support, and other member perks.

What CPP is not: an investment. An ICO. A token sale. A tradeable asset. A governance token. A stablecoin. There is no way to buy CPP. There never will be.

That set of “nots” is not an oversight. It’s the design.

## The question every loyalty-token project has to answer

When you put a loyalty point on a public blockchain, you face a fork in the road. Either the token can be freely transferred and traded — in which case you’ve effectively launched a cryptocurrency, with all the regulatory, taxation, and consumer-protection implications that follow — or the token can’t, in which case you’ve put a database row on Ethereum and have to justify why that’s worth doing at all.

The first path is well-trodden. It also tends to attract regulator attention quickly, especially in jurisdictions like Australia where ASIC’s INFO 225 explicitly treats secondary-market trading as evidence of “financial product” status. Get classified as a financial product, and your loyalty program needs an AFSL. Most exchanges don’t want a second AFSL just to run a points program.

The second path looks pointless until you understand what you’re actually buying with it: independently verifiable supply, public audit trails on every issuance and redemption, and a member-trust mechanism that doesn’t depend on you. Members don’t have to take CoinPort’s word for how many CPP exist or how they were issued — they can read the contract themselves.

We chose the second path. The rest of this post is about how we made that path actually work.

## Four design constraints that do all the work

The legal scaffold for “this is a loyalty program, not a financial product” rests on four design constraints. Each one constrains what CPP can do; together they keep the regulatory analysis stable.

### 1. Closed-loop only

CPP cannot be sent to external wallets, traded on a secondary market, swapped for other tokens, or used as payment outside CoinPort. The legal basis is ASIC’s framing: a token’s status turns substantially on whether it trades on secondary markets. CPP, by construction, doesn’t.

### 2. No fiat conversion

CPP can’t be redeemed for cash. The redemption catalog contains only in-program benefits. This is what keeps CPP outside the “currency” framing.

### 3. Bounded redemption value

A member can redeem at most AUD $1,000 worth of CPP per calendar year (GST inclusive). The cap is operational, enforced at redemption time. It reinforces the loyalty-not-investment framing and bounds CoinPort’s reporting obligations under the AML/CTF Act.

### 4. No profit expectation

CPP is marketed and operated as a reward, not as an investment opportunity. Redemption values are administrative — set by CoinPort, published in the catalog, with 30 days’ notice for changes. There’s no price discovery, no market, no implicit promise of appreciation. This addresses the Howey-style “profit from the efforts of others” framing that ASIC also references.

Together, these four are load-bearing. Drop one, and the analysis flips.

## Custodial by design

The other choice that surprises people is that CPP is custodial. Every CPP token in existence sits in a single CoinPort-controlled hot wallet on each chain. Members don’t hold private keys to “their” CPP. Their balance lives in our off-chain member ledger.

This sounds like it defeats the point of being on-chain. It doesn’t, but it requires explaining.

The on-chain layer holds the program-level state: total supply, every mint, every burn, the privileged role assignments, the pause status. These are the facts that need to be independently verifiable — they’re what protects members from us quietly minting more than we said we would.

The off-chain layer holds the member-level state: who has earned what, who has redeemed what, expiration timers, KYC tier limits. These are operational facts that don’t benefit from on-chain residence and that benefit substantially from being modifiable for compliance purposes (court orders, sanctions, error correction).

If we minted CPP directly to per-member on-chain addresses, we would either need (a) to give members the private keys, which makes the program de facto open-loop and breaks the regulatory framework, or (b) to manage thousands of CoinPort-controlled addresses, which doesn’t add transparency over a single hot wallet plus an off-chain ledger.

Model B custody — single hot wallet, off-chain member ledger — is the standard pattern for compliant custodial loyalty schemes. We’re just bringing the on-chain supply transparency that database-only programs don’t have.

## Why multi-chain

CPP is deployed on five target chains: Ethereum mainnet (canonical), BNB Smart Chain, Arbitrum One, Polygon, and Avalanche C-Chain. Same contract bytecode, same contract address (0x37dAa811B668bf5d19692A7F79579B7BFaaB26A5) on each. All five live as of launch.

These are sibling deployments, not bridged. There’s no on-chain mechanism that moves CPP from one chain to another, and there’s no canonical chain at the contract level. Each chain is internally complete.

Why go multi-chain at all? Four reasons:

1. Ecosystem reach. Each supported chain anchors CPP inside a distinct cryptocurrency ecosystem — Ethereum, BNB, Arbitrum, Polygon, and Avalanche each have their own wallets, indexers, integrations, and user bases. A multi-chain footprint means the loyalty program is visible from each of those ecosystems’ native tooling, not only Ethereum-first tooling.

2. One canonical identifier. Because the contract is deployed at the same address on every chain, members, integrators, auditors, and block explorers can recognise CPP by a single string regardless of which chain they’re querying. That’s a meaningful simplification for tracking, reconciliation, listing submissions, and member-facing copy — no per-chain address tables to maintain or get wrong.

3. Resilience. A program-level commitment to “this supply is what we said it is” benefits from not depending on a single chain’s continued operation.

4. Member accessibility. Members who already operate on BSC, Arbitrum, Polygon, or Avalanche don’t have to reach for an Ethereum wallet to interact with the program down the line.

The honest trade-off: independent per-chain supply means our 200M-per-chain cap implies a program-wide ceiling of up to 1B CPP across five chains. That’s a real commitment difference from “200M total,” and we surface it explicitly in the white paper rather than hiding it. Members and regulators reading the documents should see the same numbers we operate under.

## What we’d do differently if we were doing it again

A few honest reflections.

The closed-loop transfer guard. Our original contract design enforced the closed-loop constraint with an on-chain _update hook. We disabled it before mainnet launch and now enforce closed-loop behaviour at the application layer instead. The on-chain enforcement was operationally brittle — every legitimate program action looked like a violation to the guard and required compliance role authority to execute — and the application-layer enforcement is functionally equivalent given Model B custody. If we were starting over, we’d skip the on-chain guard from the start.

Document the “what CPP isn’t” upfront. The single most useful thing we did in the launch communications was to lead with the explicit list of things CPP isn’t (not an investment, no ICO, not for sale, can’t be withdrawn). Crypto-literate readers will assume the worst until told otherwise. Saying it directly saves everyone time.

Be honest about the regulatory framework. The temptation when launching anything on a blockchain is to gloss the regulatory situation. We chose to put the entire Australian compliance analysis in the documentation set — the ASIC framing, the AUSTRAC monitoring schema, the ATO tax treatment, the four design constraints that keep the program out of “financial product” territory. It’s longer. It’s also a lot harder to argue with, which means the document set does compliance work for us.

## What’s next

With Ethereum, BSC, Arbitrum, Polygon, and Avalanche all live, the multi-chain rollout itself is complete. The next phase is growing program usage inside each of those ecosystems and expanding the redemption catalog — particularly the free airdrop category, which we expect to become one of the main draws of the program once a steady stream of CoinPort-listed airdrops is in flight.

Beyond that: the smart-contract upgrade authority is intended to be retired in the first 12 to 18 months of operation, after which CPP becomes effectively immutable on each chain. We want the program to be the kind of thing that runs the same way ten years from now as it does at launch.

If you’re building a loyalty program, a member rewards system, or any kind of “this is on a blockchain but isn’t a cryptocurrency” project — I hope the design choices here are useful. The full set of program documentation is at coinport.com.au, including the white paper, the terms and conditions, the compliance framework, and the legal-situation summary. The contracts are verified on Etherscan, BscScan, Arbiscan, PolygonScan, and Avascan — read them, audit them, ask us about them.

We didn’t build a cryptocurrency. We built a loyalty program that happens to run on chains designed for cryptocurrencies. That distinction is everything.