Render Network

Render Network — справочная карточка криптопроекта: что делает продукт и насколько проверяемы ключевые утверждения проекта; также — соответствие тезису Decentralized AI (DecAI Fit).

Render Network — AI/Compute проект (децентрализованный рынок GPU‑вычислений), токен (символ: RENDER).

Дисклеймер

Важно: эта страница — справочный разбор проекта. В рамках DecAIHub отдельно фиксируется проверка сведений из открытых источников по AI‑тезису (что реально AI/onchain/зачем токен и на каких источниках это основано).
Это не является финансовой рекомендацией и не является советом покупать/продавать/держать актив. Мы не оцениваем цену, доходность, тайминг входа/выхода.
Выводы основаны на публично доступных материалах, обнаруженных на дату проверки. Отсутствие подтверждения не означает отсутствие технологии.

TL;DR (для тех, кто не про ИИ)

Что это: децентрализованный marketplace GPU‑рендеринга/вычислений: requestors покупают GPU‑работу у node operators.
Для кого: создатели 3D/контента, команды и приложения, которым нужен GPU‑compute (в т.ч. для AI‑задач), а также операторы GPU‑нод.
Зачем ончейн/токен: токен используется для оплаты работ и распределения/учёта стимулов (burn/mint и emissions по правилам протокола).
Что можно реально “потрогать” (Tier‑1): пошаговый гайд работы с Creator portal (подготовка сцены → job → review/approve → download).

Как это работает (очень кратко)

Requestor создаёт задачу: указывает параметры рендера/compute‑работы и бюджет.
Сеть подбирает исполнителей: GPU providers выполняют работу offchain, результат возвращается requestor’у.
Оплата и учёт — по протоколу: работы оплачиваются через токеномеханики (BME: burn токенов → кредиты; emissions → вознаграждение нодам).
Где блокчейн: onchain фиксируется токеномеханика и расчёты/лог транзакций для BME и governance‑процессов.
Роль токена: RENDER нужен, чтобы оплачивать compute‑работу и стимулировать/вознаграждать поставщиков GPU.

Быстрые ссылки: AI‑соответствие

Паспорт проекта

Поле	Значение
Название проекта	Render Network
Также известен как (aliases)	RNDR (legacy), Render
Лого (logo)	../assets/render_logo.svg
Символ токена (ticker)	RENDER
Категория	AI/Compute \| Infra
Основная сеть (chain)	Solana
Тип	Appchain
Статус сети	mainnet
Консенсус (consensus)	—
Дата запуска (launch_date)	2020-04-27
Статус проекта (status)	active
Токен (стандарт)	SPL
Контракт токена	—
Модель токена (token_type)	utility (fee-mechanism)
Макс. предложение	536,870,912 (исторический лимит RNDR; миграция 1:1 в RENDER)
Эмиссия	emissions schedule (declining; epoch-based) + burn (BME)
Токеномика (tokenomics, кратко)	BME: оплата работ через burn RENDER → Render Credits; emissions распределяются участникам сети по расписанию/эпохам.
Управление	governance через RNP + голосования
Админы/ключи	—
Аудит	yes
Bug bounty	—
Команда (team)	Render Network Foundation
Финансирование (investors/funding)	—
AI‑компонент (ai_component)	GPU compute for rendering + AI tasks
Use‑case (use_case)	decentralized GPU compute
DecAI Fit — AI‑соответствие (AI thesis fit)	5/6 — высокое соответствие тезису Decentralized AI
Итог по компонентам DecAI Fit	ai_score 2 / onchain_score 2 / token_score 3 / evidence_score 3
Last verified	2026-02-03

Ссылки (links_*)

Тип	Ссылка
Website	https://rendernetwork.com/
Docs	https://know.rendernetwork.com/
Creator portal	https://render.x.io/
GitHub	https://github.com/rendernetwork/RNPs
Releases / Changelog	https://github.com/nordskill/render-network-manager-app/releases
Whitepaper	https://renderfoundation.com/whitepaper
Roadmap	https://renderfoundation.com/roadmap
Security advisories	—
Explorer	https://etherscan.io/token/0x6de037ef9ad2725eb40118bb1702ebb27e4aeb24
X	https://twitter.com/rendernetwork
Discord	https://discord.com/invite/rendernetwork
Telegram	https://t.me/rendernetwork
Medium	https://rendernetwork.medium.com/
Audit report(s)	https://blog.openzeppelin.com/render-token-audit-2a078ba6d759
Bug bounty	—
CoinGecko (профиль, справочно)	https://www.coingecko.com/en/coins/render
CoinMarketCap (профиль, справочно)	https://coinmarketcap.com/currencies/render/

