Real estate

Read this page if you are a real estate sponsor, property manager, asset manager, or integration team evaluating property fractionalization on DALP.

DALP turns a property into a capped real-asset token. The platform records property identifiers and classification, along with location and physical details, as token claims. It controls issuance through the creation flow you select and applies the same identity and compliance controls used across other tokenized assets.

Business challenge

A sponsor owns a $25 million office building and wants smaller investors to hold regulated fractional interests without losing control over eligibility, supply, transfer restrictions, and property records.

Traditional approach

How DALP models tokenized property

Real-estate assets are part of the real-assets instrument category. This page describes the dedicated real-estate token workflow: it defines capped property fractions, stores pricing inputs, and issues optional claims for the property identifier, classification, location, coordinates, area, building year, and unit count.

Fractional supply

The maximumFractions value defines the total fractional supply for the property. In the dedicated real-estate token workflow, DALP passes that value as the premint amount and mints the full supply to the configured premintRecipient during creation. Operators should treat the resulting supply cap as fixed unless governance intentionally raises the cap later. This recipient rule applies to the dedicated real-estate workflow, not every real-assets template.

If a sponsor uses a configurable template instead, validate that template's issuance and cap controls separately before launch. For the broader distinction between asset classes, base asset types, and templates, see the asset model.

For example, a sponsor can model a $25 million property as 250,000 fractions at $100 per fraction. The token supply represents the ownership ledger. The legal rights, investor disclosures, tax treatment, and property vehicle remain part of the sponsor's offering structure and legal documentation.

Property metadata

The dedicated real-estate workflow can attach the following real-estate-specific claims during asset creation. The asset workspace then uses the claims for filtering, detail views, and review.

The Real Estate Number (or another property identifier) is stored as the unique asset identifier claim. Property type and property use are stored as the asset classification claim. City, district code, and area identifier are stored as the asset location claim for filtering and review. Latitude and longitude are stored for map and detail views. Property area, building year, and number of units are stored as physical detail claims for the asset details page. Price currency and base price per fraction are used as pricing inputs. A base-price claim is issued only when the selected compliance configuration requires it.

Coordinates are stored with fixed precision. The application displays them as human-readable latitude and longitude values. Omitted physical details are shown as not provided in the asset details view.

Registry and legal-title boundary

DALP records the token, supply cap, property claims, and transfer controls. The platform can also connect to external registry systems, legal workflows, valuation sources, and document repositories through implementation-specific integrations.

Those integrations do not make DALP the land registry. You must decide how the token maps to the legal property vehicle, which external register is authoritative for title, how registry changes are reconciled, and which off-platform approvals are required before token issuance or transfer. DALP can store property identifiers and display real-estate claims, but legal title, mortgage checks, registry synchronization, and property-record updates remain external responsibilities unless the deployment connects those systems explicitly.

Investor eligibility and transfers

Real-estate token transfers use DALP identity and compliance controls. Sponsors can require investors to pass the relevant verification checks before they hold or receive fractions. Transfer rules, lockups, maximum ownership thresholds, and jurisdiction-specific restrictions belong in the selected compliance modules and the offering's legal configuration.

DALP does not make every investor eligible by default. A transfer proceeds only when the token configuration, the investor's identity state, and the compliance setup all permit it.

Valuation and reporting boundaries

DALP stores the asset base price per fraction and property metadata so you and your investors can review the tokenized property in the asset workspace. External property-management systems, appraisal processes, rent rolls, expense ledgers, and investor distribution calculations require integration with your operational systems or custom workflows.

Do not treat the real-estate token template as a property-management platform. It provides a governed token record with capped supply controls and a compliance foundation for regulated fractional ownership.

Operating model

The diagram separates DALP's shipped tokenization surface from external property operations. DALP holds the token, claims, supply cap, issuance controls, identity checks, and transfer controls. You remain responsible for property operations and legal structuring. Rent collection, expense records, and investor reporting stay outside DALP unless those workflows are integrated separately. Appraisals follow the same boundary.

Implementation checklist

1. Structure the property ownership vehicle and confirm the legal rights each fraction represents.
2. Define token economics: total fractions, valuation currency, base price, issuance recipient or minting operator, and any ownership limits.
3. Capture property metadata: identifier, property type, property use, city, district code, area identifier, coordinates, area, building year, and unit count where available.
4. Select compliance modules for investor eligibility, transfer restrictions, lockups, jurisdiction rules, and maximum ownership controls.
5. Configure identity and KYC providers for the required investor verification status.
6. Deploy the real-estate token and verify that the capped supply is preminted to the intended recipient. If you use a configurable template instead, verify its minting and cap controls separately.
7. Review the asset workspace to confirm that the property claims and pricing inputs display correctly.
8. Connect external workflows for property documents, appraisals, rent rolls, expense records, investor reporting, governance, or distributions when the offering requires them.

Compliance considerations

Real-estate fractionalization often involves securities law, property rules, tax obligations, and cross-border transfer restrictions. DALP provides identity and compliance controls. The platform does not replace legal review of the offering structure.

For the broader control architecture, see Compliance & Security.

Limitations and integration points

Property operations come from external systems unless you integrate them into a custom workflow. Rent collection, expense records, reserve accounts, appraisal updates, and property-management data all live outside the token layer and require a separate integration or operational process to make them visible alongside the token record.

DALP can support token-based governance patterns, but property-specific proposal templates, capital-improvement votes, and repair approvals require a configured governance experience beyond the token layer.

Sponsors should connect the authoritative source for appraisals, insurance, operating agreements, and offering documents. DALP real-estate claims do not replace a data room.

Multi-jurisdiction securities and tax rules require legal review before launch.

Next steps

• Review SMART Protocol integration (ERC-3643) to understand embedded transfer compliance.
• Review the system-precious-metal template to compare real-estate preminting with a real-assets template where supply is minted after deployment.
• Explore Developer documentation for integration patterns and API customization.