Разработка системы фракционального владения активами

Разработка системы фракционального владения активами

Задача: есть актив стоимостью $5M — коммерческая недвижимость, произведение искусства, портфель private equity. Один владелец купить не может или не хочет. Нужно разбить право собственности на части и продать их сотням инвесторов. Каждый инвестор должен иметь верифицируемые права, получать свою долю дохода и иметь возможность продать долю на вторичном рынке. Мы — команда блокчейн-разработчиков с 5+ лет опыта в DeFi и security tokens. На счету более 10 реализованных проектов токенизации активов. Разберём, как построить архитектуру, которая выдержит юридическую и техническую нагрузку. Мы предлагаем полный цикл под ключ: от юридической структуры до запуска вторичного рынка.

Почему без юридической структуры токен — ничто?

Первое, что нужно сделать до написания строчки кода — определить правовую оболочку. Токен сам по себе не является правом собственности на актив. Нужна юридическая связь между 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 токены = членские права. Инновационно, но судебная практика пока ограничена.

Без правовой структуры инвесторы покупают токен, который представляет обещание, а не юридически обязывающее право. Согласно Reg D Rule 504, максимальное количество акционеров — 1800.

Как устроен смарт-контракт фракционального токена?

Реестр активов

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 или более простой 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, не в OFAC SDN list, соблюдены lock-up периоды (обычно 12 месяцев). ERC-1400 defines security token standard with transfer restrictions. Больше о стандарте можно узнать в спецификации на GitHub.

Как автоматически распределять доход?

Актив генерирует доход: рента от недвижимости, дивиденды от equity. Нужно распределять его пропорционально долям держателей без O(N) итерации. Решение — dividend-per-share tracker (алгоритм из staking rewards, battle-tested на миллиардах TVL).

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 для обоих участников.

Вторичный рынок

Интеграция с DEX и orderbook

Для торговли фракциональными токенами нужен комплаентный DEX — обычный Uniswap не проверяет KYC покупателей. Варианты:

• Разрешённый AMM — форк Uniswap v3 с whitelist проверкой в swap хуке.
• 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, и регуляторную отчётность. Мы используем мультиподпись: минимум 2 из 3 сертифицированных оценщиков должны согласиться для обновления оценки.

Технический стек

Регуляторные требования по юрисдикциям

Что входит в работу

• Юридическая документация: структура SPV/Trust/DAO LLC, договоры с asset manager, prospectus.
• Смарт-контракты: реестр активов, фракциональный токен (ERC-1400/ERC-20), vault распределения, transfer validator.
• KYC/AML pipeline: интеграция сервиса верификации, on-chain реестр, compliance проверки.
• Инвесторский портал: дашборд для просмотра портфеля, claims доходов, торговли на вторичном рынке.
• Admin dashboard: управление активами, оценка, дистрибуция доходов.
• Аудит безопасности: 4–6 недель, несколько аудиторских компаний.
• Поддержка после запуска: мониторинг, обновления, доработки.

Сроки

Реалистичный срок до первого токенизированного актива на платформе: 9–14 месяцев. Большая часть задержек — не разработка, а legal due diligence, регуляторное согласование и работа с custodians.

Мы имеем 5+ лет опыта в разработке security tokens и DeFi решений. Наши смарт-контракты управляли активами на суммы свыше $50M. Оценим ваш проект за 2 дня — свяжитесь с нами для предварительной консультации.