Общее описание проекта

Render Network — распределённая сеть/маркетплейс GPU‑вычислений, где requestors покупают выполнение рендеринга (и связанных GPU‑задач) у операторов GPU. По Tier‑1 knowledge base, сеть выросла из OTOY и была выделена в Render Network Foundation; протокол и экономическая модель описываются через whitepaper и систему предложений RNP. В модели BME оплата работы привязана к сжиганию токена RENDER и выпуску рабочих кредитов, а участникам сети распределяются emissions.

Фичи/модули

Marketplace GPU‑compute: match между requestors и GPU providers.
BME (Burn Mint Equilibrium): модель оплаты работ и распределения emissions.
Render Credits: рабочие кредиты, используемые для подачи заданий.
RNP‑governance: изменения протокола проходят через предложения и голосования.

Типичные сценарии

Сценарий 1: creator/requestor покупает GPU‑работу → получает результат рендера/compute.
Сценарий 2: оператор GPU‑ноды подключается и выполняет задачи → получает вознаграждение по emissions/правилам протокола.
Сценарий 3: держатели токена участвуют в RNP‑голосованиях → влияют на развитие протокола.
Сценарий 4 (Tier‑1 “demo surface”): creator запускает job через Creator portal (подготовка сцены → параметры → review/approve → download результата).

Как начать (кошелёк/сеть)

Что нужно: кошелёк/аккаунт и доступ к инструментам Render Network; для оплаты задач — RENDER/кредиты.
Сеть/chain: Solana (BME и RENDER SPL token по Tier‑1 docs).
Комиссии: оплата работ реализована через burn токена и выпуск кредитов (BME).

Архитектура/техника (без AI)

Компоненты: клиенты/requestors, GPU providers (node operators), протокол учёта/оплаты (BME), governance процесс (RNP).
Роли участников: requestors, providers, governance‑участники.
Где выполняется логика: выполнение GPU‑работы — offchain; учёт/оплата/эмиссии/голосования — onchain/протокольно.
Зависимости: — (конкретные интеграции и клиентские приложения зависят от сценария).

Токен/экономика (развернуто, без прогнозов)

Утилити токена: compute‑работа оплачивается через burn RENDER в обмен на Render Credits; providers получают emissions.
Кто платит комиссии: requestors/создатели задач.
Куда идут комиссии: по BME токены сжигаются при оплате работ; вознаграждение providers происходит через emissions (по расписанию/эпохам).
Эмиссия/сжигание: описано как “Token Burning and Emissions” в Tier‑1 BME‑описании; schedule фиксируется/обновляется через RNP.
Механизмы безопасности/стимулов: emissions стимулируют поставщиков GPU отвечать на спрос сети.

Управление

Кто принимает решения: сообщество через RNP‑процесс и голосования.
Как меняются параметры протокола: предложения RNP → обсуждение → голосования (в т.ч. с quorum) → внедрение.

Безопасность и инциденты

Аудиты: есть публичный отчёт аудита токена (см. links_*).
Bug bounty: —.
Инциденты: —.
Модель системы: качество и достоверность исполнения offchain‑работ, а также корректность учёта, токеномеханики и governance‑процессов зависят от реализации соответствующих механизмов.

Статус проекта и таймлайн

Текущий статус: mainnet.
Ключевые релизы/вехи: запуск сети (2020-04-27) и запуск RENDER (2023-11-02) упомянуты в Tier‑1 knowledge base.
Roadmap: публично задаётся через RNP и страницу roadmap (см. links_*).

Экосистема/интеграции

Интеграции: инструменты/клиенты для создателей и операторов нод (см. docs).
Партнёры: —.
Где реально используется: в сценариях рендера/compute, в т.ч. через AI‑генеративные инструменты (см. docs).

Ai составляющая проекта

