Обращение к деятельности Сивиллы Ключевой проблемой в достижении здорового распределения является обнаружение действий Сивиллы.

Примеры того, что мы рассматриваем как действия Сивиллы в LayerZero, следующие:

Если вы — единое целое с десятками, сотнями или тысячами адресов, участвующих в промышленном сельском хозяйстве. Если вы создали «бесполезный» NFT с единственной целью — переместить его по цепочкам. Если вы использовали популярные приложения «сивилл-фермерства», такие как Merkly, L2Pass, L2Marathon и т. д. Для получения дополнительной информации прочитайте этот твит. Если вы перебрасываете 0,01 доллара туда и обратно между цепочками ради того, чтобы прикоснуться к цепочке. Если вы думаете, что вы сивилла, скорее всего, вы и есть сивилла. Мы даем всем пользователям sybil возможность предоставить самоотчет в течение следующих 14 дней в обмен на 15% от запланированной суммы без каких-либо вопросов.

Если пользователь sybil не сообщит самостоятельно к концу 14-дневного периода (17 мая, 23:59 UTC), мы перейдем к следующим двум этапам:

Этап 1: Мы опубликуем собственный список всех идентифицированных пользователей sybil — те, кто идентифицирован и не сообщил о себе, не получат ничего. Этап 2: Мы откроем награду, где пользователи смогут отправлять подробные отчеты о деятельности Сивиллы. Успешный отчет приведет к тому, что пользователь Сивиллы ничего не получит, а охотник за головами получит 10% от запланированного распределения Сивиллы.

Как самостоятельно сообщить о деятельности Сивиллы Если вы являетесь пользователем sybil и хотите сообщить о себе, вот как это сделать:

Посетите sybil.layerzero.network Подключите кошелек, связанный с активностью Сивиллы Подпишите сообщение, чтобы подтвердить право собственности на адрес Повторите для всех адресов Сивиллы. Для промышленной деятельности мы также предоставляем API для массовой отчетности.

Примечание. Право на распределение будет зависеть от любых юридических или географических требований, каждая транзакция подписывается в цепочке и должна считаться постоянной.

Заключение Наша цель — вознаградить стойких пользователей — протоколов, пользователей и членов сообщества — которые помогли LayerZero добиться успеха до сих пор и которые помогут протоколу расширяться в будущем.

Спасибо всем, кто был частью этого путешествия. Это только начало.

Следите за обновлениями в ближайшее время!

Эта статья посвящена OFT, тому, как они работают, ключевым свойствам и тому, кто использует стандарт OFT.

Давайте погрузимся.

Что такое стандарт OFT? OFT означает «Взаимозаменяемый токен Omnichain».

Вы можете думать об OFT как об универсальном стандарте токенов, используемом для отправки, получения и формирования активов во всех блокчейнах.

Стандарт OFT — это контракт на создание и отслеживание токенов во многих цепочках одновременно. Он доступен любому, кто работает на LayerZero. Стандарт OFT распространяет взаимозаменяемые токены, такие как ERC20, на все цепочки, поддерживаемые LayerZero.

Проекты, развертывающие токен с использованием стандарта OFT, сохраняют полное право собственности на свои контракты, могут выбирать, в каких цепочках развертывать (сейчас и в будущем), а также имеют возможность выбирать способ проверки сообщений путем настройки уникального стека безопасности.

OFT Standard работает и работает уже 21 месяц, обеспечив объем переводов на сумму более 4,5 миллиардов долларов США в более чем 45 цепочках.

Как работают OFT? О переводах OFT и адаптации существующих токенов к стандарту OFT…

ОФТ Трансферы OFT работают через механизм «создания и сжигания», который работает одинаково для всех типов блокчейнов.

Передача OFT между блокчейнами включает два этапа:

Сначала токен «сжигается» (или уничтожается) в исходной цепочке блоков. Во-вторых, равное количество токенов «чеканится» (или создается) в новом блокчейне.

Ключевые свойства стандарта OFT Любой проект, создающий OFT, наследует следующие характеристики:

Контрактное владение Стандарт OFT, по своей сути не связанный с хранением, позволяет разработчикам сохранять право собственности и контроль над своими контрактами на токены, управляя поставкой токенов непосредственно в каждом блокчейне. LayerZero намеренно разработан как неизменяемый протокол, который не имеет возможности хранить активы, изменять настройки безопасности или поддерживать цепочку интегрированных контрактов. LayerZero никогда не сможет взять под контроль OFT, принять решения по безопасности, которые могут изменить способ проверки передачи OFT, или отключить поддержку цепочки, в которой включен OFT.

Некастодиальный характер стандарта OFT гарантирует, что токены остаются под контролем проекта, устраняя риски контрагентов, которые распространены в других кросс-чейн-решениях. Кроме того, развертыватели OFT могут настроить дополнительную структуру комиссий в дополнение к переводам OFT, если они хотят получать доход от своего проекта.

Гибкая безопасность Любой объект, способный проверять сообщения между цепочками, может без разрешения участвовать в LayerZero в качестве децентрализованной сети проверки (DVN), включая собственные мосты, сторонние мосты, оракулы и т. д. Приложения, созданные на LayerZero, могут выбирать комбинацию DVN для подтверждения достоверность межсетевого сообщения до его выполнения в цепочке назначения. Выбор приложения DVN называется стеком безопасности.

LayerZero позволяет разработчикам токенов выбирать собственный набор DVN для проверки передач OFT. Такая гибкость позволяет развертывателям токенов настраивать индивидуальные стеки безопасности, соответствующие конкретным требованиям их токенов.

Помимо выбора, какие объекты проверяют передачу токенов, эмитенты токенов также могут выбирать, в каких цепочках развертывается токен, сколько блоков DVN должен ждать для проверки сообщения и как сообщение выполняется в цепочке назначения. Владельцы приложений могут обновлять конфигурации при появлении новых технологий и расширять свои OFT на новые цепочки в любое время.

Кроме того, модуль Pre-Crime действует как расширенный уровень безопасности, активно проверяя транзакции на предмет потенциальных угроз или нарушений до их выполнения, тем самым усиливая защиту протокола от эксплойтов.

Контакт
Если вы планируете использовать кроссчейн своего токена или у вас есть вопросы о том, как реализовать стандарт OFT для вашего проекта, обратитесь по адресу bd@layerzerolabs.org. Команда может предложить решения и следующие шаги по развертыванию OFT.

Для конкретных запросов OFT заполните эту форму! Для получения дополнительной информации о LayerZero посетите эту ветку, прочитайте эту статью, ознакомьтесь с нашей документацией или посетите веб-сайт. Для получения дополнительной информации команда LayerZero Labs готова ответить на общие вопросы в Discord и Telegram. Вы также можете следить за LayerZero Labs на X, чтобы получать самую свежую информацию.

Ищете полное погружение в LayerZero V2? Прочтите это здесь.

Вы также можете послушать недавнее сообщение в Твиттере, организованное LayerZero Labs, в котором объясняются DVN с точки зрения команд, которые ими управляют.

Что такое децентрализованная сеть верификаторов (DVN)? Каждое приложение, созданное на LayerZero, может настроить стек безопасности, состоящий из ряда обязательных и дополнительных сетей децентрализованной проверки (DVN), для проверки выдаваемого payloadHash целостности сообщения, определяя дополнительный порог, когда одноразовый номер сообщения может быть зафиксирован как проверенный.

Другими словами, DVN — это объекты, ответственные за проверку сообщений, отправляемых по цепочкам приложениями, использующими LayerZero.

Кто может управлять DVN? LayerZero не имеет разрешений.

Таким образом, любой объект может создать DVN или разработать адаптер DVN, если его схема проверки может подтвердить целостность payloadHash сообщения.

Это приводит к тому, что разработчики приложений могут выбирать из широкого спектра опций DVN, охватывающих несколько типов клиентов, методов проверки, наборов проверки и методов проверки.

Например, для одной DVN может потребоваться участие 20 валидаторов, разбросанных по нескольким континентам, и она будет управляться исследовательской организацией, специализирующейся на криптовалюте Ethereum. В другом DVN может участвовать несколько подписантов из курируемой группы предприятий. Более новые DVN могут использовать протокол повторной ставки и реализовывать механику экономической безопасности или сокращения.

В настоящее время для приложений, построенных на LayerZero, доступно более 30 DVN, охватывающих методы проверки, использующие технологию zk, промежуточные цепочки, подписывающие стороны консорциума и сторонние мосты.

Полный список доступных DVN можно найти здесь.

Скоро появятся DVN, включающие собственные мосты, дополнительные мосты сторонних производителей, службы рестейкинга, zkOracles и кошельки MPC.

Почему важны DVN? Приложения, созданные на LayerZero, могут выбирать любой DVN (или комбинацию DVN) для проверки сообщений, передаваемых между цепочками. Выбранная конфигурация DVN является частью стека безопасности приложения.

Протокол LayerZero был специально разработан, чтобы занять беспристрастную позицию в отношении проверки сообщений. Вместо того, чтобы применять один фиксированный подход к безопасности, LayerZero передает ответственность за безопасность самим приложениям.

Мы считаем, что разработчики должны выбирать методологию проверки, которая соответствует потребностям их проекта и что она может и должна развиваться со временем по мере роста исследований и проектов без какого-либо ущерба для долгосрочной безопасности.

Это выбор конструкции, который отличается от большинства протоколов и служб обмена сообщениями, которые вместо этого предлагают только одну общую конфигурацию безопасности, постоянно обновляя единую монолитную модель сквозной безопасности (т. е. набор валидаторов, оракул, промежуточную цепочку и т. д.) для включения новые цепи.

Универсальный подход к безопасности часто приводит к тому, что приложения либо недоплачивают, либо переплачивают за безопасность. Например, омникан-проект NFT имеет гораздо меньшие требования к безопасности, чем омникан-денежный рынок. Один проект обеспечивает переводы на сумму менее 0,5 ETH, а другой может обеспечить переводы на сумму более 1 миллиарда долларов. Однако, если оба они построены на общем межсетевом протоколе безопасности, их проекты — и пользовательская база — платят одинаковую сумму за безопасность (показано ниже).

Заключение V2 — это объединение блокчейнов, универсальное развитие и безопасность приложений.

LayerZero в V2 представляет собой полную противоположность привязке к поставщику, позволяя разработчикам выбирать, изменять и комбинировать различные типы методов проверки в зависимости от конкретного варианта использования.

Устраните бункеры. Стройте везде. Собственная безопасность.

Спасибо Ирине за соавторство в написании этой статьи.

Контакт Для получения дополнительной информации о V2 посетите эту ветку, прочитайте эту статью или ознакомьтесь с нашей документацией. Чтобы узнать больше о LayerZero в целом, посетите веб-сайт. Для получения дополнительной информации команда LayerZero Labs готова ответить на общие вопросы в Discord и Telegram. Вы также можете следить за LayerZero Labs на X, чтобы получать самую свежую информацию.

