Разработка системы фракционального владения активами
Задача: есть актив стоимостью $5M — коммерческая недвижимость, произведение искусства, портфель private equity. Один владелец купить не может или не хочет. Нужно разбить право собственности на части и продать их сотням инвесторов. При этом каждый инвестор должен иметь верифицируемые права, получать свою долю дохода, и иметь возможность продать свою долю на вторичном рынке. Это и есть фракциональное владение — и технически это несравнимо сложнее, чем просто "выпустить токены".
Правовая структура: токен без юридического обеспечения — ничто
Первое, что нужно сделать до написания строчки кода — определить правовую оболочку. Токен сам по себе не является правом собственности на недвижимость или другой актив. Нужна юридическая связь между on-chain токеном и off-chain активом.
Три распространённые структуры:
SPV (Special Purpose Vehicle) — юридическое лицо владеет активом, инвесторы владеют токенами, представляющими долю в SPV. Подходит для недвижимости в большинстве юрисдикций. SPV может быть LLC, Ltd, LP. Токены — security tokens, требуют лицензирования.
Trust structure — актив в трасте, beneficiary rights токенизированы. Популярно для арт-рынка и предметов коллекционирования. Trustee управляет активом, бенефициары получают доходы.
DAO LLC (Вайоминг, Маршалловы острова) — DAO имеет юридический статус LLC. Governance токены = членские права. Инновационно, но судебная практика пока ограничена.
Без правовой структуры инвесторы покупают токен, который представляет обещание, а не юридически обязывающее право. Это либо fraud, либо worthless instrument при конфликте.
Архитектура контрактов
Реестр активов
contract AssetRegistry {
enum AssetType { RealEstate, Art, PrivateEquity, Commodity, Other }
enum AssetStatus { Pending, Active, Paused, Liquidating, Closed }
struct Asset {
bytes32 assetId;
AssetType assetType;
AssetStatus status;
string legalEntityId; // ID юридического лица (SPV/Trust)
string documentationURI; // IPFS CID юридических документов
bytes32 documentationHash; // SHA-256 хэш для верификации
uint256 totalValuation; // текущая оценка в USD (6 decimals)
uint256 totalShares; // общее количество долей
address fractionalToken; // ERC-20 токен доли
address distributionContract; // контракт для выплат дохода
uint256 createdAt;
uint256 lastValuationAt;
}
mapping(bytes32 => Asset) public assets;
// Только верифицированные asset managers могут регистрировать
function registerAsset(
bytes32 assetId,
AssetType assetType,
string calldata legalEntityId,
string calldata documentationURI,
bytes32 documentationHash,
uint256 totalValuation,
uint256 totalShares
) external onlyAssetManager returns (address fractionalToken) {
require(assets[assetId].createdAt == 0, "Asset already exists");
// Деплоим фракциональный токен
fractionalToken = _deployFractionalToken(assetId, totalShares);
// Деплоим контракт дистрибуции
address distributionContract = _deployDistribution(assetId, fractionalToken);
assets[assetId] = Asset({
assetId: assetId,
assetType: assetType,
status: AssetStatus.Pending,
legalEntityId: legalEntityId,
documentationURI: documentationURI,
documentationHash: documentationHash,
totalValuation: totalValuation,
totalShares: totalShares,
fractionalToken: fractionalToken,
distributionContract: distributionContract,
createdAt: block.timestamp,
lastValuationAt: block.timestamp
});
emit AssetRegistered(assetId, fractionalToken, msg.sender);
return fractionalToken;
}
}
Фракциональный токен: ERC-20 с transfer restrictions
Это не обычный ERC-20. Security tokens требуют transfer restrictions — нельзя продавать неверифицированным адресам. Стандарт ERC-1400 (Security Token Standard) или более простой ERC-20 с whitelist.
contract FractionalToken is ERC20, ERC20Permit {
ITransferValidator public transferValidator;
bytes32 public immutable assetId;
// Максимум 1800 держателей (лимит Reg D Rule 504 в US)
uint256 public constant MAX_HOLDERS = 1800;
uint256 public holderCount;
mapping(address => bool) private _isHolder;
modifier onlyCompliantTransfer(address from, address to, uint256 amount) {
require(
transferValidator.canTransfer(from, to, assetId, amount),
"Transfer not compliant"
);
_;
}
function transfer(address to, uint256 amount)
public
override
onlyCompliantTransfer(msg.sender, to, amount)
returns (bool)
{
_updateHolderCount(msg.sender, to, amount);
return super.transfer(to, amount);
}
function _updateHolderCount(address from, address to, uint256 amount) internal {
bool toIsNewHolder = !_isHolder[to] && amount > 0;
bool fromBecomesEmpty = balanceOf(from) == amount;
if (toIsNewHolder) {
require(holderCount < MAX_HOLDERS, "Max holders reached");
_isHolder[to] = true;
holderCount++;
}
if (fromBecomesEmpty && from != address(0)) {
_isHolder[from] = false;
holderCount--;
}
}
}
TransferValidator проверяет:
- Оба адреса прошли KYC и имеют статус accredited investor (для US Reg D)
- Ни один не в OFAC SDN list
- Не нарушаются lock-up периоды (обычно 12 месяцев для Reg D)
- Количество держателей не превышает лимит
Дистрибуция дохода: ERC-4626 vault pattern
Актив генерирует доход: рента от недвижимости, дивиденды от equity. Нужно распределять его пропорционально долям держателей без O(N) итерации.
Решение — dividend-per-share tracker (алгоритм из dividends-bearing stocks):
contract DistributionVault {
IERC20 public immutable fractionalToken;
IERC20 public immutable distributionToken; // USDC
uint256 public dividendPerShare; // накопленный дивиденд на долю (scaled by 1e18)
mapping(address => uint256) public lastDividendPerShare;
mapping(address => uint256) public pendingDividends;
// Вызывается когда поступает новый доход (рента, дивиденды)
function distributeIncome(uint256 amount) external onlyAssetManager {
distributionToken.transferFrom(msg.sender, address(this), amount);
uint256 totalShares = fractionalToken.totalSupply();
require(totalShares > 0, "No shares");
// Увеличиваем dividendPerShare пропорционально
dividendPerShare += (amount * 1e18) / totalShares;
emit IncomeDistributed(amount, dividendPerShare);
}
// Накапливаем pending дивиденды при каждом движении токена
function _updateDividend(address account) internal {
uint256 owed = (
(dividendPerShare - lastDividendPerShare[account])
* fractionalToken.balanceOf(account)
) / 1e18;
pendingDividends[account] += owed;
lastDividendPerShare[account] = dividendPerShare;
}
// Держатель забирает накопленные дивиденды
function claimDividends() external {
_updateDividend(msg.sender);
uint256 amount = pendingDividends[msg.sender];
require(amount > 0, "Nothing to claim");
pendingDividends[msg.sender] = 0;
distributionToken.transfer(msg.sender, amount);
emit DividendsClaimed(msg.sender, amount);
}
}
Алгоритм O(1) per claim — не важно сколько держателей. Hook в fractional token: при каждом transfer вызывается _updateDividend для обоих участников. Это паттерн из Synthetix staking rewards, battle-tested на миллиардах TVL.
Вторичный рынок
Интеграция с DEX и orderbook
Для торговли фракциональными токенами нужен комплаентный DEX — обычный Uniswap не проверяет KYC покупателей.
Варианты:
Разрешённый AMM — форк Uniswap v3 с whitelist проверкой в swap хуке:
// Uniswap v4 Hook для transfer compliance
contract ComplianceHook is BaseHook {
ITransferValidator public validator;
function beforeSwap(
address sender,
PoolKey calldata key,
IPoolManager.SwapParams calldata params,
bytes calldata
) external override returns (bytes4) {
// Определяем: sender покупает или продаёт токен
address buyer = params.zeroForOne ? sender : sender; // упрощение
bytes32 assetId = poolToAsset[PoolId.toId(key)];
require(
validator.isCompliantBuyer(buyer, assetId),
"Buyer not compliant"
);
return BaseHook.beforeSwap.selector;
}
}
OTC orderbook — офчейн matching с on-chain settlement. Эффективнее для неликвидных assets, где AMM дал бы высокий slippage.
tZERO, RealT, Securitize Markets — готовые регулируемые торговые площадки для security tokens. Интегрируем свои токены туда вместо создания собственного DEX.
Оценка активов (valuation updates)
Для real estate и других non-liquid assets нужны периодические переоценки. Это влияет на:
- Отображение стоимости портфеля инвестора
- Расчёт collateral ratio если токены используются в DeFi lending
- Регуляторную отчётность
contract ValuationOracle {
struct Valuation {
uint256 value; // USD, 6 decimals
uint256 timestamp;
address appraiser; // лицензированный оценщик
bytes32 reportHash; // IPFS hash отчёта об оценке
}
mapping(bytes32 => Valuation[]) public valuationHistory;
mapping(address => bool) public certifiedAppraisers;
// Минимум 2 из 3 сертифицированных оценщиков должны согласиться
// для обновления оценки — защита от manipulation
function submitValuation(
bytes32 assetId,
uint256 value,
bytes32 reportHash
) external onlyCertifiedAppraiser {
pendingValuations[assetId].push(Valuation({
value: value,
timestamp: block.timestamp,
appraiser: msg.sender,
reportHash: reportHash
}));
if (_hasConsensus(assetId)) {
_finalizeValuation(assetId);
}
}
}
Технический стек
| Компонент | Технология |
|---|---|
| Smart contracts | Solidity 0.8.x + Foundry |
| Transfer validation | ERC-1400 / кастомный validator |
| KYC integration | Sumsub / Persona + on-chain registry |
| Indexer | Goldsky / The Graph |
| Legal document storage | IPFS + Filecoin для persistence |
| Frontend | React + wagmi + RainbowKit |
| Admin dashboard | Next.js + Prisma + PostgreSQL |
Регуляторные требования по юрисдикциям
| Юрисдикция | Режим | Ограничения |
|---|---|---|
| USA | Reg D / Reg A+ | Accredited investors (Reg D) или полная регистрация (Reg A+) |
| EU | MiCA + MiFID II | Security tokens под MiFID II, требует лицензированного брокера |
| UK | FCA regulated | Restricted investment для retail |
| Сингапур | MAS CMS license | Один из наиболее прогрессивных режимов |
| Каймановы о-ва | Лёгкий режим | Популярно для SPV, но US/EU инвесторы остаются под своими законами |
Сроки
| Фаза | Содержание | Срок |
|---|---|---|
| Legal structuring | SPV архитектура, юрисдикция, compliance framework | 4–6 нед |
| Smart contracts | Registry, Token, Distribution, Validator | 6–8 нед |
| KYC/AML pipeline | Integration + on-chain registry | 3–4 нед |
| Investor portal | Portfolio, claims, secondary market | 6–8 нед |
| Admin & asset manager | Onboarding, valuation, income distribution | 4–5 нед |
| Security audit | 4–6 нед | |
| Regulatory review + launch | 4–6 нед |
Реалистичный срок до первого токенизированного актива на платформе: 9–14 месяцев. Большая часть задержек — не разработка, а legal due diligence, регуляторное согласование и работа с custodians.