Что здесь реально ИИ? Render позиционирует сеть как децентрализованный GPU‑compute для графики и AI‑задач; в Tier‑1 docs упоминаются “rendering and AI jobs”.
Что реально onchain? onchain реализованы BME‑токеномеханика (burn → credits, emissions) и governance‑процесс (RNP/voting).
Зачем нужен токен? RENDER нужен для оплаты compute‑работ (через burn) и для стимулов поставщикам GPU (emissions), а также для участия в governance.
Красные флаги (по найденной информации): offchain‑исполнение работ: требуются прозрачные критерии качества и анти‑фрод‑механизмы; путаница между “AI‑compute” и “встроенным AI‑модулем протокола”. Tier‑1 демо (AI_2=1) показывает workflow запуска job’ов, но не даёт метрик качества AI (AI_3=0).

Итог по компонентам DecAI Fit

DecAI Fit: 5/6 — высокое соответствие тезису Decentralized AI

Компонент	Уровень	Score
AI reality	средне	2
Onchain necessity	средне	2
Token necessity	высоко	3
Evidence	Tier‑1 есть	3

Подробнее

AI reality

AI_0 — намерения про AI (roadmap Tier‑1) (1/0)

AI_0 (decision): 0
Claim (1 строка): Tier‑1 описывает поддержку AI‑задач как часть оплачиваемых работ (не только “план/намерение”).
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium
Why sufficient / why not (1 строка): AI здесь упоминается как выполняемые задачи сети, поэтому это больше чем roadmap‑intent.
Conflict note (если есть): —

AI_1 — что делает ИИ (1/0)

AI_1 (decision): 1
Claim (1 строка): Сеть обеспечивает GPU‑compute для AI‑задач (и рендера) как оплачиваемую услугу.
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium ; https://know.rendernetwork.com/
Why sufficient / why not (1 строка): Tier‑1 описывает “rendering and AI jobs” и позиционирование сети как GPU‑compute.
Conflict note (если есть): —

AI_2 — демо/примеры (1/0)

AI_2 (decision): 1
Claim (1 строка): Tier‑1 knowledge base содержит пошаговый гайд работы с Creator portal (от входа до запуска/проверки job), т.е. воспроизводимый пример использования compute‑сети.
Evidence: Tier‑1 — https://know.rendernetwork.com/getting-started/how-to-get-started
Why sufficient / why not (1 строка): это демо/пример работы сети как compute‑сервиса; метрики “качества AI” (AI_3) отсутствуют, т.к. сеть исполняет разные workloads.
Conflict note (если есть): —

AI_3 — метрики/качество (1/0)

AI_3 (decision): 0
Метрики: —
Контекст (версия/дата/на чём мерили): —
Evidence: Tier‑1 — https://know.rendernetwork.com/
Why sufficient / why not (1 строка): Нет Tier‑1 метрик качества AI‑подсистемы; есть описание сервисной модели.
Conflict note (если есть): —

AI_4 — техописание/архитектура/версии (1/0)

AI_4 (decision): 0
Claim (1 строка): Есть описание токеномеханики и работы сети, но без техархитектуры “AI‑модуля”.
Evidence: Tier‑1 — https://renderfoundation.com/whitepaper
Why sufficient / why not (1 строка): Whitepaper описывает сеть GPU‑compute/рендеринга, а не AI‑модель/версию модели.
Conflict note (если есть): —

Onchain necessity

OC_1 — контракты/адреса/сеть (1/0)

OC_1 (decision): 1
Сеть: Solana (BME / RENDER SPL)
Адреса/идентификаторы: — (в рамках карточки фиксируем сеть и документацию; конкретные адреса зависят от сущности)
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/the-render-spl-token
Why sufficient / why not (1 строка): Tier‑1 прямо говорит, что BME реализован на Solana и токен — RENDER SPL.
Conflict note (если есть): —

OC_2 — onchain не только токен (1/0)

OC_2 (decision): 1
Какая полезная логика onchain: BME‑логика оплаты (burn → credits) и прозрачный onchain лог, используемый для rewards по epoch.
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium ; https://know.rendernetwork.com/basics/the-render-spl-token
Why sufficient / why not (1 строка): Onchain используется как часть расчёта/учёта и протокольной токеномеханики, а не только “переводы токена”.
Conflict note (если есть): —