Для конкретных запросов DVN заполните эту форму! О LayerZero LayerZero — это не требующий разрешений, устойчивый к цензуре и неизменяемый протокол, соединяющий блокчейны. Используя LayerZero, разработчики могут отправлять и составлять произвольные сообщения по цепочкам, сохраняя при этом полный контроль над безопасностью своего приложения.

Вот план статьи:

Что такое LayerZero?

Объяснение LayerZero — определение, понятное каждому Основные принципы — неизменные, не требующие разрешений, устойчивые к цензуре. Как работает версия 2?

Архитектура V2 — протокол, стандарты, инфраструктура V2 и V1 — ключевые моменты сравнения двух с акцентом на стеки безопасности Жизненный цикл транзакции V2 — как отправить сообщение за четыре шага Варианты использования — идентичность, стейблкоины и рынки кредитования. Допущения доверия V2 — развертывание конечных точек, риск сговора, мультиподпись 2/2 и многое другое LayerZero и рынок

Мосты — как V2 поглощает индустрию мостов (обмен сообщениями и ликвидность) OApp и OFT — почему всем следует использовать контрактные стандарты V2 Заключительные мысли

Что такое LayerZero?

Объяснение LayerZero В зависимости от того, кто вы — ваша работа, ваше портфолио, ваше образование, ваша склонность к мемам — то, как вы понимаете LayerZero, вероятно, будет различаться. То же самое происходит и с большинством криптопримитивов. Например, финансовый менеджер, водитель Uber и ваша бабушка, скорее всего, будут иметь разные определения того, что такое Биткойн. В этом примере Биткойн, вероятно, является чем-то вроде цифрового золота, инвестиций или денег даркнета, которые используются преступниками соответственно.

Учитывая это, наличие единого определения LayerZero, по-видимому, противоречит цели. Вот несколько разных способов объяснить LayerZero, предназначенных для некоторых из наиболее вероятных читателей этой статьи:

Для любителей технических документов:

Используя неизменяемую конечную точку, модули проверки только для добавления и полностью настраиваемую инфраструктуру проверки, LayerZero обеспечивает безопасность, настраиваемость и расширяемость, необходимые для достижения совместимости омникан. LayerZero обеспечивает строгое эксклюзивное владение приложениями безопасностью протокола и затратами с помощью своей новой модульной структуры безопасности с минимизацией доверия, предназначенной для универсальной поддержки всех блокчейнов и вариантов использования. Приложения Omnichain (OApps), созданные на основе протокола LayerZero, обеспечивают беспрепятственное независимое от блокчейна взаимодействие благодаря универсальной сетевой семантике LayerZero.

Для ботаников:

LayerZero — это транспортный уровень, не зависящий от проверки, который позволяет смарт-контрактам в разных блокчейнах взаимодействовать. Это полностью подключенная ячеистая сеть, не привязанная к какой-либо инфраструктуре или блокчейну. LayerZero — это протокол «омникейн», позволяющий разработчикам создавать унифицированные приложения с модульными параметрами безопасности.

Для разработчиков web3:

LayerZero — это неизменяемый, не требующий разрешений и устойчивый к цензуре протокол, соединяющий ранее разрозненные блокчейны. Используя LayerZero, разработчики могут отправлять произвольные сообщения по цепочкам, сохраняя при этом полный контроль над безопасностью своего приложения. LayerZero позволяет разработчикам создавать и настраивать унифицированные приложения, токены и примитивы данных независимо от цепочки. Эта концепция унифицированной кросс-чейн разработки заключена в слове «омникачейн» и представляет собой то, к чему LayerZero видит будущее криптовалюты.

Для любителей технологий:

LayerZero для блокчейнов — то же самое, что TCP/IP для Интернета. Там, где TCP/IP позволяет различным компьютерам под управлением разных операционных систем в разных сетях взаимодействовать (что приводит к подключению к Интернету), LayerZero позволяет взаимодействовать смарт-контрактам, закодированным на разных языках в разных блокчейнах. Это позволяет разработчикам создавать приложения, которые существуют повсеместно в блокчейнах.

Контакт Для получения дополнительной информации о V2 посетите эту ветку, прочитайте эту статью или ознакомьтесь с нашей документацией.

Чтобы узнать больше о LayerZero в целом, посетите веб-сайт. Для получения дополнительной информации команда LayerZero Labs готова ответить на общие вопросы в Discord и Telegram. Вы также можете следить за LayerZero Labs на X, чтобы получать самую свежую информацию.

По конкретным запросам:

Поставщики инфраструктуры, желающие запустить Executor DVN, должны заполнить эту форму! Разработчики, желающие создать OApp или OFT, должны заполнить эту форму!

Основные моменты версии 2 Универсальный обмен сообщениями: между цепочками можно отправлять и составлять сообщения любого типа, включая произвольные данные, вызовы внешних функций и/или токены. Модульная безопасность: разработчики могут выбирать из предпочитаемой ими комбинации из более чем 20 децентрализованных сетей проверки (DVN) при выборе стека безопасности для проверки сообщений между цепочками. Несанкционированное выполнение: любой может запустить Executor в V2. Информацию о том, как запустить собственный Executor, можно найти здесь. Унифицированная семантика: контракты OApp и OFT позволяют разработчикам создавать приложения и токены, которые работают одинаково во всех блокчейнах V2, на которых есть конечная точка. Совместимость с V1. Для приложений V1 существуют варианты миграции. Если приложения уже развернуты в версии 1, они могут использовать новую модель безопасности и выполнения через ULN 301. Дополнительную информацию можно найти здесь. Более подробную информацию о версии 2 можно найти в видеоролике о запуске версии 2, в официальном документе версии 2 и в документации разработчика версии 2. Отчеты аудита для версии 2 также доступны здесь.

О LayerZero LayerZero — это не требующий разрешений, устойчивый к цензуре и неизменяемый протокол, соединяющий блокчейны. Используя LayerZero, разработчики могут отправлять произвольные сообщения по цепочкам, сохраняя при этом полный контроль над безопасностью своего приложения. LayerZero позволяет разработчикам создавать, настраивать и компоновать унифицированные приложения, токены и примитивы данных во многих цепочках.

Все, что можно запрограммировать как смарт-контракт в одной цепочке, можно запрограммировать в нескольких цепочках с помощью LayerZero. С момента его создания на LayerZero было развернуто более 40 000 контрактов OApp, сотни команд используют стандарт OFT LayerZero для питания токенов, а десятки команд создали полномасштабные приложения в виде группировок OApp. Эти продукты включают рынки кредитования, стейблкоины, мосты, корпоративные проекты, NFT, мем-токены и решения для идентификации.

Контакт Чтобы узнать больше о LayerZero, посетите веб-сайт. Для получения дополнительной информации команда LayerZero Labs готова ответить на общие вопросы в Discord и Telegram. Вы также можете следить за LayerZero Labs на X, чтобы получать самую свежую информацию.

По конкретным запросам:

Поставщики инфраструктуры, желающие запустить Executor DVN, должны заполнить эту форму! Разработчики, желающие создать OApp или OFT, должны заполнить эту форму!

Подобно тому, как TCP/IP стандартизировал разработку Интернета, цель LayerZero - стандартизировать разработку приложений для всех цепочек. Эта концепция унифицированной межцепочечной разработки заключена в слове «омничейн», и именно так LayerZero представляет себе будущее криптовалют.

LayerZero - это протокол, разработанный для соединения блокчейнов при соблюдении следующих фундаментальных принципов:

Безразрешительность: Любой может запустить инфраструктуру, необходимую для проверки и выполнения сообщений. Любой может строить на основе LayerZero и взаимодействовать с ним. Устойчивость к цензуре: ни одно отдельное сообщение не может быть выполнено до тех пор, пока не будут проверены все предыдущие сообщения, что означает, что ни одно отдельное сообщение не может быть подвергнуто цензуре ни на каком пути. Неизменность: Конечные точки каждой цепи существуют в виде смарт-контрактов. Новые библиотеки верификации могут быть добавлены только в виде обновлений. Они не подлежат обновлению и будут существовать бесконечно. LayerZero V2 TL;DR Сегодня мы отмечаем развертывание LayerZero V2 в 40+ тестовых сетях и представление технического описания V2. V2 создает омниканальную сеть блокчейн для разработчиков, которые смогут создавать универсальные приложения.

В обновлении представлены ключевые функции:

Децентрализованные сети проверки (DVN): заменяя Oracle V1, эта роль без разрешений дает любому объекту, способному проверять пакеты данных между цепочками, присоединиться к LayerZero в качестве DVN. Адаптеры: адаптеры Axelar и CCIP DVN будут доступны сегодня в тестовой сети и после запуска основной сети. Другие адаптеры, запланированные на 2024 год, позволят разработчикам интегрировать в LayerZero любой тип собственного моста, стороннего моста, промежуточной цепочки, Oracle или других методов проверки, тем самым избегая привязки к поставщику на уровне безопасности. X из Y из N: это модульный подход к проверке, позволяющий приложениям не переплачивать и не недоплачивать за безопасность в зависимости от варианта использования. X из Y из N позволяет приложениям комбинировать DVN по своему усмотрению. Например, комбинация DVN «1 из 3 из 5» будет включать в себя один обязательный DVN и два произвольных DVN из пяти, которые должны проверять сообщение для выполнения кроссчейна. Выполнение без разрешения. Заменяя ретранслятор и отделяя выполнение от проверки, LayerZero V2 представляет исполнителей — роль без разрешений, которая облегчает плавное выполнение в цепочке назначения, упрощает платежи за газ и предлагает настраиваемые параметры газа. Стек безопасности: каждое приложение Omnichain (OApp) должно настроить стек безопасности, включающий DVN, исполнителей, подтверждения цепочки, библиотеки сообщений и пути цепочки для обмена сообщениями омникачейны. Эта настройка предоставляет приложениям полный контроль над безопасностью. В версии 2 предусмотрена подписка, при этом разработчикам OApp рекомендуется установить собственный стек безопасности. Повышенная пропускная способность. Предоставляя возможность ленивого или строгого применения nonce, V2 позволяет разработчикам выбирать, хотят ли они выполнять транзакции по порядку или вне очереди. При выполнении транзакций вне очереди пропускная способность LayerZero соответствует пропускной способности целевой цепочки, сохраняя при этом устойчивость к цензуре. Улучшенная программируемость: улучшенные интерфейсы контрактов протоколов V2, библиотеки для конкретных путей, новые шаблоны проектирования и горизонтальная компонуемость переопределяют взаимодействие приложений, способствуя гибкости и бесперебойности межсетевых транзакций. Унифицированная семантика: V2 позволяет разработчикам создавать приложения, которые работают одинаково во всех цепочках блоков, в которых имеется конечная точка LayerZero, включая цепочки, не относящиеся к EVM. Совместимость с V1. Для команд, работающих на V1, запуск V2 обеспечит как прямую, так и обратную совместимость.

