Zcash — это криптовалютная сеть с доказательством выполнения работы, и ZEC является её нативным активом. Она поддерживает прозрачные операции и защищённые переводы, которые могут скрывать отдельные детали транзакций при использовании совместимых кошельков и пулов адресов.
Используйте эту страницу, чтобы оценить, подходит ли Zcash для платежей или потребностей в конфиденциальности, затем проверьте совместимость получателя, текущую комиссионную политику, политику подтверждения и ограничения защищённой активности.
Эта страница является образовательным справочником по сети и рынку. Она не гарантирует конфиденциальность транзакций, совместимость кошельков, поддержку бирж или инвестиционные результаты.
ZEC/USDT · Binance Spot · UTC
Длинные диапазоны автоматически используют подходящий интервал свечей.
Доступны исторические свечи Binance Spot. Для обновлений текущей свечи требуется JavaScript.
| Время (UTC) | Открытие (USDT) | Максимум (USDT) | Минимум (USDT) | Закрытие (USDT) | Объём (ZEC) |
|---|---|---|---|---|---|
| 25 авг 2026 г., 10:00:00 UTC | 839,73 USDT | 843,90 USDT | 835,81 USDT | 842,24 USDT | 5 860,97 ZEC |
| 25 авг 2026 г., 09:00:00 UTC | 842,23 USDT | 854,97 USDT | 837,28 USDT | 839,61 USDT | 9 525,32 ZEC |
| 25 авг. 2026 г., 08:00:00 UTC | 852,56 USDT | 855,53 USDT | 840,66 USDT | 842,23 USDT | 9 848,26 ZEC |
| 25 авг. 2026 г., 07:00:00 UTC | 851,55 USDT | 866,93 USDT | 846,71 USDT | 852,50 USDT | 13 269,04 ZEC |
| 25 авг. 2026 г., 06:00:00 UTC | 852,28 USDT | 856,73 USDT | 844,65 USDT | 851,55 USDT | 5 203,34 ZEC |
Рыночные данные: Binance Spot ZEC/USDT
Библиотека графиков: TradingView Lightweight Charts
Zcash поддерживает как прозрачные, так и защищённые потоки транзакций.
Протокол с поддержкой защиты не делает каждую транзакцию ZEC приватной.
Zcash полезен только тогда, когда выбранный кошелёк, получатель и путь транзакции поддерживают конфиденциальность и совместимость, которые вам действительно нужны.
Опциональные защищённые переводы, платежи с учётом конфиденциальности или выборочное раскрытие информации актуальны, и все участники используют совместимое программное обеспечение Zcash.
Владение ZEC или использование сети Zcash не скрывает автоматически перевод. Исходный пул, получатель и путь, созданный кошельком, определяют, что защищено.
Кошельки, биржи и платёжные сервисы поддерживают разные типы получателей и пулы. Действительный адрес Zcash может быть непригоден в конкретном сервисном процессе.
Проверьте тип получателя, поддержку кошелька, выбранный путь транзакции, отображаемую комиссию и политику подтверждения сервиса получателя перед авторизацией платежа.
Один ZEC равен 100 000 000 затоши; точность отображения в кошельке не меняет базовую сумму.
Базовая единица измерения, отображаемая кошельком
Наименьшая единица учета ZEC
Затоши обеспечивают целочисленную единицу учета, используемую, когда программное обеспечение представляет суммы и комиссии в ZEC. Сама единица не раскрывает, хранится ли стоимость в прозрачном или защищенном пуле.
0,01 ZEC равен 1 000 000 затоши.
Единица суммы отделена от того, использует ли перевод прозрачный или защищенный пул.
Комиссии за транзакции Zcash оплачиваются в ZEC и выражаются в затоши. Текущие общепринятые рекомендации по комиссиям используют логическую работу, выполняемую транзакцией, а не универсальную фиксированную комиссию для каждого перевода.
Согласно действующему правилу обычной комиссии ZIP 317, кошельки учитывают логические действия, вносимые прозрачными входами и выходами, а также защищёнными тратами и выходами. Предельная комиссия в 5 000 затоши применяется с двумя льготными действиями, что сохраняет минимальную обычную транзакцию на уровне 10 000 затоши, позволяя более сложным конструкциям стоить дороже.
Конструкция защищенной транзакции может включать заполнение для уменьшения утечки информации из-за необычных форм. Это заполнение и межпуловая активность могут повлиять на количество действий, поэтому два платежа с одинаковой суммой в ZEC могут получить разные комиссии, рассчитанные кошельком. Обычная комиссия — это рекомендация политики кошелька, а не утверждение, что консенсус требует, чтобы каждая транзакция использовала одну точную комиссию.
Минимальная транзакция в пределах двух льготных действий имеет обычную комиссию в 10 000 затоши, что равно 0,0001 ZEC. Транзакция с большим количеством логических действий может иметь более высокую рекомендацию.
Используйте комиссию, указанную текущим доверенным кошельком. Не зашивайте старую фиксированную комиссию и не выбирайте вручную необычную комиссию, не понимая ее влияния на конфиденциальность и ретрансляцию.
Транзакция Zcash может сочетать прозрачные входы или выходы с защищенными действиями Sapling или Orchard. Результирующая конфиденциальность зависит от полного пути, выбранного кошельком.
Прозрачная активность раскрывает свои публичные адреса и суммы. Защита перемещает стоимость из прозрачного источника в защищенный пул; дезащита раскрывает прозрачную сторону получателя; а полностью защищенный перевод защищает соответствующие защищенные адреса и поля сумм от обычного публичного просмотра. Межпуловые транзакции могут включать более одного протокола перевода, поэтому кошелек должен объяснять, что защищено, а не рассматривать каждую транзакцию с доказательством как эквивалентную.
Исходные заметки, получатели назначения, обработка сдачи и поддержка кошелька определяют, какие прозрачные или защищенные компоненты создаются.
Доказательство с нулевым разглашением проверяет защищённые компоненты, не раскрывая их защищённые значения, но оно не скрывает прозрачные компоненты или метаданные, собранные вне протокола.
Zcash поддерживает прозрачные, Sapling и Orchard получателей. Единый адрес может кодировать несколько получателей, поэтому отправляющий кошелёк может выбрать наилучший поддерживаемый протокол перевода.
| Тип адреса | Общий префикс | Пул | Типичное использование | Примечание о совместимости |
|---|---|---|---|---|
| Прозрачный получатель | t1 или t3 | Прозрачный | Публичные переводы и широкая интеграция с устаревшими системами | Адреса и переводимые значения являются публичными |
| Получатель Sapling | zs | Защищённый пул Sapling | Защищённые платежи в совместимых кошельках | Прямая поддержка Sapling зависит от кошелька и сервиса |
| Получатель Orchard | Внутри единого адреса | Защищённый пул Orchard | Текущие защищённые платежи через совместимые кошельки | Нет отдельного пользовательского кодирования адреса Orchard |
| Единый адрес | u | Контейнер получателей | Одно кодирование адреса, которое может содержать поддерживаемые типы получателей | Отправляющий кошелёк выбирает совместимого получателя; конфиденциальность не гарантируется |
Единый адрес — это контейнер адресов, а не доказательство того, что конечная транзакция является защищённой. Отправитель декодирует доступных получателей и выбирает того, которого поддерживает; поэтому политика кошелька и сервис получателя остаются частью результата конфиденциальности. Просмотровые ключи — это отдельные чувствительные учётные данные, которые могут раскрывать защищённую активность для бухгалтерского учёта или выборочного раскрытия без предоставления права траты.
Подтвердите, какого получателя будет использовать отправляющий кошелёк, особенно если единый адрес включает более одного варианта.
Кошелёк или биржа могут поддерживать прозрачные депозиты, но не Sapling, Orchard или все формы единого адреса.
Первое подтверждение фиксирует транзакцию в принятом блоке. Дополнительная глубина снижает риск реорганизации в соответствии с политикой кошелька или сервиса, но не меняет конфиденциальность транзакции, уже установленную её путём.
Транзакция видна кошельку или сервису, но ещё не включена в принятый блок.
Транзакция включена в один принятый блок Zcash, при этом риск реорганизации остаётся зависимым от политики.
Каждый последующий принятый блок делает реорганизацию менее вероятной; требуемая глубина варьируется в зависимости от кошелька, продавца и биржи.
Кошелёк может ожидать настроенного подтверждения или условий доверия, прежде чем разрешить трату полученного вывода.
Кошелёк может отображать входящую сумму до того, как он будет считать этот вывод доступным для траты. Различие зависит от включения в блок, глубины подтверждения, того, считает ли кошелёк источник доверенным, и его собственной политики риска. Официальные рекомендации кошелька могут предлагать порог подтверждений, но эта рекомендация является операционной политикой, а не единым правилом консенсуса для каждого продавца, биржи и кошелька.
Интерфейсы должны различать обнаруженный платёж и подтверждённый, одобренный политикой баланс, который можно тратить.
Глубина подтверждения касается риска отмены. Выбор получателя и пути транзакции касается раскрытия информации.
Двухпутевая конструкция сохраняет привычное публичное поведение платежей, обеспечивая более сильную конфиденциальность в цепочке через защищенные протоколы.
Прозрачная активность Zcash ведет себя во многом как обычный платеж UTXO: адреса и переводимые суммы видны в публичной цепочке. Это упрощает базовую проверку, депозиты на биржах и интеграцию для сервисов, построенных на публичных записях транзакций. Это также означает, что такие переводы не получают защиты адресов и сумм, которую обеспечивает полностью защищенный путь.
Защищенные пулы позволяют узлам проверять действительность транзакции, не публикуя защищенные поля отправителя, получателя и суммы тем же способом. Это меняет то, что обычный наблюдатель цепочки может узнать, но не стирает существование транзакции, ее комиссию или все улики, создаваемые временем, контрагентами и окружающим процессом.
Поддержка обеих моделей помогает Zcash взаимодействовать с программным обеспечением, имеющим разные возможности, но переносит важное решение в кошелек. Кошелек должен распознавать получателя, выбирать поддерживаемый протокол перевода и объяснять, когда стоимость переходит между прозрачными и защищенными пулами. Привычный экран отправки недостаточен, если он скрывает, какой путь будет использован.
Полезное применение зависит от намеренной поддержки защищенных переводов, работоспособного пути получателя и операционной политики, которая принимает специфические для Zcash проверки совместимости.
Zcash может подойти, когда обе стороны намеренно поддерживают защищенного получателя, и отправитель может проверить путь перед подписанием.
Обратите внимание на: Подтвердите версию кошелька, тип получателя, комиссию и поддержку получателя; переход к прозрачной активности меняет модель раскрытия информации.
Возможности просмотра могут поддерживать сверку или отчетность без передачи права тратить средства, если рабочий процесс предназначен для этой цели.
Обратите внимание на: Определите, кто получает доступ к просмотру, что он раскрывает и как ключевой материал хранится и отзывается операционно.
Приложение может хорошо использовать Zcash, если оно явно обрабатывает унифицированные адреса, защищенных получателей, комиссии и состояния подтверждения.
Обратите внимание на: Протестируйте каждый поддерживаемый пул и путь миграции, а не предполагайте, что универсальная поддержка криптовалютных кошельков достаточна.
Поддержка защищенных получателей и компонентов унифицированных адресов различается между сервисами, поэтому конфиденциальный путь может быть доступен не везде.
Сравнение: Используйте платежный канал, явно поддерживаемый каждым требуемым контрагентом, и сравните его компромиссы по раскрытию информации.
Zcash допускает прозрачную активность и переходы между смешанными пулами. Протокол не может превратить неподдерживаемого получателя или прозрачное назначение в полностью защищенный платеж.
Сравнение: Оцените конструкции с конфиденциальностью по умолчанию, если необязательный выбор пути неприемлем, изучив их собственные ограничения совместимости.
Эта страница описывает Zcash как платежную сеть и сеть конфиденциальности, а не как замену общей среде приложений в стиле EVM.
Сравнение: Оценивайте платформу смарт-контрактов, если программируемое состояние приложения является центральным требованием.
Защищенные протоколы защищают конкретные поля в цепочке; они не являются обещанием полной операционной анонимности.
В защищенном переводе протокол предназначен для защиты адресов и сумм от обычного публичного просмотра, при этом позволяя сети отклонять недействительные траты. Прозрачные входы и выходы остаются публичными, и перемещение стоимости в защищенный пул или из него может раскрыть прозрачную сторону этого пути. Конфиденциальность, следовательно, зависит от всей транзакции, а не просто от того, появляется ли в ней один защищенный получатель.
Поведение кошелька имеет значение, потому что кошелек выбирает заметки, получателей, обработку сдачи и протоколы перевода. Унифицированный адрес может содержать более одного типа получателя, и отправляющий кошелек выбирает тот, который он поддерживает. Это улучшает совместимость, но не гарантирует, что окончательный платеж использует защищенного получателя Orchard или Sapling.
Ключи просмотра обеспечивают контролируемый доступ на чтение, не предоставляя права тратить средства. Они могут поддерживать бухгалтерский учет, отчетность или выборочное раскрытие, если кошелек и бизнес-процесс обрабатывают их правильно. Их все равно следует защищать как конфиденциальную информацию, поскольку держатель может узнать детали транзакции, которые не являются публичными в цепочке.
Сетевая конфиденциальность также не скрывает информацию, собираемую в других местах. Биржа, продавец или контрагент могут знать личность учетной записи, адрес IP, детали доставки или временные связи. Большее количество подтверждений может снизить риск отмены, но не скрывает информацию, уже видимую в прозрачном пути или уже переданную сервису.
Полезное различие заключается не в том, какая сеть универсально лучше, а в том, соответствует ли прозрачность, необязательная защита или конфиденциальность по умолчанию предполагаемому рабочему процессу.
| Сеть | Модель транзакций | Поведение адресов | Консенсус | Типичное применение | Операционный компромисс |
|---|---|---|---|---|---|
| Zcash | Прозрачные, экранирующие, экранированные и неэкранированные пути сосуществуют. | Прозрачные получатели, получатели Sapling и Orchard могут быть представлены через совместимые форматы адресов, включая унифицированные адреса. | Доказательство работы. | Рабочие процессы, которые намеренно выбирают экранированную поддержку или выборочное раскрытие. | Совместимость получателя, пула и сервиса должна быть проверена. |
| Биткоин | Входы и выходы транзакций являются публично проверяемыми. | Форматы адресов идентифицируют поддерживаемые типы скриптов, а не экранированный пул. | Доказательство работы. | Широко поддерживаемые публичные платежи и расчеты UTXO. | Публичный граф транзакций требует отдельных методов обеспечения конфиденциальности. |
| Monero | Функции конфиденциальности протокола применяются к обычным переводам по умолчанию. | Адресация кошельков построена вокруг приватного поведения транзакций, а не необязательных прозрачных получателей. | Доказательство работы. | Пользователи, которые хотят получить конфиденциальность, не выбирая прозрачный или экранированный путь. | Поддержка сервисов, методы аудита и операционные инструменты отличаются от прозрачных систем UTXO. |
Большинство ошибок возникает из-за рассмотрения сетевой возможности как автоматического свойства каждого кошелька, адреса и транзакции.
Исправление: Zcash поддерживает прозрачные и экранированные пути. Только поля, защищенные выбранными протоколами экранированных переводов, получают эти свойства конфиденциальности в цепочке.
Почему это важно: Прозрачный отправитель или получатель может раскрыть адреса и суммы, которые невозможно скрыть позже, ожидая больше блоков.
Исправление: Унифицированный адрес — это контейнер для совместимых типов получателей. Отправляющий кошелек выбирает поддерживаемый им получатель в соответствии с применимым стандартом и своими возможностями.
Почему это важно: Конечный путь может отличаться в разных кошельках, поэтому отправитель должен проверить отображаемого получателя и результат конфиденциальности.
Исправление: Подтверждения увеличивают глубину после включения в блок и снижают риск реорганизации в соответствии с политикой. Они не переписывают ранее раскрытые данные транзакции.
Почему это важно: Безопасность от отмены и конфиденциальность — это разные свойства, и их нужно проверять отдельно.
Исправление: Поддержка зависит от продукта, версии и политики сервиса. Получатель, действительный по протоколу, может быть отклонен конкретным интерфейсом.
Почему это важно: Процессы отправки или депозита должны быть протестированы перед переводом, чувствительным ко времени или с высокой стоимостью.
Исправление: Текущие рекомендации по обычной комиссии учитывают логические действия и включают льготные действия. Кошельки могут рассчитывать разные обычные комиссии для по-разному сконструированных транзакций.
Почему это важно: Жесткое кодирование старой фиксированной суммы может занижать выбранную кошельком комиссию и создавать необычное поведение комиссии.
Исправление: Экранированные протоколы защищают определенные поля в цепочке, а не информацию, собираемую устройствами, сетями, биржами, продавцами или контрагентами.
Почему это важно: Операционная конфиденциальность по-прежнему зависит от подключений кошелька, идентичности учетной записи, времени и того, что передается вне цепочки.
Практические проверки различаются для того, кто совершает один платеж, команды кошелька, сервиса, принимающего депозиты, или организации, использующей выборочное раскрытие.
Перед отправкой определите, является ли получатель прозрачным, Sapling, Orchard или унифицированным адресом, и прочитайте предварительный просмотр кошелька для фактического пути перевода. Один баланс ZEC ничего не говорит о поддержке получателя или о том, что раскроет транзакция.
Кошелек должен разбирать текущие форматы адресов, правильно выбирать получателей, рассчитывать текущую стандартную комиссию и различать полученные и доступные для траты балансы. Сообщения об ошибках должны объяснять неподдерживаемые пути вместо молчаливого отката.
Сервисы должны указывать, какие типы получателей они принимают, могут ли они вернуть средства на экранированный адрес и сколько подтверждений требует их собственная политика риска. Операции депозита также нуждаются в пути восстановления для неподдерживаемых адресов или задержанной доступности к трате.
Выборочное раскрытие может поддерживать сверку или отчетность без предоставления права траты, но просматриваемый материал может раскрывать защищенную активность его держателю. Процедуры доступа, хранения, передачи и инцидентов должны быть определены до его передачи.
Снимок — это агрегированные данные CoinGecko ZEC/USD. График — это данные Binance Spot ZEC/USDT. USD и USDT — разные котируемые активы, поэтому отображаемые значения могут отличаться.
Основные технические стандарты, используемые для проверки транзакции, получателя, комиссии и пояснений к кошельку на этой странице.
Дополнительные операционные вопросы, на которые не отвечают основные разделы о транзакциях и получателях.
Ключи просмотра могут предоставлять доступ на чтение к поддерживаемой скрытой активности без предоставления возможности тратить средства. Организации по-прежнему необходима политика доступа, хранения и точного объема раскрытия информации.
Кошелек может обнаружить входящую транзакцию до того, как она достигнет глубины подтверждения или политики доверия, необходимых для траты. Интерфейс должен различать обнаруженные, подтвержденные и доступные для траты балансы.
Это зависит от содержимого Unified Address и кошелька отправителя. Кошелек может выбрать поддерживаемый прозрачный адрес получателя, если он присутствует, но отправитель должен проверить отображаемый путь, потому что этот выбор меняет то, что является публичным.
Проверенный технический контент, проверенные источники и история обновлений.