OC_3 — onchain критичен (1/0)

OC_3 (decision): 0
Тест “замены блокчейна”: строгая необходимость блокчейна (невозможность заменить на централизованный биллинг) по Tier‑1 явно не доказана.
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium
Why sufficient / why not (1 строка): Есть onchain‑механика, но для OC_3 нужен явный тест “без ончейна ломается продукт” в Tier‑1.
Conflict note (если есть): —

Token necessity

TK_0 — токена нет (1/0)

TK_0 (decision): 0
Claim (1 строка): В проекте есть токен RENDER (SPL).
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/the-render-spl-token
Why sufficient / why not (1 строка): Tier‑1 docs описывают RENDER SPL token и его роль.
Conflict note (если есть): —

TK_1..TK_4 (1/0)

TK_1 — платёж за сервис (1/0)

TK_1 (decision): 1
Claim (1 строка): GPU‑работа оплачивается через burn RENDER в обмен на Render Credits (BME).
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/the-render-spl-token ; https://know.rendernetwork.com/basics/burn-mint-equilibrium
Why sufficient / why not (1 строка): Tier‑1 прямо описывает оплату работ через burn и выпуск кредитов.
Conflict note (если есть): —

TK_2 — стимулы/залоги/штрафы (1/0)

TK_2 (decision): 1
Claim (1 строка): Providers получают токены через network emissions как стимул обслуживать спрос сети.
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium ; https://know.rendernetwork.com/basics/the-render-spl-token
Why sufficient / why not (1 строка): Tier‑1 описывает emissions/incentives и распределение вознаграждений.
Conflict note (если есть): —

TK_3 — управление (1/0)

TK_3 (decision): 1
Claim (1 строка): Governance‑голосования по RNP используют участие держателей RNDR/RENDER с quorum по total supply.
Evidence: Tier‑1 — https://know.rendernetwork.com/about-render-network-governance/render-network-proposal-rnp-system
Why sufficient / why not (1 строка): Tier‑1 описывает голосования и quorum по supply RNDR+RENDER.
Conflict note (если есть): —

TK_4 — токен заменим (1/0)

TK_4 (decision): 0
Claim (1 строка): Токен глубоко встроен в BME‑оплату и emissions‑стимулы, поэтому “заменимость” по Tier‑1 не подтверждена.
Evidence: Tier‑1 — https://know.rendernetwork.com/basics/burn-mint-equilibrium
Why sufficient / why not (1 строка): Для TK_4=1 нужен явный Tier‑1 тезис “можно заменить без потери смысла”.
Conflict note (если есть): —

Evidence (таблица)

Tier	Источник	Что доказывает
Tier‑1	https://know.rendernetwork.com/	Что такое Render Network; роль участников; упоминание AI compute в позиционировании.
Tier‑1	https://know.rendernetwork.com/getting-started/how-to-get-started	Пошаговый гайд использования Creator portal (воспроизводимый пример работы сети).
Tier‑1	https://renderfoundation.com/whitepaper	Назначение сети GPU‑compute/рендеринга и общая модель.
Tier‑1	https://know.rendernetwork.com/basics/burn-mint-equilibrium	BME: оплата rendering/AI jobs onchain, burn+emissions, epoch‑аллокирование.
Tier‑1	https://know.rendernetwork.com/basics/the-render-spl-token	RENDER SPL token, BME на Solana, burn → credits, emissions.
Tier‑1	https://know.rendernetwork.com/about-render-network-governance/render-network-proposal-rnp-system	Governance: RNP‑процесс и голосования (quorum по RNDR+RENDER supply).
Tier‑1	https://renderfoundation.com/roadmap	Roadmap: задаётся через RNP и публичный список RNPs.
Tier‑1	https://renderfoundation.com/upgrade	Факт миграции на Solana и RENDER SPL (Nov 2, 2023), апгрейд 1:1 RNDR→RENDER и стимулы (RNP‑006).
Tier‑1	https://know.rendernetwork.com/basics/token-metrics-summary	Исторический лимит minted supply RNDR (536,870,912) и контекст миграции (для справки).
Tier‑2	https://blog.openzeppelin.com/render-token-audit-2a078ba6d759	Audit report (контекст: аудит токена; tier зависит от статуса источника).