Обращайтесь по любым вопросам
Для команд, работающих на V1, запуск V2 обеспечит как прямую, так и обратную совместимость. Информацию о миграции можно найти в нашей документации. Важно отметить, что V1 все еще находится в производстве и будет производиться вечно. На данный момент версия 2 не вносит критических изменений в версию 1 (это может измениться, когда конечные точки версии 2 распространятся на новые цепочки).

По мере приближения запуска основной сети мы продолжим обновлять нашу документацию с учетом любых изменений и публиковать образовательные ресурсы, чтобы сделать переход от версии 1 к версии 2 максимально плавным.

Если вы планируете использовать V2, у вас есть вопросы о переходе с V1 или о чем-то промежуточном, присоединяйтесь к нашему Discord.

Оригинальный алгоритм Colored Coin был призван решить эту проблему с помощью слоя метаданных без потерь поверх бухгалтерской книги биткоина, но в более общем случае в EVM это было бы сродни хранению бесконечно большого бухгалтерского списка всех адресов всех возможных раскрашивателей и их текущего баланса на каждом кошельке. Это трудновыполнимо как с точки зрения хранения данных, так и с точки зрения вычислений, и, как таковое, никогда не было жизнеспособным для реализации, что оставляет мало хороших возможностей для точного атрибутирования стоимости на цепи.

Представляем ColorTrace.

В качестве практического примера ColorTrace мы рассмотрим реализацию, использованную USDV при недавнем запуске стабильного монета.

В качестве практического примера ColorTrace мы рассмотрим реализацию, использованную компанией USDV при недавнем запуске стабильного монета.

Проблема, которую необходимо было решить, заключалась в том, что большая часть стоимости существующих стабильных монет определялась самими участниками рынка. Такие группы, как Uniswap, Curve, Coinbase и Binance, перевели триллионы долларов в стабильных монетах и принесли огромную пользу своим базовым экосистемам, но только одна из них когда-либо получала за это прямое вознаграждение. Компания Circle заключила с Coinbase специальное соглашение о разделе доходов USDC на основе вклада Coinbase в успех USDC. За это Coinbase в настоящее время получает почти $1B в год. Простым решением было бы заключить аналогичные сделки со всеми другими крупными участниками, но тут-то и возникает сложность. Представьте себе мир, в котором 24 миллиарда долларов США находятся в обращении, а большинство из них - в EOA. Сколько доходов получает каждая из сторон? Для баланса, хранящегося в Uniswap, Curve, Coinbase и Binance, легко понять, какой вклад внесла каждая сторона, но для более чем $10B+, хранящихся в кошельках пользователей и EOA, трудно определить, какой вклад внесла каждая группа.

Именно здесь на помощь приходит атрибуция стоимости в ончейне. ColorTrace открывает возможность для каждого субъекта получить пропорциональное вознаграждение за стоимость, которую он создал для базовой экосистемы. В случае с USDV это означает, что каждый токен, выпущенный организацией в обращение, будет помечен ее цветом и приписан к ней.

Addressing Sybil Activity

A key challenge in achieving a healthy distribution is detecting sybil activities.

Examples of what we view as sybil activity within LayerZero are as follows:

• If you are a single entity with tens, hundreds, or thousands of addresses participating in industrial farming.

• If you minted a “valueless” NFT for the sole purpose of moving it around chains.

• If you have used popular “sybil farming” applications such as Merkly, L2Pass, L2Marathon, etc. For more information, read this tweet.

• If you bridged $0.01 back and forth across chains for the sake of having touched a chain.

• If you think you are a sybil, you are most likely a sybil.

We are giving all sybil users an opportunity to self-report within the next 14 days in return for 15% of their intended allocation, no questions asked.

If a sybil user does not self-report by the end of the 14-day period (May 17th 23:59 UTC), we will move into the following 2 phases:

• Phase 1: We will release our own list of all identified sybil users — those who are identified and did not self-report will receive nothing.

• Phase 2: We will open a bounty where users can submit detailed reports of sybil activity. A successful report will result in the sybil user receiving nothing, and the bounty hunter receiving 10% of the sybil’s intended allocation.

How to Self-Report Sybil Activity

If you are a sybil user and would like to self-report, here’s how:

1. Visit sybil.layerzero.network

2. Connect a wallet associated with sybil activity

3. Sign message to prove ownership of address

4. Repeat for all sybil addresses

For industrial sybil activities, we are also providing an API for mass reporting.

Note: All allocation eligibility will be subject to any legal or geographic requirements and each transaction is signed on-chain and should be considered permanent.

Conclusion

Our goal is to reward the durable users — protocols, users, and community members — who helped LayerZero succeed thus far and who will help the protocol expand in the future.

To everyone who has been part of this journey, thank you. This is only the beginning.

Stay tuned for more updates soon!

Twitter Website Discord Medium. Telegram

This article is about OFTs, how they work, key properties, and who is using the OFT Standard.

Let’s dive in.

What is the OFT Standard?

OFT stands for “Omnichain Fungible Token.”

You can think of OFT as a universal token standard used to send, receive, and compose assets across all blockchains.

The OFT Standard is a contract for creating and tracking tokens across many chains at the same time. It is available to anyone building on LayerZero. The OFT Standard extends fungible tokens, like ERC20, to all the chains LayerZero supports.

Projects deploying a token using the OFT Standard maintain complete ownership of their contracts, may select what chains to deploy on (now and in the future), and have the option to choose how messages are verified by configuring a unique Security Stack.

The OFT Standard has been live and in production for 21 months, securing over $4.5 billion in transfer volume across 45+ chains.

How Do OFTs Work?

On OFT transfers and adapting existing tokens into the OFT Standard…

OFT Transfers

OFTs operate through a mint-and-burn mechanism that works the same on every type of blockchain.

Transferring an OFT between blockchains involves two steps:

• First, the token is ‘burned’ (or destroyed) on the original blockchain.

• Second, an equal amount of the token is ‘minted’ (or created) on the new blockchain.

LayerZero facilitates this accounting process by sending a message from the source to the destination blockchain, instructing it to mint the same number of tokens that were burned. This keeps the token’s total amount the same across all networks, ensuring its value stays stable during the move and that the OFT retains a unified, global supply count.

OFT Adapter

For projects that have already minted a token on a single chain, the OFT Adapter is available to extend that token across every LayerZero-supported blockchain. This process involves an intermediary contract that handles sending and receiving tokens that have already been deployed.

For example, when transferring an ERC20 from the source chain (Chain A), the token will lock in the OFT Adapter, triggering a new token to mint on the selected destination chain (Chain B) via the paired OFT Contract. From there, the OFT can be moved across any LayerZero-supported blockchain the project wants to enable using the burn and mint mechanism described above.

Key Properties of the OFT Standard

Any project creating an OFT inherits the following characteristics:

Contract Ownership

Inherently non-custodial, the OFT Standard allows developers to retain ownership and control over their token contracts, managing the token supply directly across each blockchain. LayerZero is intentionally designed to be an immutable protocol that has no ability to custody assets or alter the security settings or chain support of integrated contracts. LayerZero can never take custody of an OFT, make security decisions that would alter how an OFT transfer is verified, or disable support for a chain that an OFT is enabled on.

The non-custodial nature of the OFT Standard ensures that tokens remain under a project’s control, eliminating counterparty risks that are prevalent in other cross-chain solutions. Furthermore, OFT deployers may customize an optional fee structure on top of OFT transfers should they wish to generate revenue for their project.

Flexible Security

Any entity capable of verifying cross-chain messages may permissionlessly participate in LayerZero as a Decentralized Verifier Network (DVN), including native bridges, third-party bridges, oracles, etc. Applications building on LayerZero may select a combination of DVNs to attest to the validity of a cross-chain message before it is executed on the destination chain. An application’s selection of DVNs is called its Security Stack.

LayerZero empowers token developers to select their own set of DVNs for verifying OFT transfers. This flexibility allows token deployers to configure customized Security Stacks that align with the specific requirements of their tokens.

On top of choosing what entities verify token transfers, token issuers may also choose what chains the token is deployed on, how many blocks a DVN must wait to verify a message, and how a message is executed on the destination chain. Application owners can update configurations when new technologies emerge and expand their OFT to new chains at any time.

Additionally, the Pre-Crime module functions as an advanced security layer, proactively scrutinizing transactions for potential threats or irregularities before they are executed, thus bolstering the protocol’s defense against exploits.

Universal Semantics

OFTs bring standardization to token operations across different blockchain networks. Traditional tokens are often bound by the rules and standards of their native blockchain, leading to a fragmented experience when interacting with multiple chains. OFTs, however, maintain a consistent standard across all chains they operate on.

This uniformity simplifies the user and developer experience, as the token behaves identically regardless of the blockchain and can be composed via a wide variety of contracts. Such standardization is invaluable for developers and users alike, as it reduces the complexity and learning curve associated with managing assets on multiple chains. Furthermore, developers deploying an OFT using the LayerZero Executor can take advantage of full gas abstraction, allowing users to pay only a single gas fee from the source chain to execute an entire cross-chain flow.

Unified Token Supply

OFTs unify liquidity across networks through swift and secure communication between contracts via burn and mint. This eliminates the need for wrapped assets (4/5 largest exploits have occurred with wrapped assets, including $326M Wormhole hack in 2022) and liquidity on multiple chains for bridging via standalone asset pools, paving the way for scalable liquidity across numerous L2s and L1s.

In terms of efficiency, OFTs exist as native tokens on each chain, requiring only gas fees for transfer, devoid of additional costs associated with wrapping, bridging, or slippage. OFTs can be natively transferred across any LayerZero supported chains (currently 55+ chains) in a point-to-point flow, without ever needing to redeem on any one base chain.

OFT Standard Adoption

Any type of project can utilize the OFT Standard.

Over 100 projects have adopted the OFT Standard, ranging from stablecoins to gas tokens to LSTs.

For the sake of brevity, we will only list a few specific examples below…

Stablecoins

• Angle (agEUR): agEUR is the largest decentralized stablecoin pegged to the EURO. agEUR is available on 11 different chains. The coin has been moved 7.6 million times since it was launched 18 months ago.

• Abracadabra (MIM): Abracadabra was one of the first stablecoin projects to make their token omnichain. MIM is currently available on 11 chains.

Blockchain Tokens

• Bitcoin (BTC.b): Borderless Bitcoin leverages the LayerZero Omnichain Fungible Token (OFT) standard to seamlessly integrate Bitcoin across all LayerZero-supported networks.

• Metis (METIS): By leveraging OFTs, Metis enhanced the movement and utility of their native tokens across various blockchain environments.

DeFi Tokens

• Trader Joe (JOE): The Avalanche-founded dApp Trader Joe opted into the OFT Standards in February of 2023.

• Radiant (RDNT): Radiant Finance uses OFTs to enhance the liquidity and transferability of its governance token across various networks.

Liquid Staking Tokens

• StakeStone (STONE): StakeStone native LST, $STONE, is available on Ethereum and Manta as an OFT. As of January 2024, StakeStone’s TVL is above $750 million.

