Tokenizing a real-world asset, such as a share of a fund or a piece of real estate, is only useful if the transfer can be checked against the rules that regulate it. A public blockchain that lets anyone move a regulated token to anyone else is not usable for that job. Polaris builds compliance into the ledger itself, following the same shape as widely used tokenized-security standards, adapted to a chain with no general-purpose smart contract layer.
Identity and claims, not a KYC form on-chain
Polaris does not store personal information on-chain. Instead, every participant can have an identity record, which is a small structure bound to their address. That record does not hold a name or a document. It holds a hash, a jurisdiction code, and a set of signed claims.
A claim is a small, signed statement about the identity: that they passed KYC checks, that they are an accredited investor, or that they belong to a particular jurisdiction. The claim is signed by whoever issued it, off-chain, before the identity record is created or updated on-chain. The actual KYC process, the document checks, the human review, all of that happens off the chain. What lands on-chain is just the signed result.
Trusted issuers
A claim is only useful if the chain knows whose signature to trust. That is the job of the trusted issuer registry: an on-chain list of addresses that are allowed to issue claims or register regulated assets. Only a governance key can add or remove a trusted issuer. This stops anyone from minting a fake "KYC passed" claim and using it to move a regulated asset.
Transfer rules
Every asset on Polaris declares a compliance rule at the time it is created. This is a fixed, closed set of options rather than arbitrary code, which is part of why Polaris does not need a general smart contract layer for this to work. Some rules require a valid, unexpired claim from a recognized issuer before a transfer succeeds. Some restrict transfers by jurisdiction, either requiring a specific one or blocking a list of them. One rule, OpenTransfer, applies no gate at all: it exists for native POLA transfers and for asset classes deliberately left permissionless.
The compliance rule attached to an asset is not necessarily fixed forever. It can change over the asset's life through an update gated to the issuer or a compliance officer, for example moving from a locked-up issuance phase to open secondary trading. Every such change is written to the receipt trail, so the history of who could transfer the asset, and when, stays visible.
Accounts and holdings can also be frozen by an authorized compliance officer. A frozen sender or receiver fails a transfer, and a frozen holding cannot move, regardless of what claims exist.
A rejection is not a dropped transaction
This is the detail that matters most for anyone building on top of Polaris. When a transfer fails a compliance check, for example because the receiver has no valid KYC claim, the transaction is not silently thrown away.
Polaris draws a hard line between two kinds of checks. Checks that every validator must agree on the same way, such as a valid signature, correct format, and a matching network identifier, happen before a transaction is even accepted into the ledger. Checks that depend on the current state of the ledger, such as an account balance, a nonce, a freeze, or a compliance rule, are evaluated once a transaction has actually been sequenced.
So a compliance failure is recorded, not silently skipped. The transaction is included in the ledger, it goes through the same process as any other transaction, and it produces a receipt with a status of rejected and a specific reason, such as a compliance denial. No balance changes, no holdings move, but the transaction is sequenced and recorded, not dropped. Anyone can look up the receipt and see exactly why it failed. This is deliberate: a compliance failure is meaningful information, both for the person who submitted the transaction and for a regulator looking at the chain's history, and it belongs in the permanent record rather than disappearing.
Why not just use a smart contract
Widely used tokenized-security standards were written for chains where compliance logic lives in user-deployed contract code. Polaris takes a different path: every transaction is one of a small, fixed set of typed kinds, and the compliance engine that enforces transfer rules is part of the application layer, not a contract deployed by a user. That removes an entire category of smart-contract risk, such as reentrancy bugs or upgrade mistakes, while keeping the same enforcement guarantee: a regulated asset cannot move in violation of its declared rules.