“Where am I buying this property token from?”
A fair question before buying a share of a building. What sits behind the token, why the register is a name and not an address, and how rent reaches you.
Somebody asked this after being shown a plan that bought property tokens. It is exactly the right question, and it is one most crypto products answer badly — usually by naming a contract address, which tells you nothing about whether there is a building.
What you are actually buying
A share in a register that is a claim on a real building, with exactly one contract behind
it and a registrar behind that. The shares are issued by
0xequity, and in this build there is precisely one register
curated: WXRWA1.
You can go and look at it. 0xequity’s listings page is the register itself, from the issuer’s side rather than ours — and at the time of writing it lists exactly one tokenized property, which is the same one this build curates. Their own documentation on what a tokenized share legally is lives at docs.0xequity.com.
This matters more here than elsewhere in the system. A lending market is curated because it decides the price at which you are liquidated. A property is curated for a different reason: because it is a claim on a real building. They were once the same kind of thing internally, and the result was the planner cheerfully offering lending markets for a field that wanted a property token. Splitting them fixed that.
- Issuer
- 0xequity
- Network
- Base, and only Base — along with all four rent operations
- Curated symbols in this build
- One: WXRWA1
- Settlement currency
- USDC on Base, which is what the venue prices in
- Price source
- The venue's own oracle — not a trading pool
The price does not come from a market
This is the part that behaves unlike everything else in the catalogue.
A swap gets its price from a pool, and you protect yourself with slippage settings. A property buy gets its price from the venue’s own oracle. There is no order book and no pool depth to move.
So the buy is written the other way round from a trade:
- The amount is a count of whole shares
Not an amount of money. You are asking for 99 shares, not for $999 worth.
- What the plan bounds is the currency side
max_spendis the most USDC that buy may part with. At $10.10 a share, 99 shares is 999.90 USDC — so the bound is written as999900000, because USDC has six decimals.
Selling works the same way in reverse. min_receive is the least USDC the sale must bring
in — and because the price comes from an oracle rather than a market, that number is the
only thing standing between what you signed and whatever the oracle says at the moment it
runs. Zero is refused at signing, for that reason.
You have to be enrolled
A property share is a claim on a real asset, so it is not freely transferable to anyone. Selling requires your account to actually hold the shares, which it does only once enrolled.
How rent reaches you
Four operations, all on Base. Which one you want depends on how the position is held.
- rent.claim_own
- Claim against a lock you hold yourself, named by its NFT id.
- rent.claim_position
- Claim an amount against a position.
- rent.harvest_delegated
- Collect rent on an arrangement where you are the delegatee.
- rent.redeem
- Turn claimed rent into currency.
There is one detail here that explains a design decision elsewhere in the system.
Collecting rent takes whatever has built up, and nobody knows that figure when the plan is written.
That is why a step’s amount can be “all of whatever is there” rather than a number. Rent is the case that forced it. A monthly rent claim cannot name an amount in March for a figure that will not exist until June.
What a full loop looks like
The request people actually write is some version of “buy the property, then every month split the rent between paying down the debt and buying more.”
- 01pull-usdcbasedeposit.pull$1,000 USDC from wallet1 call
- 02buy-sharesbaseproperty.buy99 shares · max 999.90 USDC2 calls
- 03claim-rentbaserent.claim_ownall of whatever has built up1 call
- 04redeembaserent.redeem← linked step's output2 calls
- 05repaybaselend.repayan exact amount · Aave v32 calls
Note the last step. Repayment is an exact amount, deliberately: interest accrues every block, so “all” is a number nobody signed. If the rent underpays in a given month, the remainder simply stays outstanding and the next run repays more. Nothing breaks.
Two limits worth knowing before you plan
Property works like everything else, so a plan can buy on one network and manage it on another.
Property and all four rent operations are Base only. And the only crossing in the catalogue carries USDC and nothing else, so the shares themselves never leave Base.
“Can I do this?” is nearly always really “can I do this on that network.”
The honest part
One curated register, on one network, priced by one oracle. That is a narrow offering, and the narrowness is the current state of the build rather than a design goal.
What is not going to change is the shape: a property is a curated name with a registrar behind it, the plan never names an address, and anything produced goes to your account because the destination is a role rather than a field somebody can fill in.
Check it yourself, rather than trusting this page
Everything above has a primary source, and this post will go stale before any of them do. The operation catalogue in particular is generated from the running system rather than written by hand, so it is the thing to believe in six months’ time.
- 0xequity.com
- Who issues the shares, and who the registrar answers to
- app.0xequity.com/listings
- The register from their side — the properties themselves
- docs.0xequity.com
- What a tokenized share is, legally, in their words
- docs.defiloops.com/adapters
- Why the operation list is closed, and what a step can carry
- docs.defiloops.com/adapters/catalogue
- Every operation this build can execute, dumped from the source
Direct links: 0xequity · the listings · their docs · tokenized equity, explained · what a plan can do · the full catalogue