• unshETH (unshETH): unshETH expanded to BNB Chain from Ethereum by making its LST $unshETH an OFT in April 2023.

Conclusion

The OFT Standard represents a unified, secure, and user-friendly approach to tokenization.

OFT is one token standard for many chains that can use any type of verification method to approve token transfers.

As the industry continues to expand to 1000s of chains, the OFT Standard is here to enable unified token supply and liquidity while empowering token issuers to control the security specifications protecting asset transfers.

For more information on OFTs, listen to the LayerZero Lounge, where our DevRel team broke down many of the topics above in audio format.

Contact

If you’re considering bringing your token cross-chain or have questions about how to implement the OFT Standard for your project, reach out to bd@layerzerolabs.org. The team can offer solutions and next steps on how to deploy an OFT.

• For specific OFT inquiries, fill out this form!

For more information on LayerZero, check out this thread, read this article, check out our docs, or visit the website. For additional information, the LayerZero Labs team is available to answer general questions on Discord and Telegram. You can also follow LayerZero Labs on X to receive the most up-to-date information.

Twitter Website Discord Medium. Telegram

Looking for a complete deep dive into LayerZero V2? Read it here.

You can also listen to a recent Twitter space LayerZero Labs hosted that explains DVNs from the perspective of the teams that run them.

What is a Decentralized Verifier Network (DVN)?

Every application built on LayerZero can Configure a Security Stack comprised of a number of required and optional Decentralized Verifier Networks (DVNs) to check the payloadHash emitted for message integrity, specifying an optional threshold for when a message nonce can be committed as Verified.

In other words, DVNs are the entities responsible for verifying messages sent across chains by applications that use LayerZero.

Who Can Run a DVN?

LayerZero is permissionless.

Therefore, any entity can build a DVN or develop a DVN Adapter as long as its verification schema can confirm the integrity of a message’s payloadHash.

This leads to a wide array of DVN options for application developers to select from, spanning multiple client types, validation methods, validation sets, and proving techniques.

For example, a single DVN may require the participation of 20 validators spread across multiple continents and be run by a crypto-native Ethereum research organization. Another DVN may involve a handful of signers from a curated group of enterprises. More novel DVNs may leverage a re-staking protocol and implement economic security or slashing mechanics.

Over 30 DVNs are currently available to applications building on LayerZero, spanning verification methods that use zk-technology, middlechains, consortium signers, and third-party bridges.

Example DVNs

A full list of DVNs available can be found here.

DVNs coming soon include native bridges, more third-party bridges, restaking services, zkOracles, and MPC wallets.

Why are DVNs Important?

Applications built on LayerZero may choose any DVN (or combination of DVNs) to verify messages going between chains. The selected configuration of DVNs is part of an application’s Security Stack.

The LayerZero protocol was deliberately designed to take an unbiased stance on how messages are verified. Rather than enforcing one fixed security approach, LayerZero hands ownership of security over to the applications themselves.

We believe developers should choose the verification methodology that fits their project’s needs and that it can and should evolve over time with research and project growth without any compromise to long term security.

This is a design choice that differs from most messaging protocols and services, which instead offer only a single shared security configuration, continually updating a single, monolithic end-to-end security model (i.e. validator set, oracle, middlechain, etc) to include new chains.

A one-size-fits-all approach to security often leads to applications either under or overpaying for security. For example, an omnichain NFT project has much lower security needs than an omnichain money market. One project secures < 0.5 ETH value transfers, while another may secure $1B+. However, if both are built on a shared security cross-chain protocol, their projects — and user base — pay the same amount for security (shown below).

Monolithic Security

In contrast, with a diverse and growing set of DVNs, LayerZero developers can configure security parameters to best suit their application rather than being forced to fit their application into a rigid, monolithic architecture. This not only allows for more immediate flexibility, but it also future-proofs applications. For instance, without writing any additional code, an application can swap an optimistic oracle DVN for a battle-tested zkOracle as new technologies become available.

Modular Security

Research and time will introduce safer and more sophisticated methods of securing information delivered between chains. LayerZero V2 enables such advancements to be leveraged in the future.

How are DVNs Used in Practice?

An application’s “Security Stack” refers to its unique configuration of DVNs, Executors, and other security preferences. This includes choices such as enabled chains and the number of block confirmations DVNs must wait for message verification.

For the purpose of this article, we will only focus on the DVN aspect of the Security Stack.

The concept called “X of Y of N” is the core of the Security Stack. It is the configuration of DVNs inside a Security Stack, describing how applications select and/or remove DVNs to verify messages. (Editor’s note: video explanation here.)

X of Y of N allows applications to combine DVNs however they like. Application developers can designate a quorum of DVNs to check the integrity of a cross-chain message before signing off on its validity.

For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five to verify a message before moving on to execution.

Example of a DVN setup!

When building a strong Security Stack, applications should combine DVNs that minimize collusion and/or hack risk. For example, a DVN setup of Google Cloud and the Axelar DVN Adapter is a very hard Security Stack, as it includes verification from a centralized and a decentralized entity, minimizing collusion risk (and more DVNs can be added to this setup later on).

To minimize risk, applications can run their own DVN, reach out to DVN teams to perform due diligence, and/or choose a DVN combination where it is impossible to collude.

Conclusion

V2 is about connecting blockchains, universal development, and application-owned security.

With V2, LayerZero is the antithesis of vendor lock-in, allowing developers to choose, modify, and combine different types of verification methods based on a specific use case.

Eliminate silos. Build everywhere. Own security.

Thank you to Irene for co-writing this article.

Contact

For more information on V2, check out this thread, read this article, or check out our docs. To learn more about LayerZero in general, check out the website. For additional information, the LayerZero Labs team is available to answer general questions on Discord and Telegram. You can also follow LayerZero Labs on X to receive the most up-to-date information.

• For specific DVN inquiries, fill out this form!

About LayerZero

LayerZero is a permissionless, censorship-resistant, and immutable protocol that connects blockchains. Using LayerZero, developers can send and compose arbitrary messages across chains while preserving full control over their application’s security.

Twitter Website Discord Medium. Telegram

Here is an outline of the article:

What Is LayerZero?

Explaining LayerZero — a definition that everyone can understand Core Principles — immutable, permissionless, censorship-resistant How Does V2 Work?

V2 Architecture — protocol, standards, infrastructure V2 vs V1 — key highlights comparing the two, with a focus on Security Stacks V2 Transaction Lifecycle — how to send a message in four steps Use Cases — identity, stablecoins, and lending markets V2 Trust Assumptions — endpoint deployments, collusion risk, 2/2 multisig, and more LayerZero and the Market

Bridges — how V2 inhales the bridge industry (messaging and liquidity) OApp and OFT — why everyone should use V2 contract standards Closing Thoughts

What Is LayerZero?

What is LayerZero? Explaining LayerZero Depending on who you are — your job, your portfolio, your education, your predilection for memes — how you understand LayerZero will likely differ. It’s the same way with most crypto primitives. For instance, a financial manager, an Uber driver, and your grandmother will likely have different definitions for what Bitcoin is. In that example, Bitcoin is probably something akin to digital gold, an investment, or darknet money that is used by criminals, respectively.

With that in mind, having a single definition for LayerZero seemingly defeats the purpose. Here are a few different ways to explain LayerZero, curated to a few of the most likely readers of this piece:

For the whitepaper enthusiasts:

Utilizing an immutable endpoint, append-only verification modules, and fully configurable verification infrastructure, LayerZero provides the security, configurability, and extensibility necessary to achieve omnichain interoperability. LayerZero enforces strict application-exclusive ownership of protocol security and costs through its novel trust-minimized modular security framework designed to support all blockchains and use cases universally. Omnichain applications (OApps) built on the LayerZero protocol achieve frictionless blockchain-agnostic interoperation through LayerZero’s universal network semantics.

For the nerds:

LayerZero is a verification agnostic transport layer that enables smart contracts on different blockchains to interoperate. It is a fully connected mesh network not bound to any infrastructure or blockchain. LayerZero is an “omnichain” protocol enabling developers to build unified applications with modular security parameters.

For the web3 developers:

LayerZero is an immutable, permissionless, and censorship-resistant protocol connecting previously siloed blockchains. Using LayerZero, developers can send arbitrary messages across chains while preserving complete control over their application’s security. LayerZero enables developers to create and configure unified applications, tokens, and data primitives, regardless of chain. This concept of unified cross-chain development is encapsulated in the word “omnichain” and is what LayerZero envisions the future of crypto moving towards.

For the technology enthusiasts:

LayerZero is to blockchains what TCP/IP is to the internet. Where TCP/IP allows different computers running different operating systems on different networks to communicate (resulting in a connected internet), LayerZero enables smart contracts coded in different languages on different blockchains to communicate. This allows developers to create applications that exist universally across blockchains.

For your TradFi friend who you thought understood but clearly didn’t:

Imagine your Windows computer couldn’t send an email to your boss’s Mac, or your Android phone couldn’t send a text message to your mother’s iPhone. We take this for granted, but it’s all powered by a communication protocol named TCP/IP that glues the Internet together. LayerZero is that communication protocol, but for blockchains. Before LayerZero, Ethereum couldn’t communicate with Bitcoin, and neither blockchain could communicate with Solana. With LayerZero, developers and users can interact with applications and tokens that exist on many blockchains through a single protocol, similar to how Mac, Linux, and Windows users can all communicate across the same Internet (early alpha: LZ + Solana, coming in 2024).

For the dinner table at Thanksgiving:

LayerZero is like the Internet, which opened up communication to the world — email, social media, zoom calls, etc. LayerZero will do that, but for crypto — meaning finance will be open, with anybody able to move value, take out loans, trade assets, etc, without going through an intermediary like a bank or a potential censor like a government.

Core Principles It is important to remember why we are here — to build an open and just digital economy for all people, for all time. Crypto is a space that should be permissionless, allowing anyone to interact with applications. Crypto should be censorship-resistant, facilitating the movement of data packets without judgment. Crypto should exist forever, leaving behind systems that are immutable and provable, unchanging. In general, it is pertinent that the protocol to connect crypto is designed to combat corruption so that whatever we are building in this space may stay parallel to the legacy system rather than become part of it.

LayerZero’s design mirrors these core principles.

LayerZero core principles. Immutable Endpoints (the interface for interacting with LayerZero) exist as immutable smart contracts on each chain LayerZero supports. These are non-upgradeable and cannot be changed by any party, providing a safe and predictable interface to interact with. Every piece of core protocol code is non-upgradable. Neither LayerZero Labs nor anyone else besides the owner of the omnichain application has the ability to change an application’s security configuration (unless Defaults or a delegate is selected to do so).

Censorship-Resistant Individual messages can only be executed once all previous messages have been verified, meaning no individual message can ever be censored on any pathway. There is no ability for the LayerZero protocol to selectively deliver messages once they’re successfully submitted on the source chain. If a transaction is successfully submitted on the source chain, it is guaranteed to be delivered to the destination chain.

