The client's reasoning usually goes: "my token isn't a security, because it's backed by a real asset." It sounds logical. It's wrong.
These are two different axes
"Security" describes the regulatory nature of the instrument: whether it's a regulated investment contract.
"Asset-backed" describes what supports it: whether there's a real asset behind it.
A token can be both at once. In fact, most serious RWA projects are: an asset-backed security token — a regulated security, backed by a certified asset.
Adding backing does not exempt you from securities law. It only makes the instrument more solid.
How it's determined
In the United States, the classic reference is the Howey test. There's a security when someone:
- invests money,
- in a common enterprise,
- expecting profit,
- derived from the efforts of others.
Most real estate tokenizations tick all four boxes. So do mineral production offerings, revenue-share structures, and virtually anything that promises a return.
In Latin America the equivalent principle is substance over form: the regulator looks at what the instrument actually is, not the name you gave it. In Peru, for example, Law 30050 covers any mass advertising of financial assets aimed at raising money from the public in exchange for a return — regardless of what the asset is called.
The red flag you should recognize
If your token design combines several of these elements, you're almost certainly looking at a security:
- Backing by an asset
- Staking with rewards
- A buyback mechanism
- A communicated expectation of appreciation
That combination is an investment contract under another name. Structuring it as a "utility token" to dodge regulation doesn't change its nature — it just adds risk, because the regulator will judge it by what it does, not by what it's called.
What this means in practice
Assuming your token is probably a security isn't bad news. It's information that organizes the entire project:
It changes the technical standard. You use a permissioned token — ERC-3643 (T-REX) or ERC-1400 — with on-chain identity, a whitelist of approved wallets, and transfer rules encoded in the contract. It doesn't circulate freely: who can hold and transfer it is controlled.
It changes who you can sell to. Under exemptions such as Reg S or Reg D, the investor universe is limited. KYC and the whitelist are what enforce that restriction technically.
It changes the project sequence. Legal stops being a later formality and becomes the starting point. The structure defines what the token can and cannot do; the code implements it.
There's a line we use to explain it: the law sets the rules, the code enforces them. That's why legal and technical work must advance together from day one, not in sequence.
What this does not mean
It doesn't mean we determine whether your token is a security. Braincoders does not provide legal or regulatory advice — that determination is made by your securities counsel, in your jurisdiction.
What we do is build the technology according to the classification your advisor confirms, and flag it when the design you have in mind and the structure you're assuming don't match. That early warning usually saves months.
Clear on what your token actually represents? Book a discovery call and let's review the model before it becomes a problem.