Permissionless LayerZero is a pure protocol. Anyone can run the infrastructure that verifies and executes messages sent via LayerZero. If every developer and infrastructure provider stopped performing services, anybody could come in to join the protocol and pick up right where they left off. Furthermore, anyone may build on top of LayerZero and interact with those applications.

How Does LayerZero Work? V2 Architecture The core design of LayerZero V2 can be bucketed into three categories: protocol, standards, and infrastructure.

Protocol → These aspects of LayerZero protocol remain the same across every supported blockchain. In the V2 whitepaper, the protocol of LayerZero is what is deemed “intrinsic” — these are the contracts that will last forever (immutable), that anybody may build on top of (permissionless) and that enforces how transactions are ordered (censorship-resistant). The protocol comprises two entities, Endpoints and MessageLibs.

Endpoints: These are immutable smart contracts on each chain LayerZero supports. The Endpoint is the core of the LayerZero protocol. Once implemented, no entity cannot change endpoints, as they are immutable and non-upgradable. Endpoints offer a standardized interface for applications to manage security configurations and send/receive messages — the two most important things an application will want to control when building on top of LayerZero. Message Libraries: Each MessageLib is registered to an Endpoint and is how an application’s security configuration and data packet sending/receiving process is enforced. In other words, the MessageLib is how an Endpoint is fed information about the message being sent between blockchains — it is where the verification and communication of messages occurs. Notably, MessageLibs are append-only additions to Endpoints. This means they cannot be removed (still immutable) while allowing the protocol to upgrade verification methods when necessary. Developers building on LayerZero will never be forced to accept or update to a new MessageLib. To analogize here, consider LayerZero Endpoints as a blockchain and new MessageLibs as smart contracts. Just like how Uniswap updates its contracts through new product releases (UniswapV1, UniswapV2 and UniswapV3) and people can still use the old contracts, LayerZero may publish new MessageLibs, and people may still choose to use the older libraries.

Depiction of a LayerZero Endpoint. Standards → These enable the concept of “unified semantics” — where an application/token works the same across every LayerZero-supported blockchain. Unified semantics enable developers to easily build interfaces that interact with applications across tens of blockchains without having to rewrite code for new environments. LayerZero standards include how omnichain smart contracts are written, how data packets are structured, and how logic is composed. Anything a developer might need to launch an omnichain product from scratch can be found as audited, reusable, and battle-tested standards.

Contract Standards: LayerZero offers developers out-of-the-box message handling and configuration for applications (OApp) and tokens (OFT). OApp and OFT are extensions of existing contract standards — for example, OFT extends ERC-20s — and maximally cut down development time for building cool things. In the case of OApp and OFT, both contract standards allow developers to create universal applications and tokens that work the same across all LayerZero-supported chains. ONFT contract standards are already available in V1 and will be available in V2 later this year. Message Packets: This is how information is passed between chains. Each cross-chain message requires information to be formatted in a specific manner so that destination-chain activities may occur without issue. The Message Packet for LayerZero requires a nonce, source ID, sender address, destination ID, receiving address, a unique identifier, and the message payload. The nonce, source/destination IDs and unique identifier prevent replay attacks and misrouting, while also helping track the message across chains. The payload field carries the actual information or command that needs to be carried out on the destination chain. With this information correctly formatted, any generic message can be passed between chains, allowing for the transfer of data, assets, and/or external contract calls. This Message Packet format extends across any blockchain environment (EVM and non-EVM, public chains and private chains). Most of this formatting relating to packet data, such as nonce management, is handled directly by Endpoints.

LayerZero message packet. Design Patterns: LayerZero comes with a built-in set of design patterns, which can be thought of as omnichain building blocks. Developers building on LayerZero can use these design patterns to create almost anything they want. At the moment, there are four basic design patterns: AB: a one-way data transfer from source to destination.

ABA: a nested send call from Chain A to Chain B back to Chain A.

Composed AB: a message is transferred from Chain A to Chain B and calls an external contract on Chain B.

Composed ABA: moves data from source to destination, executes a contract call, and then sends it back to the source chain. (shown below.)

Composed ABC: moves data from source to destination, executes a contract call, and sends information to a third chain.

Batch Send: a single call that goes out to multiple destination chains.

While these design patterns may not seem like a big deal, design patterns are the legos for building omnichain applications and help developers create slick user experiences. For example, tokens can be bridged and swapped through a composed AB in a single transaction that only requires gas on the source chain.

Composed ABA design pattern. Infrastructure → The infrastructure layer of LayerZero is built to be permissionless: anybody can run the entities necessary to both verify and execute transactions. The infrastructure stack is also built to be completely modular — applications can choose what type of verification method it wants to use, along with what entities they want to pay for execution.

Decentralized Verifier Networks (DVNs): DVNs verify cross-chain messages. This permissionless role empowers any entity capable of verifying cross-chain data packets to join LayerZero as a DVN. Any native bridge, third-party bridge, middle chain, oracle, or other verification method may be used as a DVN inside V2, thereby avoiding vendor lock-in at the security level. As V2 has a modular design, application owners can combine DVNs to maximize verification for characteristics like security, cost, speed, or any parameter an application might want. Currently, 15+ DVNs are available, including DVNs run by Google Cloud and Polyhedra’s zklight client running DVNs and adapter DVNs for Axelar and CCIP. Again, as this is a permissionless role, any entity may set up a DVN and/or create an Adapter for a third-party bridge.

Where DVNs reside in the V2 architecture. Executors: Any entity can run an Executor, as it is an entirely permissionless role. The Executor ensures the smooth execution of a message on the destination chain by offering gas abstraction to the end-user. Executors do this by quoting end-users on the source chain in the source chain gas token while executing the transaction automatically on the destination chain. Much like applications can select a DVN set, they can also configure their application to choose a certain Executor or group of Executors. Applications also have the ability to build and run their own executor (as they can for DVNs) or operate without an Executor and have end-users manually invoke lzReceive via LayerZero Scan. Security Stack: An application’s “Security Stack” references its unique configuration of DVNs, Executors, and other security preferences (like what chains are enabled and how many block confirmations DVNs must wait to verify a message). The Security Stack enables “application-owned security” and differentiates LayerZero from many other interop solutions. Instead of locking developers into a single shared security model or a single set of validators, Security Stacks allow developers to select how their cross-chain messages are verified and change that configuration if a new DVN comes to market or a certain DVN hits liveness obstacles. V2 vs V1

The goal of V2 is not to completely overhaul a system. Instead, it is to take the V1 design and emphasize focus on the core principles of LayerZero: permissionless, censorship-resistant, and immutable.

The following five changes from V1 to V2 improve the developer experience and harden LayerZero’s core principles.

V2 vs V1 highlights:

Decoupling Execution from Verification: Previously, the Relayer was accountable for verification and execution. In V2, the Executor is separated from the verification process. Where the Relayer entity was a hypothetical bottleneck in V1 if it were to experience downtime (as of now, this has not been an issue), in V2, there will be no liveness issues. In V2, execution is a permissionless role outside the protocol and verification process. X of Y of N: This modular approach to verification empowers applications to neither overpay nor underpay for security, depending on their use case. X of Y of N allows applications to combine DVNs however they like. For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five to verify a message before moving on to execution. This means that if two DVNs outside the required DVN were unresponsive out of five, message flow could continue, greatly aiding liveness. (Editor’s note: The 2/2 multisig meme put forward around V1 by critics is wrong, as the Oracle is modular. However, with X of Y of N, that meme can be declared officially dead.) Horizontal Composability: Previously, applications were forced to compose omnichain transactions vertically, leading to transactions failing in their entirety if the final leg of a transaction failed. With horizontal composability, each leg of a transaction is saved locally on the destination chain. For example, only once the swap from source to destination is successful is the composed logic on the destination side executed (for example, logging the swap details on a separate contract). If that logging failed, it wouldn’t break the transaction, and the swap would still be successful, whereas the entire swap would have reverted with vertical composability. Unordered Delivery: Previously, all messages were verified and executed in order. V2 allows developers to choose whether to execute transactions in or out of order. With out-of-order transaction execution, LayerZero’s throughput matches the destination chain while maintaining censorship resistance. Enhanced Programmability: V2’s improved protocol contract interfaces, path-specific libraries, new design patterns, and horizontal composability redefine application interaction, fostering flexibility and uninterrupted cross-chain transactions. Let’s expand on X/Y/N and Security Stacks, as these are probably the most important concepts to understand when building on V2.

X of Y of N allows an application developer to designate a quorum of DVNs to check the integrity of a cross-chain message before signing off on a message’s validity. For example, “1 of 9 of 15” requires consensus from the following DVNs for a message to be verified:

9 from a selected pool of 15 DVNs, and 1 required DVN Regarding the required signer aspect of X of Y of N — this allows applications to harden their verification significantly by running their own DVN and requiring themselves to sign off on each transaction. That way, even if other DVNs collude to sign a malicious transaction, their application would be safe.

X of Y of N is the core of the Security Stack, allowing applications to select, combine, and/or remove DVNs to verify messages however they deem fit. This lets applications improve security as new verification methods enter the market or reconfigure DVNs if risks arise.

Security Stacks should generally be configured based on a project’s use case. For example, a cross-chain lending dApp may configure its Security Stack to the most decentralized set of DVNs possible and set a high number of blocks for confirmation, while a financial institution building an ecosystem of subnets may choose to run its own DVNs in its Security Stack with very minimal confirmation time. For inexpensive use cases or testing, developers can set a 1/1/1 quorum. However, if someone were to build an application that moved millions in value across chains sporadically, a quorum of 5/20/25 DVNs might be used.

Security Stack flexibility benefits the developer because it future-proofs an OApp by not locking it into a single verification method. If, for example, a DVN were to go down due to a hack or government subpoena, an OApp could change its Security Stack to require a signature from a different DVN.

Applications using LayerZero This unbiased stance on verification is a design choice that differs from most other messaging protocols, which often offer only a single security configuration. Outside of IBC, Hyperlane, and a few others… most cross-chain protocols adopt a shared approach to security, continually updating a single, monolithic end-to-end security model (like a validator set, oracle, middlechain, etc) to include new chains.

A one-size-fits-all approach to security will often lead to applications under or overpaying for security. For example, an omnichain NFT project has much lower security needs than an omnichain money market. However, if both are built on a middle-chain-enabled cross-chain protocol, they pay the same amount for security. In addition, using a single monolithic protocol leads to a one-size-fits-all approach to extensibility, as each verification method may only support a limited number of chains. With a modular set of DVNs, LayerZero allows developers to configure security parameters that best suit their application rather than forcing them to fit an application into a rigid, monolithic architecture.

Applications using a shared security model protocol. In building out Security Stacks, a diverse range of opinions is expected regarding the security of an application. There will be some proponents that say a Security Stack with just one DVN is enough (those would be developers currently building on single middle-chains), while others might say that anything less than a 1 required, 4/5 Security Stack is insecure. Whatever might be said, LayerZero protocol is unopinionated — it is only the transport layer and will stay verification agnostic.

With Security Stacks, LayerZero is the antithesis of vendor lock-in, as it allows developers to choose, modify, and combine different types of verification methods based on their specific use case.

V2 Transaction Lifecycle For this example, let us assume that an application (OApp) has configured its Security Stack on the LayerZero Endpoint for both the source and destination blockchains. It has also selected its preferred version of MessageLib.

LayerZero Tx Lifecycle Step 1a: Sending the Message

The source chain OApp calls lzSend on the source LayerZero Endpoint, providing the message payload and its unique path. The path is designed to be secure and resistant to censorship, constructed from the sender and recipient application addresses and their respective Endpoint IDs. Step 1b: Encoding and Emitting the Packet:

The source Endpoint assigns a unique, sequentially increasing nonce to the packet. It combines the nonce with the path to create a Global Unique Identifier (GUID) for tracking the packet. The Endpoint selects the correct source MessageLib (like ULN) based on the Security Stack to encode the packet. The packet is encoded with necessary information, including payment for DVNs to verify the message and Executors for triggering offchain actions. Step 2: Verification by DVNs:

Configured DVNs independently verify the packet on the destination side using the destination MessageLib. After the packet is verified by the sufficient number of DVNs required by the Security Stack, it is committed to the destination Endpoint by an appropriate worker (a DVN, executor, or user). Step 3: Receipt and Execution:

Endpoint ensures payload verification aligns with the OApp-configured Security Stack before committing to the channel. An executor invokes the lzReceive function to process the received packet with the Receiver OApp’s logic. This step ensures the message is delivered exactly once and without loss. If the system cannot guarantee this, the process is reverted to prevent any possibility of censorship. V2 Use Cases LayerZero is a big idea — anything that can be programmed as a smart contract on a single chain can now be natively programmed across multiple chains (which leads to far more expressive applications being built than what currently exists on the single-chain market).

Since inception, many products have been built on LayerZero, including borrow/lend dApps, cross-chain identity dApps, bridges, NFT marketplaces, enterprise projects, NFT projects, meme tokens, and data products. Over 40,000 OApp contracts are deployed on LayerZero V1, 100s of teams are using LayerZero to power OFTs, and dozens of teams have built full-scale applications as groupings of OApps.

For developers, LayerZero composability extends DeFi beyond single-chain limitations, paving the way for a more interconnected and versatile financial ecosystem. With LayerZero, the scope of applications built in DeFi expands as developers leverage more assets and blockchains. Furthermore, with the ability to run a DVN, application developers can harden security by decreasing reliance on other parties.

For users, V2 simplifies cross-chain transactions, allowing them to interact with multiple blockchains without even knowing — as they only have to pay for gas on the source chain. This streamlined experience can be adopted across every DeFi vertical — from DEXs to yield farms to NFT marketplaces — reducing the complexity for end-users. The endgame for retail DeFi is to completely abstract the chain away from users, and LayerZero OApp and OFT contracts are tools to facilitate this.

To give a concrete idea of what can be built with V2, here are a few examples of applications leveraging LayerZero V2…

Clusters (Identity): Clusters is a cross-chain, multi-wallet name service protocol addressing issues like address fragmentation, wallet management complexity, and domain squatting. It serves as a unified identity layer, enabling users to maintain a consistent identity across multiple chains — very similar to what ENS does, but for many chains, natively. Clusters ensures that actions and configurations associated with a user’s identity are consistently reflected across all integrated blockchains, thereby streamlining user interaction with various decentralized applications (dApps) and services. On the backend, LayerZero is used as the messaging layer to move actions and state changes across chains to help Clusters maintain accuracy across millions of names and billions of wallet addresses. (alpha 2.0.) Abracadabra (Stablecoin): Magic Internet Money (MIM) introduces an omnichain “beaming” service for transferring MIM tokens across 11 blockchains. Utilizing LayerZero’s Omnichain Fungible Token (OFT) standard, MIM beaming offers fast, secure, and efficient token transfers. This service extends MIM’s functionality, enabling cross-chain interactions like borrowing from different chains, executing cross-chain liquidations, and more. A nominal beaming fee of 1 USD, charged in the native gas token of the origin chain, contributes to DAO profitability. Abracadabra also runs its own DVN (MIMnet), which will be a required signer for MIM transfers once it transitions to V2. Since launching on V1, Abracadabra has facilitated two million transfers on LayerZero. Tapioca (Lending Market): Tapioca DAO is an omnichain lending & borrowing platform offering a native omnichain CDP stablecoin, USDO. The primary vision behind Tapioca is to reunify currently fragmented liquidity in DeFi by creating a natively omnichain borrowing, lending, and stablecoin protocol, where the user experience is identical to a user borrowing and lending on the same chain. Additionally, to complete the full finance stack, Tapioca users can employ cross-chain leverage with Tapioca through recursive messages. From a verification perspective, Tapioca operates a DVN that is a required signer in its own Security Stack. An example of this setup is shown below:

Tapioca’s V2 Security Stack V2 Trust Assumptions There is no such thing as a perfect system. Anybody claiming to have created something perfect in crypto should be met with scrutiny, as blockchains themselves are inherently limited to a core trade-off between speed, scale, and security.

This section discusses the trust assumptions, or security considerations, that a developer may encounter when building on top of LayerZero. Not all of these are protocol risks — many are practical risks that address social or application-level security. That being said, in good faith, we will address all types of trust assumptions here.

(Editor’s note: No pictures from here on out. Only niche interop analysis.)

Smart Contract Risk: Endpoints and MessageLibs are the basis for cross-chain communication for LayerZero. If these contracts contain a bug, then the core protocol is at risk.

This is the case with any protocol that utilizes smart contracts. While not a perfect measurement, looking at time-in-market for source code is usually a good indicator that a contract can be trusted. With that in mind, V1 Endpoints have been live for 1.5 years without error, facilitating over $40 billion in value transfer and over 100 million messages. With the launch of V2, these numbers are reset to existing V2 testnet volume and transactions, so it will take time to build the time-in-market trust back up, much like Uniswap upgrades take time to surpass their priors (Uniswap V2 trading quantity was higher than V3 for roughly six months). Of course, time-in-market is not the only metric for smart contract risk. Audits are also a good indicator. With V2, all contracts have been audited, and there is a $2.5 million bug bounty for whitehats. The V1 bug bounty of $15 million is currently the largest in the world. Malicious Developers: Developers are responsible for setting their own Security Stacks. This allows them to point to malicious DVNs and/or change a configuration at a whim if a governance or internal security process is not set up to prevent them from doing so.

Yes, developers can deploy or do malicious things on LayerZero. This is a byproduct of permissionless building and a tradeoff that’s well worth it. Ethereum, the internet, cash, etc., are all permissionless systems that allow people to do any number of things (both good and bad). To argue against this is to insult any developer’s intellect or free will. The argument that “devs can rug” is true for all applications built on permissionless blockchains. That being said, it is noted that best practice for developers is to be clear about their Security Stack and how it can be changed. For DAOs, a Security Stack could be selected and hardcoded via DAO vote, it could be time-locked and changed monthly, or a delegate could be charged with setting the Security Stack best suited to the DAO (with a time delay and with veto power from a security council). Similar setups can be used for businesses building on LayerZero. However, enterprise clients will likely want to run their own DVNs, so it should not be as big of an issue in that vertical. Diversity of DVNs: While the protocol is unopinionated, the DVNs verifying messages are not. Therefore, if there is a limited set of DVNs and applications choose to not run their own DVNs, then messages sent across the network might be censored in some way, similar to how some Ethereum validators do not include OFAC-sanctioned transactions.

A wide, varied group of DVNs is the goal for LayerZero. This diversity has multiple layers. DVNs should give developers a range of verification methods when building omnichain applications: bridges, oracles, chains, attestation services, restaking mechanisms, etc. For LayerZero to be a healthy protocol, a diverse group of entities needs to run DVNs: from enterprise solutions that connect to private chains to degenerate solutions that pick up any transaction in DeFi. On top of verification and entity diversification, it would also be nice to have a distributed set of DVNs running out of different jurisdictions to further harden the verification layer of LayerZero in the case of state-level attacks. At V2 launch, 15+ DVNs are live, from enterprises like Google Cloud to crypto-native solutions like Polyhedra zklightclient. This number should scale as V2 gains traction. With 60 chains and millions of messages to verify, more groups should be incentivized to run a DVN. DVNs and Good Faith Attestation: Similar to the above bullet, it must be noted that there is a trust assumption that DVNs will not collude.

LayerZero assumes developers will choose a Security Stack that minimizes collusion risk. LayerZero simply creates a marketplace for these ideas to be pitted against each other in terms of cost and security tradeoff (and application demand) — with the ultimate security of being able to run your own. For example, DVNs can have slashing mechanics and/or staking if it wants to, but LayerZero will not enforce this. Understanding why DVNs act in good faith can be broken into three arguments: 1) A good reputation is worth more than colluding to confirm a malicious transaction for enterprise DVNs. 2) Some DVNs already implement a transparent mechanism for incentivizing good behaviour (slashing, etc). 3) Fees make it worth running a DVN. On the reputation side, DVNs like Google Cloud, Animoca, Blockdaemon, and Gitcoin are likely too big, too ingrained in the broader crypto ecosystem and likely carry too much reputational risk to collude. On the transparency side, decentralized DVNs, like Axelar and CCIP, have their own validator sets that can be openly audited and checked — and also natively implement slashing to punish bad actors. On the fees side, with 50+ chains to service and historical message volume recently crossing 100,000,000, DVNs should be sufficiently incentivized to run just in terms of fees. Overall, protocols should look to use DVNs that will not collude. For example, a DVN setup of Google Cloud and Axelar is a very hard Security Stack, as it includes verification from a centralized and a decentralized entity, minimizing collision risk (and more DVNs can be added to this setup later on). Developers need to be careful in selecting their Security Stack, as it is possible that DVNs will attempt to collude at some point in the protocol’s future. Any application should consider collusion risk and plan accordingly by running their own DVN, reaching out to DVN teams to perform due diligence, and/or choosing a DVN combination where it is impossible to collude. Executor x Liveness: In theory, anybody may execute transactions in V2. Liveness should never be an issue, as an end-user or application can manually execute transactions on LayerZero Scan if the configured Executor goes offline. However, if, in practice, configured Executors go down frequently, there are short-term liveness concerns for applications building on LayerZero.

As already mentioned, permissionless execution should alleviate liveness concerns in theory. However, in practice, running an Executor is challenging work. As stated in the V2 launch video, running an automated executor requires billions of RPC calls per month and providing gas abstraction across 50+ chains, which in and of itself requires holding 50+ gas tokens and rebalancing those gas assets as needed. That said, an app can build and configure a smaller version of an Executor that runs across a limited chain pairing (e.g. Fantom <> Ethereum) — though even then, it is still complex to write due to re-orders, liveness, availability, resiliency against failures, race conditions, properly pricing gas cost, among other things. Overall, ensuring that multiple Executors are available is helpful for the protocol’s long-term liveness if an OApp’s selected Executor goes down. To that end, there are now open-source implementations of Executors available in our documentation. Defaults: When developers begin experimenting with LayerZero, they can opt into LayerZero Labs’ default Security Stack or set their own Security Stack. The default Security Stack is set by and can be changed by LayerZero Labs at any time. Any application that abdicates its security choice to LayerZero Labs’ defaults, therefore, abdicates its security to a centralized third party. The current default setting is Google Cloud and LayerZero Labs.

Defaults in and of themselves are not bad — it is very much like holding crypto on an exchange or custodian. This may be ideal for small applications or large enterprise solutions (as something like Coinbase is for new entrants and institutional holders of BTC). However, for crypto-native applications, opting into defaults is likely not ideal because if LayerZero Labs is hacked or turns malicious, then the default Security Stack could also be changed to be malicious. Defaults are intended for developers to test LayerZero. The end-game for most applications should be to configure their own Security Stack and not to use defaults in the first place — and/or for reputable orgs (like foundations or large applications) to publish their own ‘default’ settings for applications to use. Endpoint Deployments: LayerZero Labs is the only entity that can deploy canonical, socially accepted endpoints. If LayerZero Labs were to shut down, that would stop the current iteration of LayerZero from extending to new chains.

Since Endpoints are immutable, any Endpoint or MessageLib deployed will stay deployed and be active in perpetuity. Applications can build on this infrastructure forever, even if no new Endpoints are created. However, to expand to new networks in lieu of LayerZero Labs shutting down, some sort of workaround would need to be put into place. To clarify, other teams can deploy Endpoints — but they are not considered socially canonical, as they do not connect to other LayerZero Endpoints (breaking the whole interoperability thesis). However, if LayerZero Labs were to go down, another team could deploy Endpoints and attempt to garner social consensus for their own mesh. One solution often floated around would be allowing permissionless endpoint deployment. This, however, is a design decision that increases complexity, introduces spam risk, and will likely be very troublesome for DAO governance (in selecting canonical bridges for assets). LayerZero and the Market The cross-chain world is filled with bridges, liquidity networks, and token standards. Here’s a brief outline of where LayerZero fits.

Security Stacks: Bridges as DVNs Much like Bitcoin is built on the idea of self-custody (ownership over the security of your commodity), LayerZero is built on the idea of Security Stacks (ownership over the security of your application).

In V2, any entity that can verify a message — be it a native bridge, third-party bridge, validator set, oracle, multisig, light client, zk prover, etc. — may be used as a DVN by an application building on top of LayerZero.

This section of the article will make the case that many of the most popular third-party bridges are actually just decentralized verifier networks (DVNs) that can be used as Adapter DVNs built by application owners to verify messages in V2.

In other words, many existing bridges will likely end up as DVNs competing to verify messages inside LayerZero.

For more context, third-party bridges are cross-chain protocols competing against each other to build the most robust, industry-trusted mechanism for verifying messages between certain subsets of chains. Examples of third-party bridges include CelerIM, Axelar, deBridge, CCIP, Synapse, Wormhole, Router, IBC, etc. The designs for third-party bridges often revolve around shared security and can be generally bucketed into three categories. Middlechains like Axelar and Synapse validate messages as a hub and emit messages to spokes. There are guardian third-party bridges that attest to the validity of messages through reputational multi-sigs — like Wormhole and Avalanche Bridge. You can think of them as oracles or attestation services that sign off on cross-chain messages for a fee. The last type of third-party bridge is of a somewhat more vague bucket, which we call trust-minimized systems. These involve either zk proofs, light clients, or optimistic proofs, which can be boiled down to only having to trust one thing: math, chain consensus, and a single honest watcher, respectively.

No third-party bridge has quite cracked the code on the “best” form of security. Middlechains compete to build the most unhackable hubs. Guardians compete to bring in the most reputable players in crypto to attest to cross-chain transactions. Trust-minimized systems use the finest tools that math, blockchains, and game theory have to offer.

While each of these entities can send/receive arbitrary data across chains, that is not what third-party bridges are exceptional at. These third-party bridges are actually excellent at verification — at proving that this message happened over here and can be sent over there.

With the new V2 design, these third-party bridges, as DVNs, get to focus on what they do best — signing off on valid cross-chain transactions — and applications select the third-party bridges they want based on use-case preferences. This design should be a win-win, as third-party bridge designers no longer need to worry about execution and/or transmission of cross-chain messaging, and applications are no longer locked into a single verification method when building something that exists on multiple blockchains.

By allowing third-party bridges to do what they do best (verify things), LayerZero can focus on the main idea: unified semantics — allowing developers to compose contracts in the same way, regardless of chain. Every data packet sent and every endpoint interacted with on the LayerZero protocol is identical. LayerZero is built to allow developers to pick and choose from every type of verification method available on the market. It is a permissionless, censorship-resistant, and immutable structure that can be filled with any type (or combination) of verification method. This is powerful, as it future-proofs LayerZero against advancements in verification techniques while allowing for universal blockchain composability through a standardized messaging design.

One Messaging Layer, Many Liquidity Networks Any type of liquidity network can be recreated on LayerZero.

Another bucket of “bridges” are cross-chain protocols that allow for the transfer of tokens across chains. These are called liquidity networks. Examples include Across, Hop, Portal, Connext, Stargate, Allbridge, DLN, UniswapX, Hyphen, Catalyst, and cBridge, among others. Most liquidity networks are designed around a basic intent structure: a user has asset X on Chain A and wants asset X on Chain B. A liquidity network matches an intent with a solving mechanism that is either onchain (liquidity pools/wrapped assets), offchain (often dubbed relayers), or a mixture of both. These solving mechanisms essentially take the user’s token on Chain A and unlock/fill the same amount of tokens on Chain B. They charge a small fee for this service. The competition amongst liquidity networks can be found in bridge price execution, fees, number of tokens offered to users, and transfer time.

Something interesting about liquidity networks is that the verification method used underneath the liquidity network is somewhat arbitrary. Like how multiple AMMs can be built on top of Ethereum, many liquidity networks can technically be built on the same verification network. UniswapX emphasizes this point — it spent an entire whitepaper only talking about the liquidity aspects of the protocol (fillers, dutch-auction, optimistic execution, etc.) while not naming the underlying verification network it might use! All the whitepaper says is that a “settlement oracle” is necessary, which could be “a canonical bridge… light client bridge, or a third party bridge.” Anything passing a message between chains can be the settlement oracle here! This character trait is not unique to UniswapX. Other liquidity network designs like DLN and cBridge and Wormhole’s Portal and Catalyst could likely use other third-party bridges (aka DVNs) for settlement.

What these liquidity networks need is not necessarily a single third-party bridge — rather, they need a verification method they can trust depending on the chain pairing and use case. With V2, LayerZero could theoretically support each liquidity network for messaging (settlement) while allowing them to choose unique verification methods (Security Stacks).

LayerZero V2 offers a single messaging framework for many different types of liquidity networks to be built using different Security Stack configurations. This broadens the scope of what can be made and should result in fun experimentation. For example, a cross-chain AMM might select a Security Stack based on trade size, with the idea that different trade volumes will be settled by different Security Stacks (essentially bridge aggregation through Security Stack optionality).

Universal Contract Standards The modular blockchain thesis, the L2 scaling thesis, the omnichain thesis — all of these ideas require universal token and contract standards so that the world of 1000s of chains can operate without fragmentation and context switching depending on each new chain/asset/VM pairing. Omnichain Fungible Tokens (OFTs) and Omnichain Applications (OApps) aim to be those standards — extending developer capability without compromising security.

OFTs extend traditional token standards like ERC-20, empowering developers to create tokens that operate seamlessly across multiple blockchains. This universality eliminates silos, enabling tokens to move between chains. The potential adoption of OFTs as a standard means that developers no longer need to deploy separate, chain-specific tokens, which can divide liquidity and community while introducing different trust assumptions. Instead, OFTs offer a unified token presence across all LayerZero-supported blockchains, ensuring that token ecosystems remain cohesive and robust, regardless of the chain. OFTs work across multiple token standards (ERC20 being the most popular), add no fees outside those tacked on by applications, and allow for a universal supply to be tracked at all times (transparency). As with applications, OFT token issuers maintain complete control over their contracts and Security Stacks. (Note: ONFTs will also be live on V2 but are now in beta due to contracts being audited. The same logic for OFTs can be easily extended to ONFTs.)

Bonus photo showcasing an OFT tx. The omnichain applications (OApp) contract standard provides a universal, blockchain-agnostic developer interface. With OApps, developers can now build an application once and deploy it across any number of chains without rewriting code. This cuts development time and opens up the entire blockchain ecosystem to their application rather than a fraction of it. This also allows developers to access the combined users and liquidity of any LayerZero-supported blockchain. In addition, multiple OApps can be combined, creating genuine full-stack, cross-chain financial applications (imagine a DeFi app that allows for borrowing on any chain, swapping on any chain, etc.). With V2, LayerZero should have a good chance of becoming the single framework for cross-chain tokens and governance, as it offers a universal messaging solution with a modular verification layer.

In other words, a token or governance setup can use ANY type of verification method — or combination of verification methods — to move data to a destination chain using V2, with the only trust assumption being the sanctity of LayerZero Endpoints (a trust assumption that cannot be escaped with any other solution, either).

Overall, the case can — and maybe should — be made that OFTs and OApps become the de facto contract standards for all tokens and contracts moving forward for teams building on LayerZero-supported chains. Here are a few reasons why:

Interoperability by Default: OFTs and OApps are built for a multi-chain world. They inherently adopt cross-chain communication, making them future-proof as crypto continues to evolve into an industry with 1000s of chains. Adopting these standards allows projects to plan for years instead of months. Modular Security: Both OFTs and OApps benefit from LayerZero’s modular security framework, which enables application-specific customization of security parameters. This means developers are not forced into a one-size-fits-all security model but can tailor security to the unique needs of their application or token, enhancing both flexibility and resilience. Simplicity and User Experience: For users, the complexity of blockchain interactions fades into the background with OFTs and OApps. They offer a simplified, consistent user experience that abstracts away the technicalities of chain-specific operations. Universal Composability: There are many cross-chain contract standards on the market. Solidifying OFT and OApp as industry norms increases composability while decreasing fragmentation — without locking protocols into a single security strategy. Conclusion LayerZero’s architecture — modular at the verification level while static at the transport layer — strikes a crucial balance of current performance and future-proofed design.

The technology is here for us to build an open and just digital economy for all people, for all time. As an industry, crypto has to work together to bring that vision to fruition. By nature of that shared goal, our technologies must be permissionless.

For that vision to succeed, this philosophy must be upheld at every level of the stack. LayerZero defends these values down to the packet level.

When features are mutable, values can always be changed. Promises aren’t permanent. Decisions aren’t durable. Upgrades are risks. Eventually, systems are corrupted.

Permanence and provability must be hard coded.

That’s why LayerZero is here. That’s why LayerZero exists.

LayerZero is built so you don’t have to trust others. It’s built so you can trust yourself.

Thanks for reading. A big shout out to Tapioca Matt, Paladin Marco, LI.FI Arjun, Sandman, Catalyst Jim, and BlockWorks Ren for feedback on this piece. Handshakes all around to the LZ team as well, especially BP, MP, and RMT.

Contact For more information on V2, check out this thread, read this article, or check out our docs.

To learn more about LayerZero in general, check out the website. For additional information, the LayerZero Labs team is available to answer general questions on Discord and Telegram. You can also follow LayerZero Labs on X to receive the most up-to-date information.

For specific inquiries:

Infrastructure providers looking to run an Executor DVN should fill out this form! Developers looking to build an OApp or OFT should fill out this form!

Twitter Website Discord Medium. Telegram

V2 Highlights

• Universal Messaging: Any type of message can be sent and composed between chains, including arbitrary data, external function calls, and/or tokens.

• Modular Security: Developers may choose from their preferred combination of 20+ Decentralized Verifier Networks (DVNs) when selecting a Security Stack to verify cross-chain messages.

• Permissionless Execution: Anybody may run an Executor in V2. Information on how to run your own Executor is available here.

• Unified Semantics: OApp and OFT contracts enable developers to build applications and tokens that work the same across every blockchain V2 has an endpoint on.

• V1 Compatibility: ​​Migration options exist for V1 applications. If already deployed on V1, applications can utilize the new security and execution model via ULN 301. More information can be found here.

For more detailed information on V2, check out the V2 launch video, the V2 Whitepaper, and V2 Developer Documentation. Audit reports for V2 are also available here.

About LayerZero

LayerZero is a permissionless, censorship-resistant, and immutable protocol that connects blockchains. Using LayerZero, developers can send arbitrary messages across chains while preserving full control over their application’s security. LayerZero enables developers to create, configure, and compose unified applications, tokens, and data primitives across many chains.

Anything that can be programmed as a smart contract on a single chain can be natively programmed across multiple chains via LayerZero. Since its inception, Over 40,000 OApp contracts have been deployed on LayerZero, 100s of teams use LayerZero’s OFT Standard to power tokens, and dozens of teams have built full-scale applications as groupings of OApps. These products include lending markets, stablecoins, bridges, enterprise projects, NFTs, meme tokens, and identity solutions.

Contact

To learn more about LayerZero, check out the website. For additional information, the LayerZero Labs team is available to answer general questions on Discord and Telegram. You can also follow LayerZero Labs on X to receive the most up-to-date information.

For specific inquiries:

• Infrastructure providers looking to run an Executor DVN should fill out this form!

• Developers looking to build an OApp or OFT should fill out this form!

Twitter Website Discord Medium. Telegram

LayerZero enables developers to create and configure unified applications, tokens, and data primitives — regardless of chain — through the transmission of arbitrary messages.

Like TCP/IP standardized internet development, LayerZero’s goal is to standardize application development across all chains. This concept of unified cross-chain development is encapsulated in the word “omnichain” and is how LayerZero envisions the future of crypto.

LayerZero is a protocol designed to connect blockchains while upholding the following fundamental principles:

• Permissionless: Anyone may run the infrastructure necessary to verify and execute messages. Anyone can build on and interact with LayerZero.

• Censorship resistant: No individual message can be executed until all previous messages have been verified, meaning no individual message can ever be censored on any pathway.

• Immutable: Endpoints on each chain exist in the form of smart contracts. New verification libraries can be added as append-only updates. These are non-upgradeable and will exist in perpetuity.

LayerZero V2 TL;DR

Today marks the deployment of LayerZero V2 on 40+ testnets and the introduction of the V2 technical whitepaper. V2 creates an omnichain network of blockchains for developers to build universal applications.

The upgrade introduces key features:

• Decentralized Verification Networks (DVNs): Replacing the V1 Oracle, this permissionless role empowers any entity capable of verifying cross-chain data packets to join LayerZero as a DVN.

• Adapters: Axelar and CCIP DVN adapters will be available today on testnet and when mainnet launches. Other adapters planned for 2024 will allow developers to integrate any type of native bridge, third-party bridge, middle chain, oracle, or other verification methods into LayerZero, thereby avoiding vendor lock-in at the security level.

• X of Y of N: This is a modular approach to verification empowering applications to neither overpay nor underpay for security depending on use case. X of Y of N allows applications to combine DVNs however they like. For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five that must verify a message for cross-chain execution.

• Permissionless Execution: Replacing the Relayer and separating execution from verification, LayerZero V2 introduces Executors — a permissionless role that facilitates smooth execution on the destination chain, simplifies gas payments, and offers customizable gas settings.

• Security Stack: Each Omnichain Application (OApp) must configure a Security Stack comprising DVNs, Executor(s), chain confirmations, MessageLibraries, and chain pathways for omnichain messaging. This setup grants applications complete control over security. With V2, are opt-in, with the recommendation being that OApp developers set their own Security Stack.

• Increased Throughput: By providing the option for lazy nonce enforcement or strict nonce enforcement, V2 allows developers to choose whether they want to execute transactions in order or out of order. With out-of-order transaction execution, LayerZero’s throughput matches that of the destination chain while maintaining censorship resistance.

• Enhanced Programmability: V2’s improved protocol contract interfaces, path-specific libraries, new design patterns, and horizontal composability redefine application interaction, fostering flexibility and uninterrupted cross-chain transactions.

• Unified Semantics: V2 enables developers to build applications that work the same across every blockchain LayerZero has an endpoint on — including non-EVM chains.

• V1 Compatability: ​​For teams building on V1, the V2 launch will allow for both forward and backward compatibility.

All told, with the launch of V2, LayerZero aims to embed itself as a crypto primitive on par with Bitcoin and Ethereum. Bitcoin as the protocol for crypto money, Ethereum as the protocol for crypto finance, and LayerZero as the protocol for crypto internet.

With DVNs and Adapters, LayerZero V2 sits at the transport layer of the blockchain economy, whereas other “cross-chain” solutions battle for the right to verify messages. LayerZero can now act as a quasi-aggregator of verification methods. Any type of verification method — be it bridge, oracle, attestation service, or a blockchain itself — can be plugged into V2 as a DVN. Application owners building on LayerZero may configure DVNs based on their project’s use case.

For example, application developers can opt to verify messages through shared-security adapters like Axelar and CCIP or go with enterprise signers like Blockdaemon and Google Cloud — or a combination of all four. And, most importantly, this decision is not set in stone, as the Security Stack configuration can be changed by the application owner (or a delegate) if a DAO or business decides to do so. Independent DVNs confirmed at testnet launch will include entities run by Blockdaemon, Google Cloud, Animoca, Delegate, Gitcoin, Nethermind, P2P, StableLab, Switchboard, Tapioca, LayerZero Labs, and Polyhedra. The number of DVNs should increase as mainnet approaches — with 50+ chains to support, there is a need for many DVNs.

Permissionless execution and lazy nonce-enforcement improve both liveness and throughput properties. Liveness concerns are minimized since anyone (third-party executor, application, end-user) may now execute transactions. Throughput is maximized to align with that of the destination chain. In addition, the protocol itself is easier to build on, with new design patterns available for developers to send, receive, and compose messages across chains. Furthermore, the core protocol is built in such a way that extending to new chains — even non-EVM chains — can be done without changing how messages are sent.

V2 Launch Details

LayerZero V2 endpoint contracts are deployed on 40+ testnets starting today, with the goal being to give developers time to experiment with new Security Stacks and Endpoints before going live on mainnet.

• You can read the whitepaper here.

• You can read the developer docs here.

Mainnet launch is targeted for January 2024. The launch will include V2 endpoints on each chain that V1 supports. All Omnichain contract standards — OApp, OFT, and ONFT — will be available by mainnet launch. On testnet, only OApp and OFT will be available.

Mainnet launch will include support from the following infrastructure entities:

• DVNs: Instructions on how to run a DVN are available in the LayerZero documentation. Read more here. In addition, Animoca, Blockdaemon, Delegate, Gitcoin, Nethermind, Obol, P2P, StableLab, Switchboard, Tapioca, Polyhedra, LayerZero Labs, and Google Cloud will run DVNs on testnet. Adapters for Axelar and CCIP will also be available for testnet and mainnet launch, with more coming soon.

• Executors: Instructions on how to spin up an Executor are available in LayerZero documentation. Read more here. In addition, LayerZero Labs will offer third-party execution options for dApps. LayerZero Scan will also have a tab available for end-user execution.

Reach Out With Any Questions

For teams building on V1, the V2 launch will allow for both forward and backward compatibility. You can find migration information specifically inside our documentation. It is important to note that V1 is still in production and will continue to be in production in perpetuity. As of now, V2 brings no breaking changes to V1 (this might change when V2 endpoints extend to new chains).

As mainnet launch approaches, we will continue to update our documentation with any changes and publish educational resources to make the transition from V1 to V2 as smooth as possible.

If you are planning on building on V2, have questions about migrating from V1, or something in between, please join our Discord.

Twitter Website Discord Medium. Telegram

The original Colored Coin algorithm aimed to solve this through a lossless metadata layer on top of the bitcoin ledger, but more generally in EVM would be akin to keeping an infinitely large ledger list of every address of every possible colorer and their current balance per wallet. This is intractable in both storage and compute and, as such, has never been viable to implement- leaving there few good avenues for accurate onchain value attribution.

Introducing ColorTrace.

For a practical example of ColorTrace, we’ll walk through the implementation used by USDV in their recent launch of the stablecoin.

The problem to be solved was that much of the value of existing stablecoins were driven by the market participants themselves. Groups like Uniswap, Curve, Coinbase, and Binance have moved trillions of dollars of stablecoins and given immense utility to their underlying ecosystems and yet only one of those has ever been directly rewarded for it. Circle entered into a custom agreement with Coinbase to share the yield of USDC based on Coinbase’s contributions to the success of USDC. For this Coinbase currently earns almost $1B per year. The simple solution would be to create similar deals with all other major parties, but this is where the tricky part comes in. Imagine a world today where $24B of USDC sits in circulation, with the majority in EOAs. How much yield goes to each party? For the balance sitting in Uniswap, Curve, Coinbase, and Binance it’s easy to see how much each party has contributed, but for the more than $10B+ sitting in user wallets and EOAs it’s hard to know how much each group has contributed to that.

This is where onchain value attribution comes in. ColorTrace unlocks the ability for each entity to receive pro-rata attribution for the value they have created for the underlying ecosystem. In the case of USDV, this means that each token an entity has minted into circulation will be marked with their color and be attributed to them until it is redeemed for the underlying asset — a true onchain meritocracy.

Extending beyond USDV, ColorTrace can be used for things like onchain ref links, affiliate programs, and really any use-case that allows for protocols to reward participants fairly for any value accretive action.

For a deeper look at the design of ColorTrace and the other algorithms created along the way, read Solving Fungible Token Coloring — A Nerds Version

Twitter Website Discord Medium. Telegram