# Silicon

Welcome to the Silicon Docs

> **Silicon Network is scheduled to discontinue its service. Please see the following link for more details.** [\[Important\] Service Termination](/important-service-termination)

<figure><picture><source srcset="/files/MpopawyaxlM8kv3kucAG" media="(prefers-color-scheme: dark)"><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FDiPzVWHDm64zcZF4xmdm%2Fimage.png?alt=media&amp;token=9e37ef42-f01e-4bc4-8f6d-6a359ef617b2" alt="Silicon Docs Logo" width="375"></picture><figcaption><p>Welcome to the Silicon Docs</p></figcaption></figure>

## Discover Silicon

<table data-view="cards" data-full-width="false"><thead><tr><th data-card-target data-type="content-ref"></th><th></th><th data-hidden></th><th data-hidden data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><a href="/about/overview">Silicon Overview</a></td><td>Learn more about Silicon.</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FwgxzP59Fsy6SLRlt4KBl%2Fimage.png?alt=media&amp;token=b6186cbe-a495-4525-b23f-497ee1c13724">image.png</a></td></tr><tr><td><a href="/user-guide/wallet-configuration">Users</a></td><td>Basic setup and usage guide for Silicon</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F6tdrdjqIsCgMilIvnDsl%2Fimage.png?alt=media&amp;token=9cf70d2d-a95f-460e-8e82-4f68f25ec4b0">image.png</a></td></tr><tr><td><a href="/builders/build">Builders</a></td><td>Silicon ecosystem build guide for Builders.</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F8pgLTyS9iB09bLTRr2Pp%2Fimage.png?alt=media&amp;token=fb700af3-d9c0-48ed-8a82-a76e6f0d5109">image.png</a></td></tr><tr><td><a href="/more/brand">More</a></td><td>Brand kit, security, terms, etcs.</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fp7l8IRQgPhToP13PxICl%2Fimage.png?alt=media&amp;token=8d3f79d7-50eb-4a6e-a04f-5000a4c3123e">image.png</a></td></tr><tr><td><a href="/support/contact">Contact Silicon</a></td><td>Business inquiries, user support, and bug reports.</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FQJ7BAfz1PYuxC1W7o0eP%2Fimage.png?alt=media&amp;token=abe224cc-0f7a-44ee-a27b-616f667cbd2e">image.png</a></td></tr></tbody></table>

## Popular Guide

{% content-ref url="/pages/7RMsrsCNTQx8l21Alcgh" %}
[Wallet configuration](/user-guide/wallet-configuration)
{% endcontent-ref %}

{% content-ref url="/pages/1TnuPsCYJyPHBa7xQdA0" %}
[Deposit to Silicon](/user-guide/bridge/deposit)
{% endcontent-ref %}

{% content-ref url="/pages/BoUT0WD9FaWopq3SltCo" %}
[Withdrawal from Silicon](/user-guide/bridge/withdrawal)
{% endcontent-ref %}

## Popular Resources

{% content-ref url="/pages/3c3bDz9mf5qRBJ2eV5He" %}
[Bridge](/user-guide/bridge)
{% endcontent-ref %}

{% content-ref url="/pages/8nfLjgkHdn8jDwhdFas2" %}
[Block explorer](/user-guide/block-explorer)
{% endcontent-ref %}

{% content-ref url="/pages/BHy2172jvqpKhbMqmM1K" %}
[Brand](/more/brand)
{% endcontent-ref %}

## Join the Silicon Community!

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden></th></tr></thead><tbody><tr><td><strong>Telegram</strong></td><td><a href="https://t.me/groupsilicon">https://t.me/groupsilicon</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F9IgAaTgln8Oeweho1Ezv%2Fimage.png?alt=media&amp;token=03d7527f-159f-42f3-8d2a-13345fc0ab8b">image.png</a></td><td></td></tr><tr><td><strong>X</strong></td><td><a href="https://x.com/0xSilicon">https://x.com/0xSilicon</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FZBDECV6wIYsVOK3rhyPY%2Fimage.png?alt=media&amp;token=413f005c-eac1-43c5-9a6c-70d2b14b66b7">image.png</a></td><td></td></tr><tr><td><strong>Medium</strong></td><td><a href="https://medium.com/@0xSilicon">https://medium.com/@0xSilicon</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FYq1kZeJyxYh8Jm82XZax%2Fimage.png?alt=media&amp;token=08467c45-4796-4d7a-b9cd-920828852bd0">image.png</a></td><td></td></tr></tbody></table>

{% hint style="warning" %}
Silicon uses **Ether (ETH)** as its native network currency and has <mark style="color:red;">**never issued or distributed its own token.**</mark> Please be cautious of impersonations or scams using similar names.
{% endhint %}


# \[Important] Service Termination

Silicon Network is scheduled to discontinue its service. Please refer to the document below for more details.

한국어 버전은 아래에 있습니다. Korean version is available below.

## English

### **Notice of Silicon Network Service Termination**

**Dear Silicon Network Community,**

**We would like to thank everyone who has used Silicon Network. We are writing to inform you that Silicon Network will cease operations according to the schedule below.**

**This network is a non-custodial service, meaning that the custody and withdrawal of assets are managed directly by each user. Once the service has been terminated, assets that have not been withdrawn cannot be recovered. Please be sure to review and handle your holdings within the withdrawal support period.**

#### **Key Dates**

* #### September 2, 2026 (Wednesday) (as of this notice): Silicon L2 bridge deposits discontinued / Testnet shut down
* #### September 2, 2026 – December 31, 2026 (Thursday), 12:00 (UTC+9): User asset withdrawal support period
* #### After December 31, 2026 (Thursday), 12:00 (UTC+9): Explorer shutdown / Network termination begins

#### \*As of this notice, the new deposit (bridge) function into Silicon Network is no longer available on the website or in wallet screens. Please do not make any further deposits.

#### **Guidance by Asset Type**

**1. Assets bridged from Ethereum** You may withdraw these from Silicon Network to Ethereum Mainnet during the withdrawal support period.

* Korbit Web3 Wallet users: Follow the Korbit withdrawal procedure \[[Korbit Guide](https://www.korbit.co.kr/notice/detail/?noticeId=1tQ0pIfxoFFITH6GELPhFj)]
* External wallet (MetaMask, etc.) users: Withdraw to Ethereum Mainnet via the bridge \[[External Wallet Withdrawal Guide](https://docs.silicon.network/user-guide/bridge/withdrawal)]
* Gas fees (ETH) are required for withdrawal, so please keep a small amount of ETH on hand.

**2. Tokens issued within the network**

* Tokens issued within the network cannot be withdrawn (bridged) directly to Ethereum.
* Such tokens depend on liquidity within the network, and withdrawal or swapping may be difficult or impossible due to insufficient liquidity or other factors.
* Whether and how to handle these tokens is a decision to be made at the user's own discretion and responsibility. Once the network has been fully terminated, recovery will not be possible.

#### **Important Notices**

* This network is a non-custodial service. Silicon Network provides the technical environment and guidance for users to withdraw and handle their assets directly, but bears no obligation regarding the withdrawability of individual assets, any guarantee of value, or any duty of redemption. Reviewing and handling assets is done at the user's own responsibility.
* **No recovery of un-withdrawn assets**: Once the withdrawal support period (through December 31, 2026 (Thursday), 12:00 (UTC+9)) ends and the network is terminated, assets that have not been withdrawn regrettably cannot be recovered. Please be sure to review and handle your holdings within the period.
* **Tokens issued within the network**: Tokens issued within the network cannot be withdrawn (bridged) directly to Ethereum, and withdrawal or swapping may be difficult or impossible due to insufficient liquidity or other factors. Whether and how to handle these tokens is a decision to be made at the user's own discretion and responsibility.
* **Gas fees borne by the user**: Network fees (gas) incurred when withdrawing or swapping assets are the user's responsibility. Please keep a small amount of ETH on hand for withdrawals.
* **New deposit (bridge) function disabled**: As of this notice, the new deposit (bridge) function into Silicon Network is no longer available on the website or in wallet screens. Regardless of what is shown on screen, assets sent or deposited to Silicon Network after this notice may not be processed properly and may be impossible to withdraw or recover, and responsibility for this rests with the user. Please do not make any further deposits.
* **Caution regarding erroneous transfers**: When withdrawing to an external wallet, the user is responsible for verifying the accuracy of the address entered. Silicon Network bears no responsibility for asset losses arising from user error, such as entering an incorrect address.
* **Investment and price risk**: Virtual assets may be subject to sharp price fluctuations, and responsibility for any losses arising from the exchange or handling of assets rests with the user.
* **Non-custodial nature of the service**: This network is a non-custodial service. Silicon Network provides the technical environment and guidance for users to withdraw and handle their assets directly, but bears no obligation regarding the withdrawability of individual assets, any guarantee of value, or any duty of redemption. Reviewing and handling assets is done at the user's own responsibility.
* **Method of notice**: As this is a non-custodial service, notices are provided through Silicon Network's official channels rather than by individual notification. Please check the official channels periodically during the withdrawal support period. This termination is being carried out with advance notice in accordance with the Silicon Network Terms of Use.

#### **Method of Notice and Inquiries**

As this is a non-custodial service, termination and other major changes are announced **through Silicon Network's official channels** rather than by individual notification. Please check the official channels periodically during the withdrawal support period.

This termination is being carried out with advance notice in accordance with the Silicon Network \[[Terms of Use](https://docs.silicon.network/more/terms)].

For detailed guidance on withdrawal methods and more, please refer to the \[[Korbit Withdrawal Guide](https://www.korbit.co.kr/notice/detail/?noticeId=1tQ0pIfxoFFITH6GELPhFj)] and the \[[External Wallet Withdrawal Guide](https://docs.silicon.network/user-guide/bridge/withdrawal)].

After the network is terminated, inquiries regarding Silicon Network and guidance on asset-related matters will be transferred to Ozys.

Inquiries: <support@silicon.network>

Thank you for using Silicon Network.

## 한국어(Korean)

### **실리콘 네트워크(Silicon Network) 서비스 종료 안내**

안녕하세요. 실리콘 네트워크(Silicon Network)입니다.

그동안 실리콘 네트워크를 이용해 주신 모든 분들께 감사드립니다. 실리콘 네트워크의 운영을 아래 일정에 따라 종료하게 되어 안내드립니다.

본 네트워크는 비수탁형(Non-custodial) 서비스로, 자산의 보관 및 출금은 이용자 본인이 직접 관리 진행합니다. 서비스 종료 후에는 출금되지 않은 자산의 복구가 불가능하므로, 반드시 출금 지원 기간 내에 보유 자산을 확인하고 처리해 주시기 바랍니다.

#### **주요 일정**

* #### 2026년 9월 02일 (수요일) (공지시점): 실리콘 L2 브릿지 입금 지원 종료 / 테스트넷 종료
* #### 2026년 09월 02일 \~ 2026년 12월 31일(목요일) 12:00 (UTC+9): 이용자 자산 출금 지원 기간
* #### 2026년 12월 31일(목요일) 12:00 (UTC+9) 이후: 익스플로러(Explorer) 종료 / 네트워크 종료 진행

#### \*본 공지 시점부터 실리콘 네트워크로의 신규 입금(브릿지) 기능은 사이트 및 지갑 화면에서 제공되지 않습니다. 추가 입금을 진행하지 말아 주시기 바랍니다.

#### **자산별 안내**

**1. 이더리움에서 브릿지된 자산**\
출금 지원 기간 내에 실리콘 네트워크에서 이더리움 메인넷으로 출금하실 수 있습니다.

* 코빗 Web3 지갑 이용자: 코빗 출금 절차에 따라 진행 \[[코빗 가이드 링크](https://www.korbit.co.kr/notice/detail/?noticeId=1tQ0pIfxoFFITH6GELPhFj)]
* 외부 지갑(메타마스크 등) 이용자: 브릿지를 통해 이더리움 메인넷으로 출금 \[[외부 지갑 출금 가이드 링크](https://docs.silicon.network/user-guide/bridge/withdrawal)]
* 출금 시 가스비(ETH)가 필요하니 소량의 ETH를 남겨두시기 바랍니다.

**2. 네트워크 내에서 발행된 토큰**

* 네트워크 내에서 발행된 토큰은 이더리움으로 직접 출금(브릿지)이 불가능합니다.
* 이러한 토큰은 네트워크 내 유동성에 의존하며, 유동성 부족 등으로 출금 혹은 교환이 어렵거나 불가능할 수 있습니다.
* 해당 토큰의 처리 여부 및 방법은 이용자 본인의 판단과 책임 하에 결정하시기 바라며, 네트워크의 완전 종료 후에는 복구가 불가능합니다.

#### **유의사항**

* 본 네트워크는 비수탁형 서비스로, 실리콘 네트워크는 이용자가 자산을 직접 출금하거나 처리할 수 있는 기술적 환경과 안내를 제공하나, 개별 자산의 출금 가능 여부, 가치 보장 또는 상환 의무를 부담하지 않습니다. 자산의 확인 및 처리는 이용자 본인의 책임 하에 진행됩니다.
* **미출금 자산 복구 불가**: 출금 지원 기간(\~2026년 12월 31일 12:00(KST)) 종료 후 네트워크가 종료되면, 출금되지 않은 자산은 부득이하게 복구할 수 없습니다. 반드시 기간 내에 보유 자산을 확인하고 처리해 주시기 바랍니다.
* **네트워크 내 발행 토큰**: 네트워크 내에서 발행된 토큰은 이더리움으로 직접 출금(브릿지)이 불가능하며, 유동성 부족 등으로 출금·교환이 어렵거나 불가능할 수 있습니다. 해당 토큰의 처리 여부 및 방법은 이용자 본인의 판단과 책임 하에 결정하시기 바랍니다.
* **가스비 이용자 부담**: 자산 출금·교환 시 발생하는 네트워크 수수료(가스비)는 이용자 부담이며, 출금을 위해 소량의 ETH를 남겨두시기 바랍니다.
* **신규 입금(브릿지) 기능 비활성화**: 본 공지 시점부터 실리콘 네트워크로의 신규 입금(브릿지) 기능 은 사이트 및 지갑 화면에서 제공되지 않습니다. 화면상 노출 여부와 관계없이 공지 이후 실리콘 네트워크로 전송·입금된 자산은 정상적으로 처리되지 않거나 출금·복구가 불가능할 수 있으며, 이에 대한 책임은 이용자 본인에게 있습니다. 추가 입금을 진행하지 말아 주시기 바랍니다.
* **착오 전송 주의**: 외부 지갑으로 출금 시 입력하신 주소의 정확성은 이용자 본인이 확인하셔야 하며, 잘못된 주소 입력 등 이용자 착오로 발생한 자산 손실에 대해 실리콘 네트워크는 책임지지 않습니다.
* **투자·시세 위험**: 가상자산은 급격한 시세 변동에 노출될 수 있으며, 자산의 교환·처리에 따른 손실의 책임은 이용자 본인에게 귀속됩니다.
* **비수탁형 서비스 성격**: 본 네트워크는 비수탁형(Non-custodial) 서비스로, 실리콘 네트워크는 이용자가 자산을 직접 출금·처리할 수 있는 기술적 환경과 안내를 제공하나, 개별 자산의 출금 가능 여부·가치 보장 또는 상환 의무를 부담하지 않습니다. 자산의 확인 및 처리는 이용자 본인의 책임 하에 진행됩니다.
* **공지 방식**: 본 서비스는 비수탁형으로 개별 통지 대신 실리콘 네트워크 공식 채널을 통해 공지됩니다. 이용자께서는 출금 지원 기간 동안 공식 채널을 주기적으로 확인해 주시기 바랍니다. 본 종료는 실리콘 네트워크 서비스 약관(Terms of Use)에 따라 사전 공지 후 진행됩니다.

#### **공지 방식 및 문의**

본 서비스는 비수탁형으로, 종료 및 주요 변경 사항은 개별 통지 대신 **실리콘 네트워크 공식 채널을 통해 공지**됩니다. 이용자께서는 출금 지원 기간 동안 공식 채널을 주기적으로 확인해 주시기 바랍니다.

본 종료는 실리콘 네트워크 서비스 약관([Terms of Use)](https://docs.silicon.network/more/terms)에 따라 사전 공지 후 진행됩니다.

출금 방법 등 자세한 안내는 \[[코빗 출금 가이드](https://www.korbit.co.kr/notice/detail/?noticeId=1tQ0pIfxoFFITH6GELPhFj)] 및 \[[외부 지갑 출금 가이드](https://docs.silicon.network/user-guide/bridge/withdrawal)] 를 참고해 주시기 바랍니다.

네트워크 종료 이후 실리콘 네트워크 관련 문의 및 자산 관련 안내 창구는 오지스(Ozys)로 이관됩니다.

문의: <support@silicon.network>

그동안 실리콘 네트워크를 이용해 주셔서 감사합니다.


# Silicon Overview

Silicon, the first Web3 blockchain network in South Korea connected to a centralized crypto exchange (CEX), is building the true future of the internet in a decentralized world.

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FNLdWAEylM9hvk3bBrRZM%2FWelcome%20to%20Silicon.gif?alt=media&amp;token=5e4dbed4-2423-42a2-9554-c70e3a0b8954" alt=""><figcaption><p>Welcome to Silicon</p></figcaption></figure>

## THE FUTURE OF NETWORK <a href="#hello" id="hello"></a>

#### **Silicon is a next-generation Ethereum Layer 2 network built for real-world usability, powered by Polygon zkEVM.**

It offers a familiar yet evolved Web3 experience — where scalability meets identity, and where infrastructure is designed not just for performance, but for people.

### ✅ Fully Ethereum-Compatible

Silicon shares full EVM compatibility with Ethereum L1, allowing developers to seamlessly deploy existing smart contracts and integrate with the broader Ethereum ecosystem.

### ⚡ Faster, Cheaper, and More Scalable

Compared to Ethereum L1, Silicon delivers significantly faster transaction speeds and lower gas fees, unlocking higher throughput for both applications and users.

### 🧠 Powered by Polygon — and Part of the Agglayer Ecosystem

Silicon is built on [**Polygon zkEVM**](https://polygon.technology/polygon-zkevm), one of the most advanced ZK-rollup technologies available, combining Ethereum-grade security with ZK efficiency.\
As a member of [**Agglayer**](https://agglayer.dev/), Polygon’s multi-stack interoperability layer, Silicon connects with a growing network of sovereign zk-powered chains — unlocking seamless cross-chain experiences and shared liquidity in the future.

### 🧩 Built-In Identity Protocols

With native protocols like **Open Cohort** and **Named Wallets**, Silicon enables programmable group formation and persistent onchain identity — allowing for richer, more human-centered Web3 applications.

### 🇰🇷 Integrated with Korea’s Leading CEX

Silicon is uniquely positioned within the Korean Web3 landscape, offering seamless UX by integrating with the nation’s leading centralized exchange [(Korbit)](https://lightning.korbit.co.kr/). This allows for smoother onboarding and greater accessibility for everyday users.

## Silicon's Vision

Silicon aims to become a place that embodies the following values in the emerging era of Web3.

#### Where everything starts.

Silicon is the new basis of the upcoming Web3 ecosystem, like the element 'Silicon', a key part of sand and modern technology, it holds immense potential.

#### Where everyone can be anything.

Like tiny grains of sand that can become anything, in the Siliocn, everyone has the potential to become anything.

#### Where every identity meets.

In Silicon, everyone can freely express their individuality and transparently record it on the blockchain, forming the foundation for strong communities.

#### Where every community thrives.

Communities formed by individual identities can surpass their limits with tokenomics.\
Silicon is a new social network that enables communities to create, grow, and thrive.

#### Where every path is open.

Silicon aims to foster the exchange and revival of true Web3 community culture through seamless interaction with other blockchains.

## Get started with Silicon, right now!

{% embed url="<https://silicon.framer.website>" %}


# Features

## 1. Layer 2 Closely Connected to Ethereum

### ① **Trustless network environment with high security and decentralization**

Silicon is a Layer 2 governed by Ethereum governance. With Silicon, users will be able to experience secure utilization of on-chain assets, as Silicon has created a network environment almost identical to Ethereum, the most secure of all blockchains. In addition, Silicon Network users will be given the opportunity to access massive on-chain liquidity and protocols based on Ethereum.

### ② Providing advanced user experience

Users will be able to use Ethereum's trustless environment on Silicon and transactions will be processed at a much faster pace. This is possible because Silicon (Layer 2) performs transaction execution, and Ethereum (Layer 1) performs consensus and verification. As Silicon improves Ethereum's slow transaction speed and high gas fees, the user experience will be improved.

## 2. zkEVM Rollup Solution Driven by Polygon CDK

### ① Polygon CDK

Silicon is an EVM-compatible blockchain that uses Polygon CDK. Polygon CDK is an open source framework for building ZK-based layer 2 blockchains on Ethereum. Silicon built on Polygon CDK has "near-instant finality, unlimited scalability, and unified liquidity" characteristics, and supports a wide range of Web3 ecosystems. The Silicon blockchain can be connected to other blockchains using Polygon CDK, as well as to various companies that provide tools for integration, development, and deployment. This will enable Silicon to build a more comprehensive Web3 ecosystem.

### ② zkEVM Validium

Silicon was built using Polygon CDK and Validium chain architecture. Unlike the previous Rollup, Validium does not save transaction data on L1 network, instead, generates ZK proofs and publishes them as proofs of validity. Transactions executed on the Silicon Network by users are validated off-chain, that is, only the transaction hash is posted, and transaction data is stored off-chain. Validium-solution based Silicon optimizes blockchain scalability while ensuring data integrity.

## 3. Community-lead Web3 Ecosystem

### ① Development friendly environment

Silicon is an Ethereum-based layer 2 network with high EVM compatibility. Therefore, Ethereum developers can seamlessly deploy smart contracts, development tools, and wallets that already run on Ethereum to the silicon network at low cost.

Team Silicon believes that a developer-based community is essential for blockchain network growth. Blockchain ecosystem expands as developers share ideas and contribute to projects through mutual validation. Thus, we are developing 'Web3 Quick Starter (tentative name)', a platform that will accelerate the entry of various project developers into the Silicon ecosystem. Developers can easily onboard on Silicon's network using 'Web3 Quick Starter', and Silicon's developer community will be strengthened through various interactions among developers. Details regarding the platform will be released at a later date.

### ② Web3 user friendly environment

&#x20;The vision of Silicon is to build an ecosystem for Web3, and Telegram will be a partner to realize this vision. Telegram messenger service used by millions of global users, and a social platform closely connected to the TON blockchain network. Moreover, Telegram has developed a web3 infrastructure that allows users to have 'one-click access' to the blockchain ecosystem, and based on this, various blockchain communities operate on Telegram.

Silicon plans to develop various WebApp content based on Telegram in the near future. Telegram users will be able to access blockchain content (games, DeFi, etc.) within the messenger, without having to install separate apps.

<br>


# Missions

#### **Silicon aims to build an ecosystem based on openness and diversity where all users (Web3 users, builders, and project developers) can participate. To achieve this mission, Silicon's growth strategy (master plan) consists of three steps.**

### Phase 1. Building basic infrastructure and developing products

Silicon aims to create a Web3 developer-friendly network environment in Phase 1. Building a solid foundation of basic infrastructure from outset, is crucial to achieving this goal. Silicon built its basic blockchain infrastructure using Polygon CDK. The Silicon network is easily accessible to Polygon CDK-based blockchain projects as well as existing and new Ethereum-based blockchain projects.

Silicon Network also offers DeFi services like, DEX, cross-chain bridge, and portfolio analysis tools that enhance user convenience. With Silicon's DeFi (Decentralized Finance) service, users can experience the Web3 ecosystem. The Silicon Network aims to become a gateway to the Web3 ecosystem for more developers and users by utilizing blockchain infrastructure as well as content.

### Phase 2. Developing a new platform that lowers entry barriers for developers

Silicon aims to develop a platform that enables different blockchain developers to easily integrate with it. The 'Web3 Quick Starter(tentative name)' allows anyone, even those with no development experience, to create Web3 content. The introduction of this platform will result in a significant increase in the number of new projects being created on the Silicon network resulting from the lower entry barrier for project developers to enter the Silicon network. Consequently, the communities of developers and users that are formed around the resulting projects can experience explosive growth as a result of network effects. A diverse community of Silicon-based projects can foster a virtuous circle of attracting more developers and attracting more users.

### Phase 3. Growth of community through social platform connections

Silicon Network aims for a blockchain ecosystem centered around a community of diverse participants.

The aforementioned ‘Web3 Quick Starter’ is a platform that is freely available not only to developers, but also to general users without a significant understanding of blockchain technology. Users can create their own identities on the platform. With the identity they have chosen for themselves, users can interact with a wide range of participants and build a community of like-minded users.

Silicon plans to connect the various projects onboarded to the Silicon Network with ‘Telegram’, a global social messenger service. Telegram is a popular platform for blockchain communities, as well as wallets, DEXs, and DApps associated with the TON Network. Therefore, Silicon team intends to develop a DApp in App based on Telegram, utilizing Telegram's rich social graph to create synergy, resulting in the acquisition of Telegram's global on-chain users and the establishment of a community where web3 content developers and Telegram users can interact. The Silicon Network will foster a community-centered environment that stimulates the blockchain ecosystem's virtuous growth cycle.


# Silicon identity protocol

Meet Silicon’s Web3 social protocol that assigns unique blockchain attributes to individuals, enabling powerful social interactions.

## Meet Silicon's identity protocol, makes you even more unique.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><strong>OpenCohort</strong></td><td>OpenCohort is Silicon's social protocol that assigns unique activity-based attributes to Web3 wallets, enabling the creation of enhanced community value.</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FSCP6fZH6CNDc8zAlO29a%2Fimage.png?alt=media&amp;token=b2767cf4-72a7-4993-8888-b2a9838e9d1e">image.png</a></td></tr><tr><td><strong>NamedWallet</strong></td><td>NamedWallet is a solution that allows potential users without a Web3 wallet to declare their wallet and access various opportunities on Web3.</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FRVkVMwI6P3kHGm58UHEv%2Fimage.png?alt=media&amp;token=93128598-6e50-4748-91a6-9a9f2e7d2856">image.png</a></td></tr></tbody></table>

***

## <img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F9DRnwBokQk6Cc6218zw6%2Fimage.png?alt=media&amp;token=c80f5786-f521-453f-bf7c-12407daa1e44" alt="" data-size="line"> OpenCohort

### Make your wallet unique with cohorts.

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fx8VcdlZYp8K8i7REpJ4t%2Fimage.png?alt=media&amp;token=39b3ff66-09d2-458f-97e1-956122b99119" alt="" width="563"><figcaption><p>For example, if you stake 5 ETH, you’ll be part of the "5 ETH Stakers" cohort.<br>This allows you to connect with other "5 ETH Stakers" and even become eligible for a project's airdrop.</p></figcaption></figure>

OpenCohort assigns attributes like activity proof or affiliation to wallets, grouping users into **‘cohorts’**. 
For example, users holding 10+ NFTs or staking 5+ ETH can form activity-based groups and connect. Partners and builders can target these cohorts to grow businesses and strengthen communities.

***

## <img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FgIcBSDhkdHlOA9dA2jph%2Fimage.png?alt=media&amp;token=ecc413af-de2f-46e4-bb31-0d656d2dab10" alt="" data-size="line"> NamedWallet

### Create and assign the wallet to everything.

<div align="center"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FiTHWjubevxriHlUQvJ9J%2Fimage.png?alt=media&amp;token=3ad44295-1a8e-4e59-93e6-ede8cc1d9f8e" alt="" width="563"><figcaption><p>You can create "Satoshi Nakamoto's wallet" and send various assets to it.<br>Who knows? The <em>real</em> Satoshi might show up one day, verify their identity, and claim the assets…</p></figcaption></figure></div>

Create a blockchain wallet with NamedWallet, **assign it for a Web3 non-user**, and use it for business strategies, donations, and rewards. The wallet remains secure until ownership is verified, at which point the privileges are transferred.

***

## Product Targets

### <img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FBMBm2xuJBCaUN08khrrW%2Fimage.png?alt=media&amp;token=5f397086-f7f1-4e81-a7e8-38529173daea" alt="" data-size="line"> Partner

#### Expanding customer communities into Web3.

Partners(Company, Business, Enterprise, etcs.) can expand their customer communities into Web3, securely store data, and manage memberships transparently. Customized incentives and airdrops based on activity, contributions, and NamedWallets drive customer engagement, enhance their sense of belonging, and help build completely new marketing business strategies that never existed before.

### <img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F6VM0z8P7t8fOqZSSiPAd%2Fimage.png?alt=media&amp;token=552249d8-fa6c-4f5e-8848-e7b72f268087" alt="" data-size="line"> Builder

#### Enabling anyone to build a Web3 community.

Anyone can start a Web3 project such as tokens or Dapps using OpenCohort and NamedWallet. By designing tokenomics with NamedWallet and offering customized airdrops and incentives to partner cohorts, they can engage various users, including cohort members, influencers, and public figures. This approach helps form new cohorts, fosters ongoing communication between builders and users, and creates an environment for sustainable project growth.

### <img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FI3aWmCc3yHrsW06aK3CN%2Fimage.png?alt=media&amp;token=05a7b127-e5d8-4987-b44e-28e4e8d01e94" alt="" data-size="line"> User

#### Motivating users through Web3 activity incentives.

OpenCohort allows users to express their identities through activities in games, media, and social interactions across Web3, connecting with like-minded individuals. Through NamedWallet, users can engage by supporting organizations or individuals they follow. These interactions create opportunities for creators and businesses, while motivating users to contribute to ecosystem growth through rewards and incentives.

## Use-cases

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td>Easy and accurate Web3 activity/identity verification</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FZJkYbfLMb9Pt5LbDkpOm%2Fimage.png?alt=media&amp;token=e05c7ea4-2395-4dd3-b39a-bc30d53b6ada">image.png</a></td></tr><tr><td>Securely manage user activity on the blockchain</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FwWIdb5uXdGcvKt1c2QWk%2Fimage.png?alt=media&amp;token=c355ff7a-e85c-426f-b5ce-ea65988035ab">image.png</a></td></tr><tr><td>Connect similar types of users and build a strong, personalized community</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fgwd3SLPxfieG1rsHsPMs%2Fimage.png?alt=media&amp;token=88d46c20-720b-49c4-aa80-a5d175947b45">image.png</a></td></tr><tr><td>Categorize users based on their contributions to the community or project</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fr8ORH8enrTV6yPWfM6Vd%2Fimage.png?alt=media&amp;token=bc2ee21e-3d9e-415e-b053-ee0db3fd9ad6">image.png</a></td></tr><tr><td>Incentivize users with tiered rewards based on contributions</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FFseElgHYc7ZMGYlVWPp9%2Fimage.png?alt=media&amp;token=fb7da491-76c1-4b6c-ab06-2057b81828e3">image.png</a></td></tr><tr><td>Easier user targeting for project promotions</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FWKmGSflJoiUOPh4kNfpF%2Fimage.png?alt=media&amp;token=5c01670d-ba08-468d-8baa-4403372dfaf2">image.png</a></td></tr><tr><td>Expand customer/follower communities on the blockchain</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FoQ46M4f0uELc4YAFqXmf%2Fimage.png?alt=media&amp;token=fff23233-0b4b-4c38-a2d4-741859c73b9b">image.png</a></td></tr><tr><td>Transparent on-chain funding, donation and allocation.</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FfqPUQhko0LvTBjT8owXX%2Fimage.png?alt=media&amp;token=ac1aafd2-7846-4b75-8dbb-88e0874db544">image.png</a></td></tr><tr><td>On-chain DAO for creators &#x26; fans, businesses &#x26; customers</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FndUy3393A7I4NS9PuMiL%2Fimage.png?alt=media&amp;token=a68ec639-07b8-45bf-8822-32c06ebe1533">image.png</a></td></tr><tr><td>Fan art interaction on the blockchain</td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F2DQgsqnEYNLRD1YTC0lC%2Fimage.png?alt=media&amp;token=ebe0cde0-3584-464d-bb84-d242c6d7082f">image.png</a></td></tr></tbody></table>

***

## Try it now

#### View available cohorts and named wallets to join.

You can try out the OpenCohort and NamedWallet system directly through '[Vennie](htttps://vennie.io),' a protocol within the Silicon ecosystem. Create your own cohort and drive your project forward!

{% embed url="<https://vennie.io>" %}

#### Create my own cohorts and named wallets.

A system that allows anyone to easily create and manage cohorts and NamedWallets is in development and will be released soon.

***

## Interested?

OpenCohort and NamedWallet interact closely with the Silicon network to efficiently and securely store and process the vast data of network users. Check out our developer docs if you're interested in OpenCohort and NamedWallet.

{% content-ref url="/pages/AoauG3qSXFNxOV5N1RCc" %}
[Build on OpenCohort & NamedWallet](/builders/opencohort)
{% endcontent-ref %}


# Wallet configuration

Guide to creating and setting up a wallet for Silicon

## What is a crypto wallet?

A crypto wallet is software or a service that securely stores and manages digital assets like cryptocurrencies. It provides unique addresses for transactions and securely stores private keys used for signing and authenticating transactions. Crypto wallets are available as web wallets, mobile apps, and hardware devices.

## Supported wallet

{% hint style="info" %}
Most EVM-compatible wallets also support Silicon Network.

[Add Silicon to your network list.](/builders/network)
{% endhint %}

<table data-card-size="large" data-view="cards" data-full-width="false"><thead><tr><th>Wallet</th><th>Platform</th><th>Network</th><th data-hidden>Custody</th><th data-hidden data-type="files"></th><th data-hidden data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden></th></tr></thead><tbody><tr><td><strong>Korbit Web3 Wallet</strong></td><td>Mobile</td><td>Silicon</td><td></td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FQ2cT0zWwDg3fvLIZonaF%2Fimage.png?alt=media&amp;token=b5b9997c-a1e0-46da-8adf-ab66bf68c046">image.png</a></td><td><a href="https://korbit.co.kr">https://korbit.co.kr</a></td><td></td></tr><tr><td><strong>Teleport</strong></td><td>PC, Mobile</td><td>Silicon</td><td>Non-custodial</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F2HZQsTnwfqKeQ2zab6QA%2Fimage.png?alt=media&amp;token=fdac6090-2051-4478-871e-5bd2db5a6637">image.png</a></td><td><a href="https://teleportwallet.net">https://teleportwallet.net</a></td><td></td></tr><tr><td><strong>MetaMask</strong></td><td>PC, Mobile</td><td>EVM</td><td>Non-custodial</td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FtnF3mbMYRZULlBX5dLdJ%2Fimage.png?alt=media&amp;token=55c19326-332b-4cd7-966e-89e95b9810f0">image.png</a></td><td><a href="https://metamask.io/">https://metamask.io/</a></td><td></td></tr><tr><td><strong>SubWallet</strong></td><td>PC, Mobile</td><td>EVM</td><td></td><td></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FsbSFoOAcwUTacvH2qbps%2Fimage.png?alt=media&amp;token=f77d3585-45e7-47c4-8e04-64d5b8fe43f3">image.png</a></td><td><a href="https://www.subwallet.app/">https://www.subwallet.app/</a></td><td></td></tr></tbody></table>


# Centralized exchange

Silicon is integrated with centralized exchanges, providing a more seamless user experience.

## Silicon-supported CEX

{% embed url="<https://lightning.korbit.co.kr>" %}


# Bridge

These steps will guide you on how to use the bridge on Silicon.

{% hint style="success" %}
**What is a Crypto Bridge?**

A crypto bridge is a technology or service that facilitates the transfer of assets between different cryptocurrencies or blockchain networks. It allows users to freely transfer and exchange assets across independent networks.
{% endhint %}

## [Silicon Bridge ](https://bridge.silicon.network)

{% hint style="info" %}
Currently, Silicon Bridge does not support connections with **Korbit Web3 Wallet or Teleport Wallet**.\
If you wish to bridge assets externally, please first transfer them to a wallet that supports WalletConnect, such as MetaMask, and proceed from there.
{% endhint %}

### What would you like to do?

{% content-ref url="/pages/1TnuPsCYJyPHBa7xQdA0" %}
[Deposit to Silicon](/user-guide/bridge/deposit)
{% endcontent-ref %}

{% content-ref url="/pages/BoUT0WD9FaWopq3SltCo" %}
[Withdrawal from Silicon](/user-guide/bridge/withdrawal)
{% endcontent-ref %}


# Deposit to Silicon

Learn how to deposit your assets into Silicon in a few simple steps.

{% hint style="warning" %}
Silicon Bridge only supports bridging between Ethereum (L1) and Silicon (L2).\
For bridging to other networks, please use [Orbit Bridge](https://bridge.orbitchain.io).
{% endhint %}

{% hint style="info" %}
To use the bridge, you'll need a crypto wallet and a small amount of ETH to cover fees.
{% endhint %}

{% stepper %}
{% step %}

### Connect your wallet

{% hint style="info" %}
Currently, Silicon Bridge does not support connections with **Korbit Web3 Wallet or Teleport Wallet**.\
If you wish to bridge assets externally, please first transfer them to a wallet that supports WalletConnect, such as MetaMask, and proceed from there.
{% endhint %}

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FaYFgrTJtPh5iZZNMKYpk%2Fimage.png?alt=media&amp;token=aa22e91a-2401-4b56-9c48-cacdfee11b00" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### Select network your assets are on.

For Ethereum to Silicon, Select **Deposit.**

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FeYZGGPZ3B2bdXlvoW0c6%2Fimage.png?alt=media&amp;token=a9f44551-6396-4b5b-864f-4f4373fbffca" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### Select an asset and enter the amount you want to bridge.

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F412CgN6RczDSfZwnJMUN%2Fimage.png?alt=media&amp;token=0035f1a5-d4ad-4aa3-872e-7ffe9f797771" alt="" width="375"><figcaption></figcaption></figure> <figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FiYTF4IY35HOSyvqpQsUp%2Fimage.png?alt=media&amp;token=26a40d48-3376-4851-a9b0-c0250d7f1515" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### Verify the 'Destination Address' for the transfer.

Check that your **wallet address is correct**. If needed, **you can send directly to another address** (e.g., from MetaMask to Korbit Web3 Wallet or Teleport).

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FVyc0LWtjdO4sKWUs4aBT%2Fimage.png?alt=media&amp;token=f9029982-93d6-421f-ac43-c5699c7cbec3" alt="" width="375"><figcaption></figcaption></figure> <figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FzjfjYOrJ53V1dJGeCcrp%2Fimage.png?alt=media&amp;token=f32aa79a-a79b-4ef9-82be-9105f9080454" alt="" width="375"><figcaption><p>You can directly bridge and transfer assets from Wallet A to Wallet B.</p></figcaption></figure></div>
{% endstep %}

{% step %}

### Review the summary of the bridge and gas fees, then confirm the bridge.

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F8zxcHRiGqHC3mnr27keX%2Fimage.png?alt=media&amp;token=768567fb-2556-4435-a299-65d868e2cd2f" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}
{% endstepper %}


# Withdrawal from Silicon

Learn how to withdraw your assets from Silicon in a few simple steps.

{% hint style="warning" %}
Silicon Bridge only supports bridging between Ethereum (L1) and Silicon (L2).\
For bridging to other networks, please use [Orbit Bridge](https://bridge.orbitchain.io).
{% endhint %}

{% hint style="info" %}
To use the bridge, you'll need a crypto wallet and a small amount of ETH to cover fees.
{% endhint %}

{% stepper %}
{% step %}

### Connect your wallet

{% hint style="info" %}
Currently, Silicon Bridge does not support connections with **Korbit Web3 Wallet or Teleport Wallet**.\
If you wish to bridge assets externally, please first transfer them to a wallet that supports WalletConnect, such as MetaMask, and proceed from there.
{% endhint %}

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FaYFgrTJtPh5iZZNMKYpk%2Fimage.png?alt=media&amp;token=aa22e91a-2401-4b56-9c48-cacdfee11b00" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### Select network your assets are on.

For Silicon to Ethereum, Select **Withdraw.**

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F4sfKVzJBl53xWO4vsXFN%2Fimage.png?alt=media&amp;token=7163fbd5-9bef-404c-aff0-ad0218648dab" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### Select an asset and enter the amount you want to bridge.

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FJQwVEfxr3IBMmJtqfAGL%2Fimage.png?alt=media&amp;token=5c6ef25d-7531-4911-98a3-e14ba86adf97" alt="" width="375"><figcaption></figcaption></figure> <figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fw2Ff7AO5X8yW6ERhixMr%2Fimage.png?alt=media&amp;token=52156f18-78ab-4a97-8311-cdc431042e0e" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### Verify the 'Destination Address' for the transfer.

Check that your **wallet address is correct**. If needed, **you can send directly to another address** (e.g., from MetaMask to Korbit Web3 Wallet or Teleport).

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FVAIRLenylkJuAcQI9ieA%2Fimage.png?alt=media&amp;token=2fa42277-b78d-4dcd-bfe1-bbbf52b46042" alt="" width="375"><figcaption></figcaption></figure> <figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FIjmUrt84s54rC9V2s9d3%2Fimage.png?alt=media&amp;token=3ed224a7-86ee-4131-b2d0-3e357d75686d" alt="" width="375"><figcaption><p>You can directly bridge and transfer assets from Wallet A to Wallet B.</p></figcaption></figure></div>
{% endstep %}

{% step %}

### Review the summary of the bridge and gas fees, then confirm the bridge.

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F6ubSuxAu9eZqqK5iTbkK%2Fimage.png?alt=media&amp;token=77dea856-d725-43e2-b233-68718c4169a4" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}

{% step %}

### <mark style="color:red;">\[IMPORTANT]</mark> To bridge from Silicon (L2) to Ethereum (L1), make sure to click "Finalize" in the Activity Screen.

{% hint style="info" %}
Due to the structural nature of moving from L2 to L1, the Finalize step is required.\
The "Finalize" button will be activated once the bridge transaction is complete, which **may take around 10 to 30 minutes.**
{% endhint %}

<div align="left"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FsFDwXyViUvjynRgVxMFZ%2Fimage.png?alt=media&amp;token=90733f52-ff64-4054-85a2-71b2fa1d90b1" alt="" width="375"><figcaption></figcaption></figure></div>
{% endstep %}
{% endstepper %}


# Block explorer

This step explains the Block Explorer, a tool for viewing recorded transactions.

{% hint style="success" %}
**What is a Block Explorer?**

A Blockchain Explorer is a tool similar to a search engine that shows both the current and historical state of a blockchain. Anyone with internet access can use it to view all public blockchain transactions.
{% endhint %}

## Silicon Scope (L2)

Silicon Scope provides features like L2 block times, transaction searches, detailed information views, smart contract interactions, and insights into deposits, withdrawals, batch transactions, and contracts.

<table data-card-size="large" data-view="cards" data-full-width="false"><thead><tr><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><strong>Silicon Scope</strong></td><td></td><td><a href="https://scope.silicon.network">https://scope.silicon.network</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F8jFb91iw0hvMCAp48Bq2%2Fimage.png?alt=media&amp;token=2fa62e2b-157f-4458-96ce-62c14a8c55c0">image.png</a></td></tr></tbody></table>

## Etherscan (L1)

Etherscan is a Block Explorer for the Ethereum (L1) network, allowing you to view transactions rolled up from Silicon (L2) that are recorded on Ethereum.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Etherscan</strong></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FgnghojSoXNr9vnNwWFjl%2Fimage.png?alt=media&amp;token=420983eb-1c37-40ce-b3d3-2df5bac1d79d">image.png</a></td><td><a href="https://etherscan.io">https://etherscan.io</a></td></tr></tbody></table>


# Fees

The Silicon is a zkEVM based layer 2 network, using the Polygon CDK.

The Polygon CDK is a zkRollup solution that is being used in global L2 network implementations.

When a user sends a transaction on a rollup, the transaction fee paid is meant to cover the cost of two things: *the L2 network resources needed to execute the transaction + the L1 network resources for making the transaction data available.*

In the case of rollups built on top of Ethereum, this second part of the formula is what’s costly.

{% embed url="<https://polygon.technology/blog/polygon-zkevm-effective-gas-price-live-on-mainnet-beta>" %}
Source
{% endembed %}

The L1 fee will vary depending on the amount of transactions on the L1. If the timing of your transaction is flexible, you can save costs by submitting transactions during periods of lower gas on the L1 (for example, over the weekend)

Similarly, the L2 fee can increase and decrease depending on how many transactions are being submitted to the L2. This adjustment mechanism has the same implementation as the L1; you can read more about it[ here](https://eips.ethereum.org/EIPS/eip-1559).

For additional details about fee calculation on Silicon, please refer to the[ Polygon zkEVM developer documentation](https://polygon.technology/blog/polygon-zkevm-effective-gas-price-live-on-mainnet-beta).


# Build on Silicon

Documentation for Silicon Developers

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FeuZwE7iTQrdub2Nio0Dn%2F%E1%84%8F%E1%85%A5%E1%86%B7%E1%84%91%E1%85%A9%E1%84%8C%E1%85%B5%E1%84%89%E1%85%A7%E1%86%AB%201.gif?alt=media&amp;token=3565da63-18b6-4947-92c0-dd5007903a67" alt="" width="563"><figcaption><p>Hey you, BUIDL on Silicon now!</p></figcaption></figure>

Silicon is a zkEVM Layer 2 network built on Ethereum, powered by [Polygon CDK](https://wiki.polygon.technology/docs/cdk/) — a zkEVM stack for building Ethereum layer 2 scaling solutions. Developers can easily deploy their existing contracts on zkEVM, and users can move their assets from Ethereum and conduct transactions off-chain. These transactions are bundled into groups with a zero-knowledge proof to verify their validity

## Developing on Silicon (Chain)

<table data-view="cards"><thead><tr><th data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="/builders/network">Network information</a></td></tr><tr><td><a href="/builders/zkevm-contracts">zkEVM contracts</a></td></tr><tr><td><a href="/builders/testnet">Testnet</a></td></tr></tbody></table>

## Developing on OpenCohort

<table data-card-size="large" data-view="cards"><thead><tr><th data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="/builders/opencohort/contract">Contract</a></td></tr><tr><td><a href="/builders/opencohort/framework">Framework</a></td></tr></tbody></table>


# Build on OpenCohort & NamedWallet

<table data-card-size="large" data-view="cards"><thead><tr><th data-card-target data-type="content-ref"></th><th data-hidden data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="/builders/opencohort/contract">Contract</a></td><td></td></tr><tr><td><a href="/builders/opencohort/framework">Framework</a></td><td></td></tr></tbody></table>


# Contract

## Standard contract for OpenCohort

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>OpenNameTag</td><td></td><td></td><td><a href="/builders/opencohort/contract/opennametag">OpenNameTag</a></td></tr><tr><td>Account Abstraction</td><td></td><td></td><td><a href="/builders/opencohort/contract/account-abstraction">Account Abstraction</a></td></tr></tbody></table>


# OpenNameTag

## Overview

`OpenNameTag` is a smart contract that complies with the ERC-721 standard, allowing the issuance and management of unique NameTag NFTs (Non-Fungible Tokens) for addresses on the Silicon Network. Additionally, it uses the ERC-5192 standard to issue a token that manages information bound to a specific address. This allows users to manage metadata and attributes associated with their addresses, such as name, description, image, and even custom key-value pairs as attributes.

## Code

* Github: <https://github.com/0xSilicon/opencohort-contracts/blob/main/contracts/token/OpenNameTag.sol>

## Address

* Mainnet: `0x2df5f5d15cde349b075137ffd6b1f94462df5929`
* Sepolia: `0x00c6242D66157A51df7e05dfEfb38372B798758f`

## Key Features

Unlike Ethereum Name Service (ENS) on the Ethereum network, OpenNameTag on the Silicon Network offers the following features:

* **Compliance with ERC-721 Standard**
  * OpenNameTag is an ERC-721 standard NFT token that supports token ownership, issuance, and querying ownership status. Each NameTag issued by users is minted as an NFT, meaning it can be seamlessly integrated into existing NFT systems.<br>
* **Flexible Attribute Management**
  * Each address can define, add, modify, and delete various attributes (key-value pairs) for their address. Token holders can manage metadata such as name, description, and image, as well as custom attributes.
  * Each address can specify basic user-defined metadata like `name`, `description`, and `image`, which can be easily referenced on the blockchain.
  * This flexible attribute management function allows users to manage attributes with key-value pairs.
  * Data such as name and image defined by each address can be considered official information about the address and can be utilized in various ways within the blockchain ecosystem. For instance, ERC-20 token contracts can directly provide their image and i18n resources.<br>
* **1:1 Token Binding per Address**
  * Each address is guaranteed to hold one NameTag, meaning there is no need to search for what attributes an address has assigned to itself.
  * OpenNameTag implements the ERC-5192 interface, permanently binding the token to the address.<br>
* **Low Cost, Unlimited Expression**
  * With OpenNameTag, anyone can freely define attributes by simply paying the transaction cost. There is no need to worry about uniqueness, and users don’t have to pay high costs for special words or reserved keywords.

## Contract Variables

* `MAX_PROPERTY_COUNT`: The maximum number of attributes an address can have.
* `_name` & `_symbol`: The name and symbol of the OpenNameTag token.
* `_tokens`: An array storing all issued tokens.
* `_ownerList`: A list of addresses that own tokens.
* `_tokenIds`: A mapping from owner addresses to the token IDs they own.
* `_owners`: A mapping from token IDs to the owner addresses.
* `_balances`: A mapping that tracks the token balances of each owner.
* `_metadata`: A mapping from token IDs to the metadata (NameTagMetadata structure) of each token.
* `_propertyCount`: A mapping that stores the number of attributes each token has.
* `_propertyKeyList`: A list that stores the attribute keys for each token.
* `_usedProperty`: A mapping that tracks the attributes used by each token.
* `_properties`: A mapping that stores the actual attributes (key-value pairs) for each token.

## Events

* **Transfer**: Triggered when a token is transferred. (Inherited from ERC-721)
* **MetadataUpdate**: Triggered when a token's metadata is updated.
* **SetNameTagMetadata**: Triggered when NameTag metadata is set.
* **AddProperty**: Triggered when an attribute is added to a token.
* **RemoveProperty**: Triggered when an attribute is removed from a token.
* **ModifyProperty**: Triggered when an attribute of a token is modified.

## External Functions

* **version()**: Returns the version of the contract as a string.

## ERC-5192 Interface

* **locked (uint256 tokenId)**: Always returns true, indicating that the token is permanently locked. This follows the ERC-5192 (Soulbound Token, SBT) standard.

## ERC-721 Interface Functions

* **supportsInterface(bytes4 interfaceId)**: Checks if the contract supports a specific interface (following the ERC-165 standard).
* **totalMinted()**: Returns the total number of minted tokens.
* **totalSupply()**: Returns the total number of tokens in circulation.
* **balanceOf(address owner)**: Returns the number of tokens owned by a specific address.
* **getOwnerListLength()**: Returns the number of unique owners.
* **getOwnerByIndex(uint256 idx)**: Returns the address of an owner at a specific index in \_ownerList.
* **ownerOf(uint256 tokenId)**: Returns the address of the owner of a specific token ID.
* **tokenIdOf(address owner)**: Returns the token ID associated with a specific owner's address.
* **name()**: Returns the name of the token collection.
* **symbol()**: Returns the symbol of the token collection.
* **baseURI()**: Returns the base URI for accessing token metadata.
* **tokenURI(uint256 tokenId)**: Returns the metadata URI of a specific token.

## Metadata Functions

* **metadata(uint256 tokenId)**:
  * Returns the `NameTagMetadata` for a specific token, including the `name`, `description`, and `image`.
* **setNameTagMetadata(NameTagMetadata memory nameTagMetadata)**:
  * Allows a user to set or update the metadata of a specific token.
* **propertyCount(uint256 tokenId)**:
  * Returns the number of attributes associated with a specific token ID.
* **propertyKey(uint256 tokenId, uint256 idx)**:
  * Returns the attribute key at the idx-th position for a specific token ID.
* **property(uint256 tokenId, string memory key)**:
  * Returns the value of the idx-th attribute key for a specific token ID.

## Attribute Management Functions

* **addProperty(string memory key, string memory value)**:
  * Adds a new attribute (key-value pair) to the address.
* **addPropertyBatch(string\[] memory keys, string\[] memory values)**:
  * Adds multiple attributes to the token in a single batch.
* **removeProperty(string memory key)**:
  * Removes a specific attribute key from the address.
* **modifyProperty(string memory key, string memory value)**:
  * Modifies the value of an existing attribute key for the address.


# Account Abstraction

## Overview

Account Abstraction (referred to here as “AA”) is a concept that separates the transaction logic from the specific constraints imposed by Externally Owned Accounts (referred to here as “EOA”) on the blockchain. In Ethereum, accounts can be divided into two types: EOAs controlled by private keys and Contract Accounts (referred to here as “CA”) controlled by programmatic code logic.

While there are two types of accounts, most wallet users are likely more interested in choosing a safer and more convenient wallet than focusing on the type of account. AA leverages smart contracts, enabling users to perform more flexible and customizable transaction validation, offering various security advantages compared to EOAs, which are subject to cryptographic constraints.

## Benefit of Account Abstraction

* **Increased Flexibility**
  * Allows implementation of custom logic for transaction validation.
  * Supports features such as multi-signature wallets and social recovery.<br>
* Improved User Experience
  * Users can handle customized transactions without directly managing private keys, increasing convenience.<br>
* Enhanced Security and Recovery
  * Can apply new cryptographic algorithms.
  * Provides features such as social recovery and programmable key management, enhancing security.

## Use Case of Account Abstraction

* Wallet Flexibility
  * Smart contract wallets operate independently without an EOA, providing easy access to account recovery, fee management, and multi-signature functionality.<br>
* Gasless Transactions
  * Allows the use of tokens other than ETH for fee payments, or enables third parties to pay the fees on behalf of the user, reducing the burden of paying gas fees.<br>
* Programmable Account Logic
  * Operates based on code rather than private keys, allowing users to program various transaction approval conditions. Users can set complex rules such as multi-signature, delayed execution, and hierarchical approval structures.

## Account Abstraction on Silicon Network&#x20;

The Silicon Network has deployed the ERC-4337 standard's EntryPoint 0.7.0 contract and related systems. The EntryPoint address is identical to that of Ethereum, and it has been deployed with the exact same code as the official repository.

* ERC-4337 EntryPoint 0.7.0 Addresses
  * Silicon:[ Scope Silicon Network](https://scope.silicon.network/account/0x0000000071727de22e5e9d8baf0edac6f37da032)
  * Ethereum: [Etherscan](https://etherscan.io/address/0x0000000071727de22e5e9d8baf0edac6f37da032)&#x20;

## World's First Account Abstraction-Friendly Blockchain Explorer

The Silicon Network's Blockchain Explorer is optimized for ERC-4337's UserOperation. It provides detailed information on various UserOperations executed through EntryPoint and interprets them.

* In **UserOperation**, detailed information such as Paymaster, Batch Execution, Events, and RawData, in addition to basic property information, is provided.<br>
* In **Transaction**, you can check whether UserOperations exist and view detailed information in a list format.<br>
* In **Account**, you can view the list of UserOperations executed by an AA account, similar to a regular transaction list.

## Additional Resources and Reference Materials

For a deeper understanding of Account Abstraction, refer to the following resources:

* [https://www.erc4337.io](https://www.erc4337.io/docs)
* <https://github.com/eth-infinitism/account-abstraction>
* <https://eips.ethereum.org/EIPS/eip-4337>


# Framework

Standard Framework for OpenCohort

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f332">🌲</span> Merkle Tree &#x26; Merkle Proof</td><td></td><td></td><td><a href="/builders/opencohort/framework/merkle-tree-and-merkle-proof">Merkle Tree &amp; Merkle Proof</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f9d1-1f91d-1f9d1">🧑‍🤝‍🧑</span> Participants</td><td></td><td></td><td><a href="/builders/opencohort/framework/participants">Participants</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f9e9">🧩</span> Components</td><td></td><td></td><td><a href="/builders/opencohort/framework/components-overview">Components Overview</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1faaa">🪪</span> Address &#x26; Identity</td><td></td><td></td><td><a href="/builders/opencohort/framework/address-and-identity">Address &amp; Identity</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f680">🚀</span> Use Case</td><td></td><td></td><td><a href="/builders/opencohort/framework/use-case">Use Case</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f5a5">🖥️</span> Developer</td><td></td><td></td><td><a href="/builders/opencohort/framework/developer">Developer</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f4c4">📄</span> Public Prover Lists</td><td></td><td></td><td><a href="/builders/opencohort/framework/public-prover-lists">Public Prover Lists</a></td></tr></tbody></table>


# Merkle Tree & Merkle Proof

Merkle Tree and Merkle Proof are large-scale data validation methods and are used in a variety of fields. You can find verified code for them in OpenZeppelin, and you can find related material on Wikipedia and other websites. This page briefly describes Merkle Tree and Merkle Proof, and covers their use in OpenCohort.

* **Reference**
  * [https://github.com/OpenZeppelin/merkle-tree<br>](https://github.com/OpenZeppelin/merkle-tree)
  * [https://docs.openzeppelin.com/contracts/5.x/api/utils#MerkleProof<br>](https://docs.openzeppelin.com/contracts/5.x/api/utils#MerkleProof)
  * <https://en.wikipedia.org/wiki/Merkle_tree>

## Waht is Merkle Proof?

**Merkle Proof** is a method for verifying the integrity of data using a Merkle Tree. By organizing a large set of data into a binary tree structure (a Merkle tree), you can efficiently and securely verify that a particular piece of data is included in this large set. For example, in distributed systems like blockchains, Merkle Proof is used to verify whether a transaction is included in a particular block. The advantage of this method is that it allows verification using only a few hash values, without needing to download the entire dataset or check all nodes.

## The Concept of Merkle Tree &#x20;

A Merkle Tree is a data structure that organizes data into a binary tree structure. The basic concepts are as follows:

1. **Leaf Node**: The lowest node in the tree, each of which contains a hash value of raw data (such as a transaction or file block).
2. **Parent Node**: These nodes are calculated by combining the hash values of two child nodes, representing higher levels in the tree.
3. **Root Hash**: The node at the top of the tree, representing the hash value of the entire tree. It plays a key role in ensuring the integrity of the entire dataset.

## How Merkle Proof Works&#x20;

Merkle Proof allows verification of whether a particular leaf node (an address or identity in OpenCohort) is part of the Merkle Tree using only a few hash values. The process works as follows:

1. **Data to be verified (Leaf Node)**: The hash of the data to be verified is provided.
2. **Proof Path**: Hash values along the path to the root hash are provided. This includes the hash values of sibling nodes along the path.
3. **Root Hash**: The root hash representing the entire Merkle Tree is provided.

The verifier then uses the provided data and proof path to compute the root hash. If the computed root hash matches the provided root hash, it proves that the data is part of the Merkle Tree.

## Benefits of Merkle Proof

* Increased Verification Efficiency: Merkle Proof enables fast verification of large datasets using only a few hash values, reducing the need to download the entire dataset. This helps significantly reduce network costs and verification time.<br>
* Ensured Data Integrity: Merkle Proof efficiently verifies data without tampering. If the provided root hash and proof path do not match, the verification fails, ensuring the integrity of the data.

## Merkle Tree in OpenCohort

In OpenCohort, Merkle Trees play a crucial role. A 'Cohort' contains a Merkle Root Hash representing the aggregated dataset for each time frame in a rollup. This enables reference to the aggregated data for all times, making it accessible for smart contracts on the blockchain to use any point-in-time data.

#### Standard Implementation

* OpenCohort uses the Merkle Proof implementation from OpenZeppelin.
* The method for constructing Merkle Trees in OpenCohort adopts Uniswap’s approach:
  * It hashes the index, bytes(20), and weight to prevent '64 bytes attack'.
  * [Uniswap Merkle Distributor](https://github.com/Uniswap/merkle-distributor)
* OpenCohort provides a distribution logic forked from Uniswap, utilizing Merkle Tree and Merkle Proof mechanisms for efficient allocation.

#### Address & Identity

* In OpenCohort, Merkle Leaves are not limited to representing addresses with bytes(20). This opens up vast possibilities for bridging the legacy world and blockchain.
* Bytes(20) not restricted to addresses may require additional signatures for proof verification.
* For further details, refer to [the Address & Identity section](https://wiki.prod.ozys.work/wiki/spaces/PJSilicon/pages/13500952/Address+Identity).

#### References

* OpenCohort Airdrop: <https://github.com/0xSilicon/opencohort-contracts/blob/main/contracts/airdrop/OpenCohortAirdrop.sol>

<br>


# Participants

OpenCohort involves a variety of participants. Understanding these entities, from the 'Silicon Blockchain' to 'Individual Users,' is essential for developing and applying the protocol. Based on this understanding, decide how you want to engage with OpenCohort.

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FOTPhn4qkmhObTWHgtbEV%2FParticipants%20-%20%EB%B3%B5%EC%82%AC%EB%B3%B8.png?alt=media&amp;token=b42feaea-28a7-4ff2-91a5-8262569d2f41" alt=""><figcaption></figcaption></figure>

## Silicon Blockchain

The Silicon Blockchain is a key sponsor supporting the decentralized OpenCohort protocol. Through OpenCohort, Cohort NFTs based on the Silicon Blockchain are minted, and the Merkle Root Hash is stored. The Prover URI is recorded on the blockchain, and the incentive protocol that users receive for participating in the Cohort is also executed on the blockchain. Additionally, the Silicon Blockchain supports OpenNameTag to enhance the value of public address information.

## Manager

`The Manager` is a decentralized service provider responsible for managing Cohort memberships. Key functions include:

* `Partners` can add, modify, or snapshot their customer community and points in the Cohort following the `Manager` protocol.
* `Partners` (typically) submit Identity Mapping Signatures through the `Manager`.
* `The Manager` stores and manages membership and snapshot history for each Cohort.
* `The Manager` generates the MerkleRootHash of the snapshot and collects information for rollups. `The Manager` may also perform the rollup.
* `The Manager` provides finalized Cohort snapshot information, rollup information, and Identity Mapping details to `the Prover`.

## Prover

`The Prover` plays a role in providing finalized Cohort information to `users` and the ecosystem in a static format. `The Prover` can be an API or a decentralized static file system.

* `Users` can verify `Prover` information through the Cohort NFT recorded on the blockchain.
* `The Prover` provides Proof of Cohort membership and points, which are proofs related to the Merkle Hash of a specific snapshot.
* `The Prover` offers Identity Signatures provided by the Manager to `users` (users must be aware of their identity).
* `The Prover` provides the Merkle Root Hash for the Cohort rollup, other attribute values, and the Partner's signature information. Anyone can use these signatures to roll up Cohort information on the blockchain.
* `The Prover` provides dump forms of Proof information, snapshot membership data, and Identity Signature information, allowing anyone to query and verify the Merkle Tree.

## Partner

`Partners` play a crucial role in expanding their customer `(User)` communities into the Web3 space. Through OpenCohort, `Partners` transparently manage memberships, communities, and identity verification while promoting community participation through incentives. They support a smooth transition and growth of their user community in Web3, encouraging interaction.

* `Partners` can issue Cohort NFTs and manage multiple Cohorts (e.g., `Best Player` Cohort, `Most Visitor` Cohort, etc.).
* `Partners` manage Cohort membership and points through `the Manager`.
* Even if a user does not have a blockchain wallet, `the Partner` can manage the Cohort membership based on the user’s identity. However, only the Partner can determine whether the identity contains personal data, and OpenCohort and other participants are not responsible for the exposure of public data recorded on the blockchain.
* `Partners` can trustlessly disclose Signature information that maps the provided identity to the blockchain wallet address where the actual incentive will be received.
* `Partners` take snapshots of Cohort memberships and provide snapshot signature information. This signature information is used for blockchain rollups, and all snapshot history can be checked on the blockchain.

## Builder

`Builders` play a central role in driving innovation in the Web3 ecosystem by using the OpenCohort protocol to create new projects and communities. `Builders` can release new projects (tokens or exclusive content) to designated users. They also form new user communities by strategically communicating with targeted users through promotions and incentives. The participants of `Builder` projects become the foundation for the continued growth of the project and ecosystem through a virtuous cycle of converting into new Cohorts.

* `Builders` can perform airdrops to membership targets supplied by `Partners`. They can use the standard airdrop protocol or utilize `the Airdrop Helper`.
* `Builders` can also conduct airdrops targeting past membership data.
* `Builders` can offer incentives to Cohorts with assets other than their project assets.
* `Builders`, being `Partners` who manage community memberships, can also use services that automatically manage platform community memberships into Cohorts.
* `Builders` offer grants for membership information provided by `Partners`. `Partners` can receive grants from `Builders` as their community grows.

## Users

Through OpenCohort, `users` can express their identity and membership based on activities in games, media, social interactions, and more across Web2 and Web3 spaces, connecting with other users with similar interests. These social interactions facilitate the growth of Web3 communities and the foundation for new projects, fostering the growth of the Web3 ecosystem. Moreover, `users` create a positive feedback loop of active participation and growth in the Web3 ecosystem by earning benefits and incentives for their activities.

* `Users` can earn blockchain-based incentives for their activity histories on various platforms.
* The process centered around user memberships in the Web3 ecosystem through OpenCohort is as follows: each platform offers user activity-based membership as a Cohort through OpenCohort as a `Partner`. `Builders` provide incentives to the Cohort. `Users` can obtain Proof through `the Prover` or Identity Signatures as needed.

## Airdrop Helper

While OpenCohort provides various opportunities for all participants, it may be difficult for all users to easily understand and utilize the protocol. This is where `the Airdrop Helper` aids `Builders` interested in forming communities in Web3 to focus on their projects and activates the various Cohorts provided by `Partners`. `Airdrop Helper` can independently generate platform Cohorts as needed, encouraging more Builders to participate and leading the virtuous cycle of the ecosystem.

<br>


# Components Overview

## Base Component

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FefTKHdOpkBtoqeXSxgjf%2FBase%20Component(50).png?alt=media&amp;token=42d9bbac-4667-43ed-b8ee-787572bd72aa" alt=""><figcaption></figcaption></figure>

1. **Cohort NFT (ERC 721)**\
   \
   The Cohort is an NFT contract that extends the standard NFT on the blockchain. Each blockchain has a widely used Cohort NFT token deployed on it, and the Silicon blockchain also has a Cohort NFT issued by Silicon developers. Although anyone can issue a Cohort NFT token with the same functionality, it is recommended to use a common NFT to prevent ecosystem confusion.<br>
2. **Cohort Item**\
   \
   `A Partner` can mint a Cohort Item for their community and define its basic attributes. One NFT Item represents one Cohort, and the membership and points for this Cohort are managed through a Manager. Most of the information, including basic attributes, is recorded in the Cohort Item, **but the membership list is not stored on the blockchain**. Instead, only the representative value of the list, the MerkleRootHash, is recorded.<br>
3. **Member**\
   \
   `A Partner` can manage the membership list for their owned and minted Cohort Item through `the Manager`. When providing the membership list, Partners can choose between blockchain wallet addresses or a custom identity managed by them, and this decision is made when creating the Cohort Item.\
   \
   `A Partner` can have only one identity mapping, which means that the same custom identity must be used for the membership lists of all Cohort Items owned by that Partner. For more details, refer to :page\_facing\_up:[Address Identity](https://wiki.prod.ozys.work/wiki/spaces/PJSilicon/pages/13500952/Address+Identity).\
   Members in a Cohort have membership status as well as additional point information. The points are managed by the Partner and are assigned based on the policies set by the Partner. The usage of points is determined by the Builder.<br>

## MerkleProof Component

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FY4Bgh441Vdf5A5diPBxH%2FMerkle%20Component.png?alt=media&amp;token=527d3aaf-761a-46ab-b73c-25b57b4df7df" alt=""><figcaption></figcaption></figure>

4. **Snapshot**\
   `A Partner` can request the creation of MerkleTree information to finalize their managed membership and upload it to the blockchain. `The Manager` generates the MerkleRootHash based on the Cohort membership list at the time of the request and asks `the Partner` for signature information required for Rollup. \
   \
   Once the correct signature is completed, `the Manager` delivers the MerkleTree information of the Cohort to the designated `Prover`. `The Prover` compiles the MerkleProof information and publicly provides the data needed for Rollup.\
   \
   The Snapshot includes nonce information and signature details, and the nonce must continue to increase to Rollup the Cohort data on-chain.<br>
5. **Rollup**\
   Rollup is the process of recording the MerkleRootHash, which is the representative value of large memberships managed by the OpenCohort system, on-chain. This significantly improves efficiency by allowing the blockchain to verify summarized data instead of processing individual memberships, minimizing the membership management costs for `the Partner`.\
   \
   This method plays a crucial role in expanding the blockchain’s processing capacity while maintaining security and decentralization. Data that is not Rolled-up cannot be used on-chain, and Snapshot information must be Rolled-up for it to be effectively used on the blockchain. With the Rollup Signature provided by the Prover, anyone can Rollup the Cohort Snapshot to the blockchain, `not just the Partner`.\
   \
   Cohort Items store records of all Snapshots, enabling the use of specific data from past points in time.

## Airdrop Component

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FAaIYcSyZMhhjJnlaad0O%2FAirdrop%20Component.png?alt=media&amp;token=522b045b-f044-4b88-abe5-477369047557" alt=""><figcaption></figcaption></figure>

6. **AirdropDeployer**\
   The data of various `Partners` managed on the blockchain through the OpenCohort system can be utilized in multiple ways, with one of the most representative use cases being Airdrop incentives through membership and point proof.\
   \
   OpenCohort supports various types of Airdrops utilizing Cohorts, allowing `Users` to claim incentives provided by `Builders`. The Airdrop Deployer developed by Silicon developers has been deployed on the Silicon blockchain and can be used by anyone with knowledge of the blockchain, including `Builders` and `Airdrop Helpers`.<br>
7. **Airdrop SBT (ERC 721 & ERC 5192)**\
   Airdrop is an NFT contract deployed on the blockchain that extends the standard NFT and implements the SoulBound Token (SBT) under the ERC-5192 standard. The Airdrop Contract supports four types of Airdrops (Weight, Count, Constant, Unit), enabling `Builders` to select the most suitable incentive model for their project and efficiently allocate incentive resources. Unlike Cohort NFTs, which use a single minted Item, Airdrops issue new Airdrop SBTs for each incentive setting.\
   \
   `Partners` can include users without blockchain wallets as Airdrop recipients through identity mapping. Additionally, `users` who generate wallets via Account Abstraction can claim Airdrop incentives without ETH for gas fees and deploy the Account Abstraction wallet on the blockchain simultaneously. This allows access to the blockchain even without initial assets, encouraging a wider variety of community users to easily enter the Web3 environment of OpenCohort.<br>
8. **Airdrop SBT Item**\
   An Airdrop SBT Item is automatically issued to `users` who receive a specific Airdrop incentive. This Airdrop SBT Item, issued to `the user`, serves as an on-chain record reflecting their activity and identity, and offers additional rewards beyond the Airdrop incentive. Furthermore, `users` who continuously contribute to the project and community can receive additional incentives based on their previously issued Airdrop SBT Items, promoting active participation and growth in the Web3 projects and communities, thereby fostering a positive feedback loop.


# Address & Identity

## Win-Win Condition

The Win-Win condition represents the utilization strategy for each participant in OpenCohort. This requires mutual cooperation between participants, so that each participant can leverage OpenCohort to achieve their goals and maximize benefits. When the Win-Win condition is met, participants can create optimal incentive opportunities while fostering the activation of the community and ecosystem.

* **Partner**: Partners aim to boost community engagement by offering incentive opportunities through OpenCohort to their community members.
* **Builder**: Builders utilize OpenCohort to help scale their project by onboarding community members who are unfamiliar with blockchain to the Web3 project.
* **User**: The user does not wish to engage in additional activities to receive incentives and already feels fatigued by similar reward programs from various projects. If the achievements and activities the user has already accomplished can be recognized in Web3, it would bring greater satisfaction.
* **Silicon Blockchain**: Silicon aims to facilitate entry into Web3 by making it easy for participants to obtain incentives without complicated wallet creation procedures or transaction fees.
* Additionally, each participant seeks to minimize costs incurred in this process.

## Solution

Through Address & Identity Mapping, the Win-Win condition of each participant can be achieved.

* **Partner**: When creating a Cohort, Partners can use the Identity format instead of an Address. When Partners offer memberships, they use Manager to provide a Normalized Identity instead of an Address, which is represented in the format specified by the Partner. Externally, the Identity may appear as an Address.
* **Partner**: When a member of a particular Identity creates a blockchain wallet, the partner can map the wallet Address to that Identity through the Manager API.
* **Builder**: By managing a Cohort with Identities, Builders can provide airdrop incentives to members who do not have wallets. Even without a wallet, members with a specific Identity can trustlessly confirm incentives on the blockchain, allowing Builders to manage airdrop incentives more efficiently.
* **User**: Users can receive incentives based on their previous contributions or community activity, without the need for complex wallet creation steps.
* This process may slightly increase computing costs within the Manager or Prover's Storage, but the overall impact is minimal compared to the total data size.

## Principle: Merkle Leaf Component Expansion

In the OpenCohort protocol, the membership components that serve as leaves of the Merkle Tree are structured as follows. Each participant can modify this structure as needed, but OpenCohort’s default API is based on the structure below:

* `[uint256 index, bytes20 address, uint256 weight]`

In this structure, the ‘address’ or ‘weight’ fields are not strictly required to be used for their intended purposes. Each field’s data can be utilized flexibly based on the participant’s choice. This allows OpenCohort to expand the concept of an 'address' to encompass not only blockchain addresses but also a flexible usage of the 1.46e+48 Number space in the bytes20 format.

## Principle: Identity Mapping Signature

To use Cohorts on-chain, membership proof for bytes20 Identity is required. OpenCohort provides a signing feature that allows `Partners` to prove the mapping between Identity and Address. This enables the verification of Cohort membership across various on-chain applications, including airdrops and governance.

`Partners` provide a single Identity Mapping for each case. `Users` can obtain mapping information through `the Prover` and utilize it on the blockchain.

In summary, on-chain code such as Airdrop uses Proof to prove Cohort membership, and the connection between Identity and Address can be verified through a Mapping Signature.

## Signer

In most cases, the entity that provides the identity mapping for a Cohort is `the Partner`. `The Partner` has full authority over providing membership and can link the Identity to a blockchain address, and the Airdrop has full control over which recipients to offer the incentive to. Therefore, the party offering the airdrop has complete authority to choose the recipients from the published Cohort membership list. If necessary, they can create a separate Cohort for the airdrop. However, if the existing Cohort’s Identity is used, a potential issue arises where the Cohort Owner and the Identity Mapping Signature provider's addresses differ.

To address this issue, OpenCohort provides the ability to set up a separate identity mapping signature provider for the airdrop target cohort. In this setup, signer will be the signature provider.

## OpenIdentityRegistry

The Identity Mapping Signature is a value managed solely by `the Partner` (Signer). In cases of wallet loss or hacking, the Signer can change the Address mapped to a specific Identity at any time.\
However, this creates a problem where the previous Signature value is constantly in circulation. To prevent this, OpenCohort offers the following features via the OpenIdentityRegistry:

* Signers can register Addresses that are no longer supported.
* Delegates can register revoked Addresses on behalf of the Signer, using the Signer’s signature.
* When using Identity Mapping Signatures for applications like airdrops, it is possible to check in the Registry whether an Address has been revoked by a specific Signer.

## Precautions

* `Partners` should ensure that no personal information is included in the data disclosed via `Provers`. Due to the nature of blockchain, information cannot be deleted or modified once information is disclosed. Any legal liability related to personal information rests with Partners, in compliance with relevant laws and regulations, rather than with OpenCohort or the Silicon Network.
* `Signers` are responsible for managing Signatures for the same Identity. When the mapped Address changes and the previous Signature value is exposed, issues like duplicate receipt or Signature reuse may occur. Therefore, `Signers` should exercise particular caution in protecting their private keys.


# Use Case

## Open Cohort

The Merkle Tree in OpenCohort serves as an efficient method for proving and ensuring data integrity, supporting a variety of data validation. OpenCohort extends the existing Merkle data, enabling it to be widely utilized not only for address validation, but also by a community of partners with unique identities and builders looking to enforce fine-grained incentives.

***

### On-Chain Use Cases

Merkle Tree proofs are widely used across blockchain protocols, including leading dApps like Uniswap, to verify on-chain data safely and efficiently.

1. **Proof of Membership and Points**\
   Merkle Trees are useful for verifying that a specific user is included in a data set, making it easy to confirm membership without complex calculations.
   * **Token Airdrops**
     * Merkle Trees are used to validate whether a specific user is eligible for a token airdrop. If the airdrop recipient list is structured as a Merkle Tree, users can submit a proof (Merkle Proof) for their address to claim the airdrop.
     * OpenCohort supports proving eligibility based on various identity types, not just addresses.<br>
   * **Proof of Voting Rights and Other Entitlements**
     * Merkle Proofs can validate that a user’s address is part of a list with specific rights, such as voting rights. This allows voters to confirm that their address is in the authorized voter list, ensuring the integrity of on-chain voting systems. This is similar to the "proof of eligibility" in off-chain environments, as discussed below.<br>
   * **Points Systems**
     * For projects or services that manage on-chain points based on user activity, Merkle Proofs can be used to offer additional incentives. Users can easily confirm and utilize points managed on-chain, making the system applicable across various contexts.
     * This system is similar to oracles, with the distinction that points are managed by a central entity.<br>
2. **Oracle Data Validation**\
   Merkle Trees can validate external data provided by oracles.
   * By converting the data provided by Oracle into a Merkle Tree structure, it is possible to guarantee the integrity of each data item and prove that the data has not been changed on the blockchain.
   * Storing large-scale data from oracles directly on-chain can be costly and inefficient. OpenCohort allows historical use of Rollup and proof methods using representative values (RootHash), enabling efficient on-chain use of diverse data, including past data.

***

### Off-Chain Use Cases

OpenCohort can also be applied in off-chain environments for efficient data validation.

1. **Proof of of Eligibility**\
   The OpenCohort protocol securely manages identity data mapped to the user's blockchain addresses.
   * Users can utilize OpenCohort to prove various qualifications in off-chain services and, in some cases, earn additional incentives.<br>
2. **Transaction History Verification**\
   OpenCohort allows verification of specific users’ transaction histories.
   * Even as part of large data sets, transaction histories can be validated with Merkle Proofs without storing the entire data on-chain.
   * OpenCohort enables validation of off-chain data, allowing specific transaction histories to be proven in off-chain environments using Merkle Proofs.<br>
3. **Data Integrity Verification**
   * OpenCohort can verify that data has not been tampered with. While a typical Merkle Tree system only uses RootHash, OpenCohort can prove the integrity of on-chain data, including signatures on rollup data, even in untrusted environments (Trustless).
   * Participants can create Merkle Trees for different datasets, such as membership information or files, and use Merkle Proof to verify with the rolled-up data that the data has not been tampered with.

***

## Named Wallet

The Named Wallet system enables influencers, gamers, or other high-profile individuals to have a virtual wallet deployed on the blockchain. Instead of the traditional method of using a personal EVM address from the start, this system allows for the creation of a **virtual address** linked to the individual, and a contract-based wallet is deployed on the blockchain. Later, when the real person (or their representative) activates the wallet, they can claim ownership by transferring the wallet's control to their **actual EVM address**. This system provides flexibility, security, and ease of use for public figures while maintaining control until the activation phase.

### **Primary Use Case: Virtual Address Deployment, Management, and Ownership Transfer** <a href="#primary-use-case-virtual-address-deployment-management-and-ownership-transfer" id="primary-use-case-virtual-address-deployment-management-and-ownership-transfer"></a>

1. **Deployment of Wallet Contract with Virtual Address**
   * **Goal**: To deploy a contract-based wallet that is initially associated with a **virtual address** instead of an actual EVM address.
   * **Process**:
     * A **virtual address** is assigned to a specific user (e.g., an influencer, gamer, or any public figure).
     * Using this **virtual address**, a wallet contract is deployed by the **Signer** (via `deployWallet`), creating a contract that behaves like a personal wallet but is controlled by the **Signer** until activation.
     * This contract-based wallet can receive assets, hold tokens, and interact with other contracts, just like a typical wallet.
2. **Wallet Management by Signer**
   * **Goal**: Allow the **Signer** to configure, update, and manage the wallet contract before it is activated by the real user.
   * **Process**:
     * The **Signer** has administrative control over the wallet contract until the real user activates it.
     * **Signer** can modify wallet settings (e.g., tax rates, wallet information, add/remove properties) using functions like `changeTaxRate`, `changeInfo`, `addPropertyBatch`, and `removeProperty`.
     * **Signer** is also authorized to transfer funds or tokens to the wallet contract using `transferTo` or `transferTokenTo`.
3. **Ownership Transfer to Real EVM Address**
   * **Goal**: Allow the real user (e.g., influencer) to take full control of the wallet by transferring ownership from the **virtual address** to their **actual EVM address**.
   * **Process**:
     * Once the **Signer** has deployed the wallet and configured it, the real user (e.g., the influencer) can activate the wallet by signing a message that proves they are the legitimate owner of the **virtual address**.
     * The signature is verified via the `getDataHash` function, and the ownership is transferred to the user's actual EVM address via the `activateWallet` function.
     * After activation, the wallet contract is fully controlled by the real user and can be used for regular blockchain transactions (sending tokens, interacting with smart contracts, etc.).

### **Roles and Permissions** <a href="#roles-and-permissions" id="roles-and-permissions"></a>

1. **Signer Role**:
   * The **Signer** is responsible for deploying and managing wallet contracts. They can modify settings, transfer assets, and configure the wallet until the real user activates the wallet.
   * The **Signer** holds control over the contract during the setup phase, ensuring that the wallet is properly configured before it is transferred to the real user.
2. **Owner (Real User)**:
   * Once the wallet is activated, the real user (e.g., influencer or gamer) assumes control of the wallet.
   * The user’s **EVM address** becomes the official owner, allowing them to manage the wallet, send tokens, and interact with decentralized applications.

### **Example Use Cases for Named Wallet** <a href="#example-use-cases-for-named-wallet" id="example-use-cases-for-named-wallet"></a>

1. **Influencer or Gamer Wallets**:
   * A **Signer** deploys a wallet contract for a popular gamer or influencer using a **virtual address**.
   * The **Signer** configures the wallet and transfers tokens (e.g., donations or in-game currency) to the virtual wallet.
   * Later, the gamer or influencer activates the wallet by transferring ownership to their **real EVM address**, gaining full control.
2. **Corporate Wallets for Brands**:
   * A corporation can deploy a wallet for their brand or product, associated with a **virtual address**.
   * The **Signer** can manage the wallet, adding properties, transferring tokens, and making updates.
   * The corporation’s representative (e.g., legal team) activates the wallet and takes full control by transferring ownership to the **company’s EVM address**.
3. **Charity or Crowdfunding Campaigns**:
   * A charity or crowdfunding campaign can deploy a wallet for their cause using a **virtual address**.
   * The **Signer** manages donations and token transfers to the wallet.
   * Once the charity is ready to take control, they activate the wallet by transferring ownership to the charity’s official **EVM address**.


# Developer

## Overview

### Forming Cohort

* OpenCohort is a separate layer closely interacting with the Silicon network to efficiently store and process extensive identity data of network participants.
* Each cohort representing NFT (called 'Cohort NFT') exists on the Silicon network, and anyone on-chain can mint them.
* Address information and attributes associated with each cohort can be managed in OpenCohort. They are rolled up into the Silicon network and stored with the rootHash value of the Cohort NFT at that specific point in time. This is akin to saving game progress to create separate save data. *(Roll-up is performed not in real-time but through the OpenCohort Manager, which generates a definitive list of associated addresses and manually performs the Roll-up.)*
* The list of addresses included in the rootHash of the Cohort NFT can vary at each point in time, and it is possible to query and utilize the list for specific points in the past.

***

### Airdrop

* You can execute an Airdrop contract targeting the rootHash of a specific 'Cohort NFT' stored at a particular point in time.
* Users included in the rootHash can obtain their proof by comparing it with the Prover information of the corresponding Cohort NFT, allowing them to claim and mint airdrop tokens. *(It is also possible to distribute specific quantities by verifying each individual's proof.)*
* Users receive the airdrop-targeted 'tokens' along with 'SBT' to prove they received the airdrop.

<table data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f4d4">📔</span> Cohort</td><td></td><td></td><td><a href="/builders/opencohort/framework/developer/cohort">Cohort</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="1f4dc">📜</span> Protocol</td><td></td><td></td><td><a href="/builders/opencohort/framework/developer/protocol">Protocol</a></td></tr><tr><td><span data-gb-custom-inline data-tag="emoji" data-code="2708">✈️</span> Airdrop</td><td></td><td></td><td><a href="/builders/opencohort/framework/developer/airdrop">Airdrop</a></td></tr></tbody></table>


# Cohort

The Cohort is a blockchain smart contract designed for the OpenCohort system. It functions as both an ERC-721 NFT and a Soulbound Token (SBT) implementing the ERC-5192 standard. The contract provides metadata and snapshot capabilities and defines multiple structures for storing Merkle Tree information.

## Code

* Github : [https://github.com/0xSilicon/opencohort-contracts](https://github.com/0xSilicon/opencohort-contracts/)

## Address

* Mainnet: `0x5bed204DFF313eFb26cfB8b2B2222140F4697BbE`
* Sepolia: `0x41b00d0b361190D8e3539f386Cf8A11dc8aEddF5`

## Standard Implementations

The standard aspects of ERC-721 and ERC-5192 that do not require specific understanding are omitted in the section below.

## Data Structures

* **Enum CohortType**
  * This enum specifies whether to define the cohort of Address Type or Identity Type.<br>
* **Struct CohortMetadata**
  * This common structure is used to represent both general information about the Cohort item and details about snapshots.
  * For general item information, it defines standard NFT attributes via tokenURI and specifies the Cohort type. It also references details about the latest rollup data, such as merkleRoot, totalWeight, totalCount, and prover.
  * For snapshot metadata, it contains information for each snapshot, including merkleRoot, totalWeight, totalCount, and the prover.
  * Structure Variables
    * `cohortType`: Specifies the type of Cohort.
    * `tokenURI`: Standard token URI.
    * `merkleRoot`: Merkle Tree Root Hash for the snapshot.
    * `totalWeight`: Total weight of the snapshot.
    * `totalCount`: Total member count in the snapshot.
    * `prover`: Prover that provides snapshot data.

## Events

* MetadataUpdate
  * Triggered when the metadata of a specific Cohort is updated.
  * Parameters
    * `tokenId`: Unique ID of the token whose metadata was updated.<br>
* SetCohortMetadata
  * Triggered when Cohort metadata is set.
  * Parameters
    * `tokenId`: Unique ID of the token for which metadata is set.
    * `nonce`: Unique value for the metadata.
    * `metadata`: Contents of the set Cohort metadata.
    * `snapShotTime`: Timestamp of the snapshot.<br>
* SetCohortGrant
  * Triggered when the grant rate for a specific Cohort item is set.
  * Parameters
    * `tokenId`: Unique ID of the token for which the grant is set.
    * `cohortGrant`: Set information regarding the Cohort grant rate.

## Read-Only Functions

* **cohortType**
  * Returns the cohort type of a specific token.
  * Parameters
    * `tokenId`: The unique ID of the token to check the type for.
  * Return Value: The cohort type of the specified token.<br>

* **grant**
  * Returns the grant rate information for a specific token's cohort. The accuracy of this rate is determined by GRANT\_RATE\_DENOMINATOR, and the maximum rate is set by MAX\_GRANT\_RATE.
  * Parameters
    * `tokenId`: The unique ID of the token to check the grant for.
  * Return Value: The grant rate information for the specified token's cohort.<br>

* **metadata**
  * Returns the metadata of a specific token.
  * Parameters
    * `tokenId`: The unique ID of the token to check the metadata for.
  * Return Value: The metadata of the specified token.<br>

* **metadataNonce**
  * Returns the metadata nonce for a specific token. This is used to verify the nonce for the next rollup.
  * Parameters
    * `tokenId`: The unique ID of the token to check the metadata nonce for.
  * Return Value: The metadata nonce of the specified token.<br>

* **getLastSnapShotTime**
  * Returns the timestamp of the last rollup snapshot for a specific token.
  * Parameters
    * `tokenId`: The unique ID of the token to check the snapshot timestamp for.
  * Return Value: The timestamp of the last snapshot.<br>

* **getExactTimeSnapShot**
  * Returns the exact snapshot metadata for a specific timestamp.
  * Parameters
    * `tokenId`: The unique ID of the token to check the snapshot for.
    * `timestamp`: The timestamp to verify.
  * Return Value: The snapshot metadata for the specified timestamp.

* **getSnapShot**
  * Returns snapshot data for a specific timestamp.
  * Parameters
    * `tokenId`: The unique ID of the token to check the snapshot for.
    * `timestamp`: The timestamp to verify.
  * Return Value: The snapshot metadata for the specified timestamp.

* getChainId
  * Returns the current chain ID.
  * Return Value: The chain ID.

## State-Changing Functions

* mint
  * Mints a new cohort token. Any user can issue a new cohort.
    * Parameters
      * `cohortMetadata`: Metadata of the token to be minted.
  * Return Value: The unique ID of the minted token.<br>
* setTokenURI
  * Sets the URI for a specific token.
    * Parameters
      * `tokenId`: The unique ID of the token for which to set the URI.
      * `tokenURI_`: The URI string to be set.<br>
* setCohortGrant
  * Sets the cohort grant rate for a specific token.
    * Parameters
      * `tokenId`: The unique ID of the token for which to set the grant.
      * `cohortGrant`: The cohort grant rate information to be set.<br>
* rollupWithSignature
  * Processes a rollup with a signature, utilizing snapshot signature information provided by the partner as Manager.
    * Parameters
      * `tokenId`: The unique ID of the token to process the rollup for.
      * `cohortMetadata`: Specifies the cohort information.
      * `timestamp`: The snapshot timestamp.
      * `signature`: A signature to confirm that the snapshot to be rolled up was created by the owner.


# Protocol

The protocol manages Cohort Address and Identity memberships in OpenCohort, supports snapshot generation, and processes rollup information for these snapshots. It includes **the Manager** that processes snapshots to enable rollups, and **the Prover** that provides Merkle proofs and other necessary signatures based on the stored information.

**The Prover API URI** can be queried through the Cohort Metadata on the blockchain, and **Builders and Users** can use this API to help facilitate the incentive cycle.

{% content-ref url="/pages/ao0ya50kyjmC0GBDuxvX" %}
[Base API](/builders/opencohort/framework/developer/protocol/base-api)
{% endcontent-ref %}

{% content-ref url="/pages/bKHQmoJINia1cG7sHuQH" %}
[Manage API](/builders/opencohort/framework/developer/protocol/manage-api)
{% endcontent-ref %}

{% content-ref url="/pages/vr35FEitW56lBY8KUeaS" %}
[Prover API](/builders/opencohort/framework/developer/protocol/prover-api)
{% endcontent-ref %}


# Base API

## API Signatures

* The authorization signature uses 'Ethereum message signing', assuming the ChainID of the relevant chain (e.g., ETH: 1, Silicon Mainnet: 2355).
* For signatures used in snapshot submissions, verification is conducted using the ETH ChainID of 1 (the ChainID is included in the message).

## Basic Response

{% code lineNumbers="true" %}

```
{
  statusCode: number;
  message: string;
  data: ResponseData;
}
```

{% endcode %}

## Success

{% code lineNumbers="true" %}

```

{
	"statusCode": 200
	"data": {},
	"message": "success"
	
}
```

{% endcode %}

## Fail

{% code lineNumbers="true" %}

```
{
	"statusCode": 500
	"message": error_message
}
```

{% endcode %}

## Error Message List

The following are basic error messages. Additional error messages may be present depending on the handling within each method.

### Basic Validation

| Message                 | Description                                                                                                                                        |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| invalid\_target         | When `managerName` does not match the name of the requested Manager.                                                                               |
| request\_timeout        | Request timed out.                                                                                                                                 |
| used\_signature         | When the signature value has already been processed within the allotted time (to prevent double usage).                                            |
| invalid\_cohort         | When the `CohortId` in the request does not match the `CohortId` in the requestPath, or if the `CohortId` is invalid or the cohort does not exist. |
| invalid\_owner          | When the owner in the request is missing or does not match the Owner of the `CohortId`.                                                            |
| invalid\_method         | When the method is incorrect.                                                                                                                      |
| fail\_to\_authorization | When the authorization signature verified with the hash in the body does not match the Cohort Owner.                                               |

### Basic Method Validation

| Message            | Description                                                                                                      |
| ------------------ | ---------------------------------------------------------------------------------------------------------------- |
| invalid\_members   | When the members field is missing or not in a dictionary format.                                                 |
| exceed\_limit      | When the number of members being added exceeds the limit per request.                                            |
| too\_many\_members | When the total number of members, after attempted additions, exceeds the overall limit.                          |
| invalid\_address   | When one or more addresses in the members field have an incorrect format.                                        |
| invalid\_weight    | When the format of the weight in the members field is incorrect (must be an integer between 0 and `uint32.max`). |
| pending\_snapshot  | When an `add` request is sent during the snapshot `prepare` status, but a `submit` is expected.                  |

### Signature Generation Example

#### Example 1

{% code lineNumbers="true" %}

```
dataHash = keccak256(
		abi.encode(
				[string, address, uint256, address[], address[], bytes[], uint256],
				["OpenCohort:UpdateIdentity", cohort, chainId, identityList, addressList, signatureList, validUntil]
		)
);
signingHash = ERC191(dataHash);
```

{% endcode %}

#### Example 2&#x20;

{% code lineNumbers="true" %}

```
const {
    cohort,
    chainId,
    cohortId,
    snapshotTime,
    snapshotSignature,
    validUntil
} = dto;

const dataBytes = defaultAbiCoder.encode(
    ['string', 'address', 'uint256', 'uint256', 'uint256', 'bytes', 'uint256'],
    ['OpenCohort:Submit', cohort, chainId, cohortId, snapshotTime, snapshotSignature, validUntil]
);
const dataHash = keccak256(dataBytes);
const signingBytes = Buffer.concat([
    Buffer.from('\x19Ethereum Signed Message:\n32', 'ascii'),
    Buffer.from(dataHash.replace("0x",""), 'hex')
]);
const signingHash = keccak256(signingBytes);
```

{% endcode %}


# Manage API

If a Manager API’s role is solely focused on managing the cohort's foundational information, membership, and identity to provide snapshot rollup data to the Prover, it does not strictly need to follow the Protocol outlined on this page. Manager APIs may adopt more flexible permission structures, alternative verification methods, or even entirely different protocols depending on the provider. The descriptions below refer to the default Manager API as implemented by the Silicon development team.

* **Required Permissions:** Owner of the Cohort NFT item on the Silicon Network.
* **Permission Verification:** An HTTP header authorization containing the signature from the Cohort Item owner on `keccak256(request.body)`, valid within N seconds from the timestamp (N = 30 seconds).

## Add Members to a Cohort

#### POST /cohort/{cohortId}/member/add

* Adds an address to a specific cohort. If the address is already included, only its Weight is updated.

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "members":{
    "0x0000000000000000000000000000000000000400":1,
    "0x0000000000000000000000000000000000000500":2
  },
  "signature": "0xabcsafbasdb..."
}

// response
{
  "statusCode": 200,
  "data": affectedRowCount
}
```

{% endcode %}

## Removing Members from a Cohort:

#### POST /cohort/{cohortId}/member/remove <a href="#post-cohort-cohortid-member-remove" id="post-cohort-cohortid-member-remove"></a>

* Removes a specified address from a cohort. If the address does not exist in the cohort, the action is ignored.

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "members":[
    "0x0000000000000000000000000000000000000400", 
    "0x0000000000000000000000000000000000000500"
  ],
  "signature": "0xabiofsdnboiqnw..."
}

// response
{
  "statusCode": 200,
  "data": affectedRowCount
}
```

{% endcode %}

#### POST /cohort/{cohortId}/member/remove/all <a href="#post-cohort-cohortid-member-remove" id="post-cohort-cohortid-member-remove"></a>

* Removes all members from a cohort. If the address does not exist in the cohort, the action is ignored.

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "signature": "0xabiofsdnboiqnw..."
}

// response
{
  "statusCode": 200
  "data": affectedRowCount
}
```

{% endcode %}

## **Adding or Removing Identity Mapping in a Cohort**

#### POST /identity/update

* Maps an actual EOA to an address (Identity) within a specified cohort and submits a signature for the mapping.
* This function operates independently of the snapshot preparation status.
* Updating signatures for addresses not currently in the cohort is also supported.&#x20;
* If a new signature is received and is valid, it will overwrite any previous signature (e.g., EOA change).
* To delete a signature, set the EOA to the `0x0` address and submit a signed message. However, to prevent the reuse of a previous signature, it’s recommended to process it as a revocation.3

#### signature

The signature is signed as follows. This signature is used by the AirdropContract, which verifies it through the code below when collecting an ExtraSignature for airdrop targeting this cohort.

* Silicon Chain Cohort NFT Verification Code

{% code lineNumbers="true" %}

```
//import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
//import "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";

bytes32 hash = keccak256(abi.encode(address(cohortNFTAddress), getChainId(), identityEOA, addressEOA); 
bytes32 signingHash = MessageHashUtils.toEthSignedMessageHash(hash);
require(cohortOwner == ECDSA.recover(signingHash, signature));
```

{% endcode %}

* Each identity signature example

{% code lineNumbers="true" %}

```
const { defaultAbiCoder, keccak256 } = require('ethers/lib/utils');

(async() => {
    const cohortNFTAddress = "0x0000000000000000000000000000000000001234";
    const chainId = "1414";
    const uniqueKey = "0x000000000000000000000000000000000000dead";
    const target = "0x7777777777777777777777777777777777777777";

    const dataBytes = defaultAbiCoder.encode(
        ['string', 'address', 'uint256', 'address', 'address'],
        ['OpenCohort:Identity', cohortNFTAddress, chainId, uniqueKey, target]
    );
    console.log(`Data Bytes: ${dataBytes}\\n`);

    const dataHash = keccak256(dataBytes);
    console.log(`Data Hash: ${dataHash}\\n`);

    const signingBytes = Buffer.concat([
        Buffer.from('\\x19Ethereum Signed Message:\\n32', 'ascii'),
        Buffer.from(dataHash.replace("0x",""), 'hex')
    ])
    const signingHash = keccak256(signingBytes);
    console.log(`Signing Hash: ${signingHash}`);
})()


```

{% endcode %}

#### R**equest & Response**

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "signer":"0x12345..Address" // the address that signed the identity map below
  //"timestamp", "owner" etc. can be included but will be ignored if present 
  "identities":{
    // member address included in Cohort: [actual mapped EOA address, signature by Cohort Owner for mapping]
    "0x0000000000000000000000000000000000000400":["0xc6a2ad8cc6e4a7e08fc37cc5954be07d499e7654","0xSIGNATURE_R_S_V"], // V= 0x1b or 0x1c
    "0x0000000000000000000000000000000000000500":["0xAddress","0xSIGNATURE_R_S_V"]
  },
  
  "signature": "0xaoidsghngoiqwng..."
}

// fail response
{
  "statusCode":500,

  // Request method check
  "message":"invalid_identity",  // if the identity item is missing or not in the Dict<EOA, [EOA, SIG]> format
  "message":"invalid_signature", // if the SIGNATURE provided for any identity item is invalid or not from the signer (in this case, no request processing occurs; validation is prioritized)
}

```

{% endcode %}

## **Preparing a Cohort Snapshot**

#### POST /cohort/{cohortId}/snapshot/initialize

* Confirms nonce 0 snapshot data for a Cohort with a specified Hash and generates a snapshot.

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "signature": "0xabsabnoiqwengqwe..."
}

// response
// If the Merkle Root Hash generated from the addresses currently in the cohort matches the Merkle Root Hash set on-chain at nonce 0, it will immediately process the same actions as a snapshot submission.
{
  "statusCode":200,
  "message": "success"
}

// fail response
{
  "statusCode": error_code
  "message": error_message	
}

```

{% endcode %}

#### POST /cohort/{cohortId}/snapshot/prepare

* Requests the necessary information to create a finalized snapshot of the addresses currently under management. This is only possible if the RootHash for the Cohort item is generated.

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "snapshotTime": 1718266039,
  "signature": "0x1o2hnioadsngioqw..."
}

// response
{
  "statusCode": 200,
  "data": {
    "signatureInfo": {
      "address": "0x0000000000000000000000000000000000000700",
      "cohortId":{cohortId},
      "merkleRoot":"0xd0e15e9b115375b9725e57604121792e871db3128dc0c5683601d8288f755930",
      "timestamp":1718266039, // Snapshot reference time (for rollup, returned exactly as requested in the request).
      "prover":"<https://api-prover.silicon.network>",
      "totalWeight":10000000,
      "nonce":1, // The first snapshot begins at 1.
    },
    "expiredAt":1718266099 // Submit signatures within this time. 
  }
}

// fail response
{
  "successCod": error_code,
  "message": error_message	
}

```

{% endcode %}

## Confirmation of Cohort Snapshot

#### POST /cohort/{cohortId}/snapshot/submit

* Signatures for a pending snapshot are submitted via **prepare**, finalizing the snapshot data and storing the rollup data.

#### Signature

The signature is generated based on the **signatureInfo** provided in **prepare**, as shown below.

* Reference: Silicon Network Cohort NFT verification code

{% code lineNumbers="true" %}

```
//import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
//import "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";

bytes32 hash = keccak256(abi.encode("OpenCohort:Rollup", address(cohortNFTAddress), getChainId(), CohortId, nonce, merkleRoot, totalWeight, totalCount, prover, timestamp)); // tokenId == CohortId
bytes32 signingHash = MessageHashUtils.toEthSignedMessageHash(hash);
require(cohortOwner == ECDSA.recover(signingHash, signature));

```

{% endcode %}

* Example of a rollup signature

{% code lineNumbers="true" %}

```
const { defaultAbiCoder, keccak256 } = require('ethers/lib/utils');

(async() => {
    const cohortNFTAddress = "0x0000000000000000000000000000000000001234";
    const chainId = "1414";
    const tokenId = "1234";
    const nonce = "1";
    const merkleRoot = "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff";
    const totalWeight = "10000000000000000";
    const totalCount = "1000";
    const prover = "<https://prover.prover.prover>";
    const timestamp = "777777777";

    //bytes32 hash = keccak256(abi.encode(address(this), getChainId(), tokenId, nonce, merkleRoot, totalWeight, totalCount, prover, timestamp));
    const dataBytes = defaultAbiCoder.encode(
        ['string', 'address', 'uint256', 'uint256', 'uint256', 'bytes32', 'uint256',  'uint256', 'string', 'uint256'],
        ['OpenCohort:Rollup', cohortNFTAddress, chainId, cohortId, nonce, merkleRoot, totalWeight, totalCount, prover, timestamp]
    );
    console.log(`Data Bytes: ${dataBytes}\\n`);

    const dataHash = keccak256(dataBytes);
    console.log(`Data Hash: ${dataHash}\\n`);

    const signingBytes = Buffer.concat([
        Buffer.from('\\x19Ethereum Signed Message:\\n32', 'ascii'),
        Buffer.from(dataHash.replace("0x",""), 'hex')
    ])
    const signingHash = keccak256(signingBytes);
    console.log(`Signing Hash: ${signingHash}`);
})()


```

{% endcode %}

#### Request & Response

{% code lineNumbers="true" %}

```
// request
{
  "validUntil": 1718266039,
  "snapshotTime": 1718266039,
  "snapshotSignature": "0xasdghioegqoeipwmngoiadsjmg",
  "signature":"0x99502d2cd9ea810a6a70f16374466fc45795d2c06f74e48....be8d1982ab130f9c257c73a1955479de6aeacd132133d3f861b"
}

// response
{
  "statusCode":200,
  "message": "success"
}

// fail response
{
  "successCod": error_code,
  "message": error_message	
}

```

{% endcode %}


# Prover API

**A Prover** is a participant that receives confirmed Cohort information from **the Manager** and provides it in a static form. **The Prover** can be an API or a decentralized static file system. Unlike the Manager API, the Prover API protocol must utilize precise implementations. External systems must appropriately call the API according to the Prover version to obtain Proof.

### Release Versions <a href="#release-versions" id="release-versions"></a>

* 1.0.0 Initial Prover API

## Supported Prover Protocol Version

#### GET /prover/config <a href="#get-prover-config" id="get-prover-config"></a>

* This endpoint provides the version of the protocol offered by this Prover path.

{% code lineNumbers="true" %}

```
//response
{
	"statusCode": 200,
	"data": {
		"major": 1,
		"minor": 0,
		"patch": 0
	},
	"message": "success"
}

```

{% endcode %}

## Rollup Information Provision

#### GET /cohort/{cohortId}/rollup/info.json

* /cohort/{cohortId}/rollup/infos
* Provides the current information that the Prover is aware of for a specific cohort.
* application/json

{% code lineNumbers="true" %}

```
// response
{
  "successCode": 200,
  "data": {
    // Latest Snapshot
    "current": {
      "cohortId" : 1,
      "nonce": 12,
      "merkleRoot" : "0xd0e15e9b115375b9725e57604121792e871db3128dc0c5683601d8288f755930",
      "signature":"0x99502d2cd9ea810a6a70f16374466fc45795d2c06f74e48....be8d1982ab130f9c257c73a1955479de6aeacd132133d3f861b"
      "snapshotTime": 1724151658,
      "totalCount": 0,
      "totalWeight": "0",
      "prover": "<https://api-cohort.silicon.network.dev.ozys.work>",
      "status": 0,
      "createdAt": 1724119258
    },
    
    "latestRollup": [ 
      {
        "cohortId": 11,
        "nonce": 0,
        "merkleRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "signature": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "snapshotTime": 1724151658,
        "totalCount": 0,
        "totalWeight": "0",
        "prover": "<https://api-cohort.silicon.network.dev.ozys.work>",
        "status": 0,
        "createdAt": 1724119258
      }
    ]
  },
  "message": "success"
}

// fail response
// Responds in the same manner regardless of CohortId validation failure or other errors without error messages.
{
  "statusCode": error_code
}

```

{% endcode %}

## **Rollup Information Dump**

#### GET /cohort/{cohortId}/rollup/chunk/{n}.csv <a href="#get-cohort-cohortid-rollup-chunk-n00-.csv" id="get-cohort-cohortid-rollup-chunk-n00-.csv"></a>

* Provides the current information that the Prover is aware of for a specific cohort, in units of 100.
  * `/cohort/{cohortId}/rollup/chunk/0`: Provides Rollup information for nonce 0 to 99.
  * `/cohort/{cohortId}/rollup/chunk/1`: Provides Rollup information for nonce 100 to 199.
  * `/cohort/{cohortId}/rollup/chunk/100`: Provides Rollup information for nonce 10000 to 10099.<br>
* text/csv

{% code lineNumbers="true" %}

```
merkleRoot,singingTimestamp,signature,nonce
0x2222...8888,1718266000,0x9952...,0
0x3333...7777,1718266010,0x9953...,1
0x4444...6666,1718266020,0x9954...,2

```

{% endcode %}

## **Snapshot Basic Information Provision**

#### GET /prover/{0xMerkleRootHash}/member/count <a href="#get-prover-0xmerkleroothash-member-count" id="get-prover-0xmerkleroothash-member-count"></a>

* Provides the current information that the Prover is aware of for a specific cohort.

{% code lineNumbers="true" %}

```
// response
{
  "statusCode": 200,
  "data": {
    "merkleRoot": "0x8d6e8e9749e227c6fa9e06b342df074e71ac3e9e859db776b72fd801ea078f83",
    "totalCount": 4,
    "totalWeight": "10"
  },

	"message": "success"
}

// fail response
{
  "statusCode": error_code
}

```

{% endcode %}

#### GET /prover/{0xMerkleRootHash}/member/chunk/{n} <a href="#get-prover-0xmerkleroothash-member-chunk-n" id="get-prover-0xmerkleroothash-member-chunk-n"></a>

* Provides the current information that the Prover is aware of for a specific cohort.
* Query members for a specific merkle root in units of 10000
  * `/prover/{0xMerkleRootHash}/chunk/0`: Provides information for index 0 to 9999.
  * `/prover/{0xMerkleRootHash}/chunk/1`: Provides information for index 10000 to 19999.
  * `/prover/{0xMerkleRootHash}/chunk/2`: Provides information for index 20000 to 29999.

{% code lineNumbers="true" %}

```
// response
{
  "statusCode": 200,
  "data": {
    "participants": [
      {
        "address": "0xe265082f598d288e0cbafc009e2dcd1193b2cef1",
        "weight": "4"
      },
      {
        "address": "0x4774ba6738c1c739811744f5b6f8e3631825a88d",
        "weight": "3"
      },
      {
        "address": "0x2d761c33fc8e4d4a42c1379b817b84060e04de54",
        "weight": "2"
      },
      {
        "address": "0x29524b9eab6e86afa6891c89db62e7eba959bbf4",
        "weight": "1"
      }, ... 
    ]
  }
}

// fail response
{
  "statusCode": error_code
}

```

{% endcode %}

#### GET /prover/{0xMerkleRootHash}/info.json

* Provides information for a specific snapshot.
* application/json

{% code lineNumbers="true" %}

```
// response
{
  "successCode": 200,
  "data": {
    "totalCount": 11,
    "totalWeight": "72"
  }
}

// fail response
// Responds in the same manner regardless of merkleRootHash validation failure or other errors without error messages.
{
  "successCode":500
  "message": "internal_server_error"
}
```

{% endcode %}

## Snapshot Proof Information Dump

#### GET /prover/{0xMerkleRootHash}/chunk/{n}.csv

* Provides all associated addresses and information that can prove the merkleRootHash for a specific snapshot. Provided in units of 10000.
  * `/prover/{0xMerkleRootHash}/chunk/0.csv`: Provides information for index 1 to 10000.
  * `/prover/{0xMerkleRootHash}/chunk/1.csv`: Provides information for index 10001 to 20000.
  * `/prover/{0xMerkleRootHash}/chunk/2.csv`: Provides information for index 20001 to 30000.<br>
* text/csv

{% code lineNumbers="true" %}

```
index,address,weight
1,0xc6a2ad8cc6e4a7e08fc37cc5954be07d499e7654,0x445435
2,0x2f3713f388bc4b8b364a7a2d8d57c5ff4e054830,0x2454
3,0x662b67d00a13faf93254714dd601f5ed49ef2f51,0x1454
4,0xa323d7386b671e8799dca3582d6658fdcdcd940a,0x44
...

```

{% endcode %}

## **Snapshot Proof Information Retrieval**

#### GET /prover/{0xMerkleRootHash}/proof/{0xAddress}

* Provides the proof information for the requested address in the specified snapshot.
* application/json

{% code lineNumbers="true" %}

```
// response
{
  "statusCode": 200,
  "data": {
    "merkleRoot": "0x0000000000000006d5a671e01e395d007592733b7350b46496125d7d13e",
    "accountAddress": "0x000000000B1c24066781dcf6D5a2E0a8e580D1bd",
    "index": "0",
    "weight": "11",
    "proofs": [
      "0x48d95521cdc425f30d203135600000000000020e7833945b6b932590fe1d2b47",
      "0x775ba10acf69f4c46f9c4d06a000000000000dc3fa2e9179fd92dbe1d1755732",
      "0x2537ad083a72a378000000000000000000000fcdc6644b4eb70fa4707148e043",
      "0xbd53d4a35056a7fb1e031e2cbdac1e3a0d00000000000000629669c5a34bf6162"
    ]
  }
  
// fail response
{
  "statusCode": 500,
  "message": error_message
}
```

{% endcode %}

## **Identity-EOA Mapping Signature Information Retrieval**

#### GET /identity/signature/{signer}/{0xIdentity}

* Provides the proof information for the requested address in the specified snapshot.
* application/json

{% code lineNumbers="true" %}

```
{
  "successCode": 200,
  "data":{
    "signature":"0xd0e15e9b115375b9725e57604121792e871db3128dc0c5683601d8288f75593099f80a49c04a10a3158e13edf16c9f87f5e1cab776e930f036f6f00d2e2c4d401b"	
  }
}

// fail response
{
  "statusCode": error_code,
  "message": error_message
}
```

{% endcode %}

## **Identity-EOA Mapping Signature Information Dump**

#### GGET /identity/chunk/{signer}/{n}.csv

* Provides EOA mappings for all identities related to a specific cohort. Provided in units of 10000.
  * `/identity/{signer}/chunk/0.csv`: Provides the first mapping from 1 to 10000.
  * `/identity/{signer}/chunk/1.csv`: Provides mapping information from 10001 to 20000.
  * `/identity/{signer}/chunk/2.csv`: Provides mapping information from 20001 to 30000.<br>
* text/csv

{% code lineNumbers="true" %}

```
identity,address,signature
0x0000000000000000000000000000000000000400,0xc6a2ad8cc6e4a7e08fc37cc5954be07d499e7654,0xd0e15e9b115375b9725e57604121792e871db3128dc0c...b776e930f036f6f00d2e2c4d401b
0x0000000000000000000000000000000000000500,0x2f3713f388bc4b8b364a7a2d8d57c5ff4e054830,0x93099f80a49c040a49a10a3158e13edf3128dc9f87f5e1cab...d0e0c5683601d8288f755d1b
0x0000000000000000000000000000000000000600,0x662b67d00a13faf93254714dd601f5ed49ef2f51,0x792e810a3158e13edf8e13edf16c7f5e1cab77...115375b9725e576041213099f80a49c041c
0x0000000000000000000000000000000000000700,0xa323d7386b671e8799dca3582d6658fdcdcd940a,0x31f87f5e1cab776e930f...3158e513edf16c9d0e15e9b115375b9725e57604121792e871d1b
...

```

{% endcode %}


# Airdrop

The Airdrop feature represents an on-chain incentive that leverages OpenCohort. The Silicon development team provides deployers on the Silicon Network that perform four basic types of Airdrop distribution for Builders and Airdrop Helpers to utilize.&#x20;

* [Reward Type](/builders/opencohort/framework/developer/airdrop/reward-type)

The Airdrop Contract is an NFT based on ERC-721 that implements ERC-5192. It has functions such as cohort reference, Merkle Proof verification, and identity verification, and is the entity that provides incentives to users. Airdrop Deployer is a Factory Contract that issues Airdrop SBT based on specified airdrop configurations.

The signature verification for the airdrop follows the ERC-1271 standard, allowing signature verification via contracts without necessarily signing with an EOA that has a secp256k1 PrivateKey.

## Code

* GitHub:[ OpenCohortAirdrop.sol](https://github.com/0xSilicon/opencohort-contracts/blob/main/contracts/airdrop/OpenCohortAirdrop.sol)

## Address

* Mainnet: TBD

## Standard Implementations

Details regarding standard ERC-721 and ERC-5192 implementations are omitted, as no special understanding is required.

## Data Structures

* **enum RewardType**
  * Defines reward types. Airdrop currently supports Weight, Count, Constant, and Unit types.<br>
* **struct OpenCohortAirdropConfig**
  * A structure that allows querying all settings for the airdrop. Not all variables are used across every reward type.
  * Struct Variables
    * `rewardType`: Defines the type of reward.
    * `token`: Specifies the token for the airdrop.
    * `totalAmount`: Defines the total airdrop amount for Weight and Count types.
    * `claimableTime`: The start time at which users can claim their rewards.
    * `amountPer`: Defines the reward amount for Constant or Unit types.
    * `signer`: Specifies the identity cohort's mapping signature provider.
    * `name`: The name of the airdrop.
    * `description`: Description of the airdrop.
    * `image`: The main image representing the airdrop.
    * `baseURI`: The base URI for the airdrop SBT per NFT standards.

## Events

* SetCohortId
  * Triggered when setting the target cohort item for the airdrop.

    * Parameters
      * `cohortId`: The assigned cohort ID.
      * `cohortGrant`: Assigned cohort grant information.
      * `cohortGrantRateDenominator`: Denominator for the cohort grant rate.

* SetCohortTime
  * Parameters
    * `cohortTime`: The assigned cohort snapshot time.
    * `cohortMetadata`: Assigned cohort metadata.<br>

* Claimed
  * Parameters
    * `cohortTime`: The assigned cohort snapshot time.
    * `cohortMetadata`: Assigned cohort metadata.

## Read-Only Functions

* cohort
  * Return Value: The address of the currently set cohort.
* cohortMetadata
  * Return Value: Metadata of the currently set cohort item.
* cohortGrant
  * Return Value: Grant information for the current cohort partner.
* cohortGrantRateDenominator
  * Return Value: Denominator of the current cohort grant rate.
* openCohortAirdropConfig
  * Return Value: Current OpenCohort Airdrop settings.
* claimableTime
  * Return Value: Time at which claims can start.
* signer
  * Return Value: Address of the mapping signature provider for the identity cohort.
* image
  * Return Value: Image URL.
* cohortId
  * Return Value: The ID of the current cohort item.
* cohortTime
  * Return Value: Snapshot time of the current cohort.
* isClaimed
  * Parameters
    * `index`: Membership index in the Merkle Tree.
  * Return Value: Boolean indicating if the index has been claimed.

## State-Changing Functions

* setCohortId
  * Sets the cohort ID targeted by the airdrop and initiates necessary verification before triggering the SetCohortId event.
  * Parameters
    * `cohortId_`: Cohort ID to set.<br>
* setCohortTime
  * Resets the snapshot time within the target cohort and performs necessary verification before triggering the SetCohortTime event.
  * Parameters
    * `cohortTime_`: Cohort time to set.<br>
* claim
  * Allows users with membership in the target cohort to claim incentives using proof information from the Prover.
  * Parameters
    * `index`: Merkle Tree index.
    * `uniqueKey`: Address.
    * `weight`: Weight.
    * `proof`: Merkle proof for the claim.<br>
* claimBySignature
  * Same as claim, but for Identity Cohort, performs claim with additional validation of the Signer's Identity Mapping Signature.
  * Parameters
    * `index`: Merkle Tree index.
    * `uniqueKey`: Identity.
    * `weight`: Weight.
    * `proof`: Merkle proof for the claim.
    * `beneficiary`: Blockchain address of the identity mapping.
    * `signature`: Identity mapping signature.


# Reward Type

This page outlines the amount receivable for each of the four RewardTypes supported by Airdrop in OpenCohort.

## Weight

* Calculated based on the same snapshot.
* **Token amount receivable**: (Recipient’s `weight` within the snapshot) / (`totalWeight` of the snapshot ) \* (`totalAmount` of airdropped tokens)
* **Total eligible recipients**: `totalCount` of the snapshot (all Merkle Tree leaves)

## Count

* Calculated based on the same snapshot.
* **Token amount receivable**: (`totalAmount` of airdropped tokens) / (`totalCount` of the snapshot)
* **Total eligible recipients**: `totalCount` of the snapshot (all Merkle Tree leaves)

## Constant

* Calculated based on the same snapshot.
* **Token amount receivable**: A fixed amount of `amountPer` for each recipient
* **Total eligible recipients**: Up to `totalAmount / amountPer` of the first Merkle Tree leaves are eligible to receive tokens.
  * The first `totalAmount` / `amountPer` leaves in the Merkle Tree
* If the total number of cohort users is smaller than `totalAmount / amountPer`, then effectively every user receives tokens, making it function similarly to the **Count** type.

## Unit

* Calculated based on each user's activity (weight) in the latest snapshot.
* **Token Amount Receivable**: Users receive tokens in "amountPer" units based on their weight in the snapshot.
  * (`amountPer` of the Airdrop) \* (Recipient’s `weight` within the snapshot)
* **Total Eligible Recipients**: Determined on a first-come, first-served basis, but the exact number of eligible recipients isn’t fixed.
  * Total receivable weight: (`totalAmount` of airdropped tokens) / `amountPer`
* In this type, if a user’s weight increases, they may claim additional tokens according to their **added weight**\*`amountPer`.&#x20;
* However, if a user’s weight decreases, it does not reduce their previously claimed amount.


# Play OpenCohort

## Development Resources for Partners

&#x20;The **Silicon development team** understands the challenges that various partners face when working with **OpenCohort** and **Named Wallet**, two services that were previously unavailable. Community developers may have varying levels of blockchain knowledge based on their experiences and environments, and using **OpenCohort** and **Named Wallet** can involve more complexity than standard REST API integrations.

&#x20;To address this, the Silicon team plans to open-source **Play OpenCohort**. This will allow a diverse range of partners and community developers to manage their data as Cohorts more easily, and we will continue to provide resources to support ecosystem growth.

#### Official Resources

* nodejs : <https://github.com/0xSilicon/play-opencohort>

Tutorials offers the following features:

1. **Open Cohort**

* Cohort Management
  * Mint Cohort
  * Set Grant for Cohort
* Cohort Member Management & Airdrop
  * Add/Remove Members
  * Update Member Identity
  * Initialize/Prepare Snapshot
  * Submit Snapshot Signature
* Todo
  * Self Rollup
  * Revoke Identity

2. **Named Wallet**

* Deploy Wallet
* Check Wallet List
* Add/Remove Wallet Property
* Change Wallet Infomation
* Activate Wallet

&#x20;

3. **Cohort/Wallet Manager (Optional)**

The Manager Contract can manage both Cohort and Named Wallet with a single contract.

* Deploy Manager Contract
* Manager Contract Method Execution Examples

#### Community Resources

* Anyone can contribute code to OpenCohort or the Silicon Network.


# Named Wallet

## Code <a href="#code" id="code"></a>

* Github : [https://github.com/0xSilicon/opencohort-contracts](https://github.com/0xSilicon/opencohort-contracts/)

## Wallet Factory Contract <a href="#wallet-factory-contract" id="wallet-factory-contract"></a>

A Factory contract for deploying Named Wallets, providing an efficient and scalable solution for creating wallets with unique identities.

### Address (Factory)

* Mainnet: `0x5F53CD20ecE6605c62a3525E1031b1d87Be05D80`
* Sepolia: `0x507cBAFFaf2DbD1f872089E9aF8087F120C96710`

### Functions <a href="#functions" id="functions"></a>

#### deployWallet

deployWallet is used to deploy a new wallet contract, initializing it with the specified properties and returning the address of the newly deployed wallet contract.

```solidity
function deployWallet(
    address virtualAddress,
    WalletInfo memory walletInfo,
    string[] calldata keys,
    string[] calldata values
) external returns (address)
```

**Parameters:**

<table data-header-hidden><thead><tr><th width="193"></th><th width="158"></th><th></th></tr></thead><tbody><tr><td>Name</td><td>Type</td><td>Description</td></tr><tr><td><code>virtualAddress</code></td><td>address</td><td>The address associated with the virtual or designated environment where the wallet will be linked. (ex, <code>0x1234567890abcdef1234567890abcdef12345678</code>)</td></tr><tr><td><code>walletInfo</code></td><td><a href="https://wiki.prod.ozys.work/wiki/spaces/SD/pages/51478574/Silicon+docs#Data-Structures">WalletInfo</a></td><td>A structured data type (<code>WalletInfo</code>) containing essential wallet details.</td></tr><tr><td><code>keys</code></td><td>string[]</td><td>An array of strings representing the property keys of the wallet. <strong>It is mandatory that the array includes a key labeled</strong> <code>category</code></td></tr><tr><td><code>values</code></td><td>string[]</td><td>An array of strings representing the corresponding values for each key in the <code>keys</code> array. These values define the actual data or settings for the wallet's properties.</td></tr></tbody></table>

**Return Values**

<table data-header-hidden><thead><tr><th width="191"></th><th></th></tr></thead><tbody><tr><td>Type</td><td>Description</td></tr><tr><td>address</td><td>The address of the newly deployed wallet.</td></tr></tbody></table>

#### **computeAddress**

This function computes the address of a contract that will be deployed using the `CREATE2` opcode, based on the provided signer and virtual address. It returns the future address of the contract, which can be predicted before deployment.

{% code overflow="wrap" %}

```solidity
function computeAddress(
    address signer,
    address virtualAddress
) external view returns (address)
```

{% endcode %}

**Parameters:**

<table data-header-hidden><thead><tr><th width="199"></th><th width="142"></th><th></th></tr></thead><tbody><tr><td>Name</td><td>Type</td><td>Description</td></tr><tr><td><code>signer</code></td><td>address</td><td>The address of the signer, used to generate a unique salt for contract address computation.</td></tr><tr><td><code>virtualAddress</code></td><td>address</td><td>The address associated with the virtual environment or contract, used in combination with the signer to create a unique salt.</td></tr></tbody></table>

**Return Values**

<table data-header-hidden><thead><tr><th width="218"></th><th></th></tr></thead><tbody><tr><td>Type</td><td>Description</td></tr><tr><td>address</td><td>The predicted address of the contract that would be deployed using the <code>CREATE2</code> opcode.</td></tr></tbody></table>

#### **getDataHash**

This function computes a hash of the data that will be signed by the `signer` when activating a wallet.

```solidity
function getDataHash(
    address virtualAddress,
    address owner
) external view returns (bytes32)
```

Parameters:

<table data-header-hidden><thead><tr><th width="205"></th><th width="124"></th><th></th></tr></thead><tbody><tr><td>Name</td><td>Type</td><td>Description</td></tr><tr><td><code>virtualAddress</code></td><td>address</td><td>The address associated with the virtual environment or contract, used to identify the wallet in the context of the activation process.</td></tr><tr><td><code>owner</code></td><td>address</td><td>The address of the person who will take over the ownership of the wallet.</td></tr></tbody></table>

Return Values

<table data-header-hidden><thead><tr><th width="211"></th><th></th></tr></thead><tbody><tr><td>Type</td><td>Description</td></tr><tr><td>bytes32</td><td>The hash of the data that the <code>signer</code> will sign to activate the wallet.</td></tr></tbody></table>

&#x20;

#### **activateWallet**

This function allows the transfer of ownership of a wallet contract, deployed via `deployWallet`, from the `signer` to the `owner`. The wallet contract address is computed using the `computeAddress` function, and the ownership transfer is verified through the signature provided by the `signer`.

```solidity
function activateWallet(
    address signer,
    address virtualAddress,
    address owner,
    bytes calldata signature
) external
```

**Parameters:**

<table data-header-hidden><thead><tr><th width="199"></th><th width="154"></th><th></th></tr></thead><tbody><tr><td>Name</td><td>Type</td><td>Description</td></tr><tr><td><p><code>signer</code></p><p> </p></td><td>address</td><td>The address of the current wallet owner. This address signs the data to confirm the ownership transfer to the new <code>owner</code>.</td></tr><tr><td><code>virtualAddress</code></td><td>address</td><td>The address associated with the virtual environment or contract to which the wallet is linked.</td></tr><tr><td><code>owner</code></td><td>address</td><td>The address of the new wallet owner, who will receive ownership of the wallet.</td></tr><tr><td><code>signature</code></td><td>bytes32</td><td>The signature corresponding to the hash of the data that is generated by the <code>getDataHash</code> function.</td></tr></tbody></table>

## Named Wallet Contract

### Data Structures

#### Struct WalletInfo

```solidity
struct WalletInfo {
    string name;
    string image;
    string description;
    uint256 rate;
}
```

* The properties `name`, `image`, and `description` are stored in the `NameTagMetadata` struct ([l](https://github.com/0xSilicon/opencohort-contracts/blob/main/contracts/token/OpenNameTag.sol#L27)[ink](https://github.com/0xSilicon/opencohort-contracts/blob/56aaff9c49fc380416bc6cb674dabc79e91d319c/contracts/token/OpenNameTag.sol#L27)) of OpenNameTag.
* `rate`: Tax rate paid to the signer when assets are transferred from the wallet.

### Functions <a href="#functions.1" id="functions.1"></a>

#### **Asset Transfer Functions**

These functions allow the contract owner to transfer assets, either native tokens (ETH) or specific tokens, to other addresses.

**transferTo**

```solidity
transferTo(address to, uint256 amount) public payable onlyOwner
```

* **Description**: Transfers a specified amount of native cryptocurrency (ETH) to the given address. This function is restricted to the `owner`, ensuring that only the contract owner can transfer funds from the contract's balance.

&#x20;

**transferTokenTo**

```solidity
transferTokenTo(address token, address to, uint256 amount) public onlyOwner
```

* **Description**: Transfers a specified amount of a particular ERC20 token from the contract to the given address. The contract owner is the only one authorized to initiate token transfers, ensuring control over the assets.

#### **Configuration Functions**

These functions are used to modify and update various configurations or properties of the contract. They are generally restricted to specific roles, such as the `signer` or `factory`, to ensure proper authorization before making changes.

**changeTaxRate**

```solidity
function changeTaxRate(uint256 rate_) public onlySigner
```

* **Description**: Changes the tax rate of the system. Only the `signer` is allowed to modify the tax rate to ensure that only authorized parties can make financial adjustments.

&#x20;

**changeInfo**

{% code overflow="wrap" %}

```solidity
function changeInfo(string memory _name, string memory _image, string memory _description) public onlySigner
```

{% endcode %}

* **Description**: Updates the basic information of the contract, such as the name, image, and description. This function is restricted to the `signer` to prevent unauthorized changes to the contract's identity or metadata.

&#x20;

**addPropertyBatch**

{% code overflow="wrap" %}

```solidity
function addPropertyBatch(string[] calldata keys, string[] calldata values) external onlySignerOrFactory
```

{% endcode %}

* **Description**: Adds multiple properties (key-value pairs) to the contract in batch. This function can be called by either the `signer` or the `factory`, allowing for efficient property management by authorized roles.

&#x20;

**removeProperty**

```solidity
function removeProperty(string calldata key) external onlySigner
```

* **Description**: Removes a specific property identified by its key. Only the `signer` can remove properties, ensuring that property changes are made with proper authorization.


# Public Prover Lists

By using publicly available Prover endpoints, Partners and Builders can contribute to OpenCohort without needing to operate their own Provers. Operating a Prover typically requires both technical expertise and a deep understanding of the OpenCohort system.

To run a Prover, a backend web service infrastructure must be in place, including essential elements such as storage, monitoring, computing resources, and a database. Additional implementation components may be necessary, depending on specific requirements. Leveraging Public Provers allows Partners and Builders to focus on utilizing OpenCohort more efficiently, enhancing development productivity.

## Important Notes

* While Provers are managed in a decentralized manner, each Prover maintains independent information. Therefore, Merkle data for the Cohort may not be present across all Provers.
* Endpoint providers may impose rate limits or temporarily suspend service based on operational conditions or user traffic. These actions may occur without prior notice, so please exercise caution when managing or retrieving data.&#x20;
* Each endpoint does not guarantee a specific uptime or response time.

## Public Prover Endpoint <a href="#public-prover-endpoint" id="public-prover-endpoint"></a>

<table><thead><tr><th width="170">Service Provider</th><th width="291">Prover Endpoint</th><th width="284">Manager Endpoint</th><th>Remarks</th></tr></thead><tbody><tr><td>Silicon.network</td><td><a href="https://api-cohort.silicon.network/">https://api-cohort.silicon.network/</a></td><td><a href="https://api-cohort.silicon.network/">https://api-cohort.silicon.network/</a></td><td></td></tr></tbody></table>


# Network information

## Manual Network Configuration

|                    | Silicon Mainnet                                                                                                                                                                                       |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **URL**            | <ul><li><a href="https://rpc-sepolia.silicon.network"><https://rpc.silicon.network></a></li><li><a href="https://silicon-mainnet.nodeinfra.com"><https://silicon-mainnet.nodeinfra.com></a></li></ul> |
| **Chain ID**       | `2355`                                                                                                                                                                                                |
| **Curruncy**       | ETH                                                                                                                                                                                                   |
| **Block Explorer** | [Silicon Scope](https://scope.silicon.network)                                                                                                                                                        |
| **Bridge**         | [Silicon Bridge](https://bridge.silicon.network)                                                                                                                                                      |


# zkEVM contracts

The following addresses are canonical on the Silicon zkEVM

## L2 Contracts (Silicon Mainnet)

| Contract Name                   | Contract Address                             |
| ------------------------------- | -------------------------------------------- |
| Polygon zkEVM Deployer          | `0xCB19eDdE626906eB1EE52357a27F62dd519608C2` |
| Proxy Admin                     | `0x0F99738B2Fc14D77308337f3e2596b63aE7BCC4A` |
| Polygon zkEVM Bridge            | `0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe` |
| Polygon zkEVM GlobalExitRoot L2 | `0xa40d5f56745a118d0906a34e69aec8c0db1cb8fa` |
| Timelock                        | `0xBBa0935Fa93Eb23de7990b47F0D96a8f75766d13` |

## L1 Contracts (Ethereum Mainnet)

| Name                         | Address                                      |
| ---------------------------- | -------------------------------------------- |
| Pol Token                    | `0x455e53cbb86018ac2b8092fdcd39d8444affc3f6` |
| Polygon zkEVM                | `0x419dcd0f72ebafd3524b65a97ac96699c7fbebdb` |
| Polygon RollupManager        | `0x5132A183E9F3CB7C848b0AAC5Ae0c4f0491B7aB2` |
| Polygon zkEVM GlobalExitRoot | `0x580bda1e7a0cfae92fa7f6c20a3794f169ce3cfb` |
| DataCommitee                 | `0x24e09Ef4F69B6058E047EE5E709B345F3cA47F3A` |
| Polygon zkEVM Bridge         | `0x2a3dd3eb832af982ec71669e178424b10dca2ede` |

## Role Addresses

<table><thead><tr><th width="161">Role</th><th width="389">Address</th><th>Type of Key</th></tr></thead><tbody><tr><td>Admin</td><td><code>0xef5D7af5dbBeE845860E75cE8f8e8fE7F6e8dBF7</code></td><td>EOA managed by Silicon</td></tr><tr><td>Sequencer</td><td><code>0x47ed9538faA1522be7abD8a8BCAEc8d9C04Ed60D</code></td><td>EOA managed by Silicon</td></tr><tr><td>Aggregator<br>(AggLayer)</td><td><code>0x20A53dCb196cD2bcc14Ece01F358f1C849aA51dE</code></td><td>EOA managed by Polygon Labs</td></tr><tr><td>DataCommitee Members</td><td><p><code>0x113958b2E9FFDECC74EEDb206A12b5f1168164fb</code></p><p><br><code>0x88eb99475d70cCdB891171344c7Ee90688Fa134c</code></p></td><td>EOA managed by Silicon</td></tr><tr><td>DataCommitee Members</td><td><code>0x07389Ba04a3D39c04BAf605bF9d254B5EB0bC3e0</code></td><td>EOA managed by NodeInfra</td></tr></tbody></table>


# Testnet

Developing in Testnet environment.


# Setup

You must manually add the Sepolia Testnet and Silicon Sepolia networks by following the configuration details provided in the table below.

## Manual Network Configuration

<table><thead><tr><th width="179"></th><th>Silicon Sepolia</th><th>Ethereum Sepolia</th></tr></thead><tbody><tr><td><strong>URL</strong></td><td><a href="https://rpc-sepolia.node.0xsilicon.net:8545">https://rpc-sepolia.node.0xsilicon.net:8545</a></td><td><a href="https://rpc.sepolia.org">https://rpc.sepolia.org</a></td></tr><tr><td><strong>Chain ID</strong></td><td><code>1414</code></td><td><code>11155111</code></td></tr><tr><td><strong>Curruncy Symbol</strong></td><td>ETH</td><td>ETH</td></tr><tr><td><strong>Block Explorer</strong></td><td><a href="https://scope-sepolia.silicon.network">Silicon Testnet Scope</a></td><td><a href="https://sepolia.etherscan.io">Etherscan Sepolia</a></td></tr><tr><td><strong>Bridge</strong></td><td><a href="https://bridge-sepolia.silicon.network">Silicon Testnet Bridge</a></td><td></td></tr></tbody></table>


# Faucet

About Silicon Testnet Token

{% hint style="success" %}
**What is Fauchet?**

A testnet Faucet is a tool used on blockchain test networks to provide users with a test version of a specific cryptocurrency. Typically, users can obtain cryptocurrency for free on the testnet using a testnet Faucet. This allows developers and users to test applications and explore blockchain functionalities without spending real assets.
{% endhint %}

## How to get Silicon Testnet ETH?

ETH used on the Silicon Testnet is compatible with Sepolia ETH. Simply claim Sepolia ETH from various distribution websites and bridge it effortlessly to the Silicon Testnet!

### 1. Get Sepolia ETH

{% embed url="<https://cloud.google.com/application/web3/faucet/ethereum/sepolia>" %}

### 2. Bridge to Silicon Testnet

{% content-ref url="/pages/q4qWaV9XFWS2FLmbBwvf" %}
[Bridge](/builders/testnet/bridge)
{% endcontent-ref %}


# Bridge

By using the [Silicon Sepolia Bridge](https://bridge-sepolia.silicon.network), you can bridge Testnet assets from Ethereum Sepolia and use them. Please refer to the link below for instructions on how to use the bridge.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><strong>Sepolia Silicon Bridge</strong></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FdXReH4p6QcJ5HnvN9gEq%2Fimage.png?alt=media&amp;token=d80bc052-e6bb-4387-a8e7-de50f4dc3837">image.png</a></td></tr></tbody></table>

{% content-ref url="/pages/3c3bDz9mf5qRBJ2eV5He" %}
[Bridge](/user-guide/bridge)
{% endcontent-ref %}


# Block Explorer

This step explains the Block Explorer, a tool for viewing recorded transactions.

## Silicon Scope (L2)

<table data-card-size="large" data-view="cards" data-full-width="false"><thead><tr><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><strong>Sepolia Silicon Scope</strong></td><td></td><td><a href="https://scope-sepolia.silicon.network">https://scope-sepolia.silicon.network</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FXXnq8v2Ydu5IG2wqnwqB%2Fimage.png?alt=media&amp;token=134de2b8-5bed-4848-9fe7-0e187eeb94a5">image.png</a></td></tr></tbody></table>

## Etherscan (L1)

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Sepolia Etherscan</strong></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FgnghojSoXNr9vnNwWFjl%2Fimage.png?alt=media&amp;token=420983eb-1c37-40ce-b3d3-2df5bac1d79d">image.png</a></td><td><a href="https://sepolia.etherscan.io">https://sepolia.etherscan.io</a></td></tr></tbody></table>


# zkEVM Testnet Contracts

The following addresses are canonical on the Silicon zkEVM

## L2 Contracts (Silicon Sepolia Testnet)

| Contract Name                   | Contract Address                             |
| ------------------------------- | -------------------------------------------- |
| Polygon zkEVM Deployer          | `0x36810012486fc134D0679c07f85fe5ba5A087D8C` |
| Proxy Admin                     | `0x85cEB41028B1a5ED2b88E395145344837308b251` |
| Polygon zkEVM Bridge            | `0x528e26b25a34a4A5d0dbDa1d57D318153d2ED582` |
| Polygon zkEVM GlobalExitRoot L2 | `0xa40d5f56745a118d0906a34e69aec8c0db1cb8fa` |
| Timelock                        | `0xdbC6981a11fc2B000c635bFA7C47676b25C87D39` |

## L1 Contracts (Ethereum Sepolia Testnet)

| Contract Name                | Contract Address                             |
| ---------------------------- | -------------------------------------------- |
| Pol Token                    | `0x6a7c3F4B0651d6DA389AD1d11D962ea458cDCA70` |
| Polygon zkEVM                | `0x0947030d46917b307cd77f003beac1b3ea6d7cf0` |
| Polygon RollupManager        | `0x32d33d5137a7cffb54c5bf8371172bcec5f310ff` |
| Polygon zkEVM GlobalExitRoot | `0xad1490c248c5d3cbae399fd529b79b42984277df` |
| DataCommitee                 | `0x786EA264920787173A3c90b7910D309AdC8145b4` |
| Polygon zkEVM Bridge         | `0x528e26b25a34a4A5d0dbDa1d57D318153d2ED582` |

## Role Addresses (Testnet)

| Role                 | Contract Address                                                                                                          | Type of Key              |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------ |
| Sequencer            | `0xFd4440D4FB146562Ff6C613C9A4Df45363c590F1`                                                                              | EOA managed by Silicon   |
| Aggregator           | `0x0325686a18aA829B9FaaAD70f22ea0830aA6076F`                                                                              | EOA managed by Polygon   |
| DataCommitee Members | <p><code>0xb31af7A5F64982e90634A503f239C0fa8f15D4E8</code><br><code>0xE1aB51c1Ed35dE68cD4733ec5F7351553967aC97</code></p> | EOA managed by Silicon   |
| DataCommitee Members | `0x49f20e0D022D5302E48B9721604aEc3eC3453C9F`                                                                              | EOA managed by NodeInfra |


# Frequently Asked Questions

Silicon FAQs

<details>

<summary>Silicon의 기본 네트워크 화폐는 발행되었나요?</summary>

아니요. Silicon의 현재 기본 네트워크 화폐는 이더(ETH)이며, 이 외의 자체 화폐 발행 계획은 없습니다. Silicon의 화폐, 토큰임을 사칭하는 사기 행각을 주의하세요.

</details>

<details>

<summary>Silicon의 수수료(가스비)를 rETH, oETH, WETH와 같은 다른 종류의 이더로 지불할 수 있나요?</summary>

아니요. Silicon에서는 이더리움 네트워크에서 브릿지된 이더(ETH)로만 수수료를 지불할 수 있습니다. 다만, DApp을 통한 트랜잭션 발생 시 각 DApp의 수수료 시스템(Fee Delegation 등)이 적용될 수 있습니다.

</details>

<details>

<summary>중앙거래소의 자산을 지갑으로 바로 전송해도 되나요?</summary>

타 네트워크의 자산을 실리콘 네트워크에서 활용하기 위해선 자산을 꼭 브릿지하여야 하며, 아래 목록의 거래소가 아닌 경우 현재 실리콘 네트워크의 자산 지원 여부가 불분명한 중앙거래소이므로 결코 실리콘 네트워크의 지갑으로 자산을 전송할 때에 주의가 필요합니다.

[Korbit / ETH](https://www.korbit.co.kr/faq/list/?category=5wlSj45vmbDyHBA92Ux0Ie\&article=696SdfCmeHje9cMsx7eRGp)

</details>


# Contact Silicon

Inquiries, bug reports, suspicious activity reports, partnership proposals, etc.

{% hint style="info" %}

#### Have you experienced any inconveniences within the Silicon ecosystem, or do you have any ideas for improvements? Feel free to contact us!

{% endhint %}

## Inquiries, Bug/Suspicious Reports, etcs.

* <support@silicon.network>

## Partnership/Marketing Proposals

* <business@silicon.network>


# Brand

Introduction and usage guide for Silicon brand identity.

## Silicon Brand Identity

### Download directly here

<table><thead><tr><th align="center">Circular Symbol</th><th>Square Symbol</th><th data-hidden></th></tr></thead><tbody><tr><td align="center"><div><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F9quTz49nb0B6zz1L05u8%2FSilicon%20Square%20Symbol.png?alt=media&amp;token=e6de9a6a-9bf0-4666-bb44-e73053585bae" alt=""><figcaption></figcaption></figure></div></td><td><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2F2R2tkfnbIoVUSSNIIEnl%2FSilicon%20Rectangular%20Symbol.png?alt=media&amp;token=8d27489e-cf67-41bb-8581-f47be86b8e63" alt=""></td><td></td></tr></tbody></table>

### Signature

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fd2YjwvLPNb5xahnRYHpf%2Fimage.png?alt=media&amp;token=8f430dbf-6efd-4f35-ab81-04101a1d1af8" alt=""><figcaption><p>Signature of Silicon</p></figcaption></figure>

Silicon, inspired by the element silicon, the main component of sand, symbolizes boundless potential, akin to how sand gathers to create infinite possibilities. This ethos is reflected in Silicon's symbols and logos.

### Symbol

<div data-full-width="false"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2Fa38ZEFW6GL6SCe44qpns%2Fimage.png?alt=media&amp;token=ccbaaefd-43ee-40ad-bd3b-8036b17ddf87" alt="" width="240"><figcaption><p>Symbol of Silicon</p></figcaption></figure></div>

The symbol of Silicon is designed to mimic the elemental symbol of 'Silicon (Si)' and the S-curve, symbolizing the rapid growth of technology.

### Color System

To emphasize its visual brand identity, Silicon has established a dedicated color system.\
It is important to use the color palette appropriately according to hierarchy.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><em>Primary Color</em></td><td><strong>Silicon Blue</strong><br><code>#007AFF</code></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FAsGaqBV2opJTp4LcO9kb%2Fimage.png?alt=media&amp;token=03980c26-21c0-480b-a417-8f380184d949">image.png</a></td></tr><tr><td><em>Secondary Color</em></td><td><strong>Silicon Sky Blue</strong><br><code>#80C3FF</code></td><td></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FYi3j1JQajrUf1GLd5lFh%2Fimage.png?alt=media&amp;token=134f75d7-b679-445c-9f72-9538bc3373a3">image.png</a></td></tr></tbody></table>

***

## Usage Guide

### Exclusion Zone

<figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FUoXSelOyB9oKXJ3Cul3f%2Fimage.png?alt=media&amp;token=780913d4-b5a4-4e13-861e-e97fd99bc918" alt=""><figcaption><p>(<strong>✕</strong>) is the gap's minimum secure width</p></figcaption></figure>

### Circular Image

<div data-full-width="false"><figure><img src="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FnC1sG6B6wSIxvg8DJoPE%2Fimage.png?alt=media&amp;token=c84d73e0-3d90-4cac-8f7f-60ffb6d17090" alt=""><figcaption><p>(<strong>2✕</strong>) is the gap's minimum secure width</p></figcaption></figure></div>

### Guidelines

When using our brand identity, the following types of usage are prohibited.

* Use the logo in its original form and arrangement.
* Modifications are not allowed.
* Colors other than the following three are prohibited from being used in the logo.\
  ***Silicon Blue, Black or White, Contrasting Grayscale***
* Do not change style of the logo.

***

## Assets

All assets can be downloaded from the link below.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><strong>Google Drive</strong> </td><td>File formats ready for quick and easy use.</td><td></td><td><a href="https://drive.google.com/drive/folders/1C1WCEtohReb6XtFEN1ynvnxYwX2HbyeD?usp=sharing">https://drive.google.com/drive/folders/1C1WCEtohReb6XtFEN1ynvnxYwX2HbyeD?usp=sharing</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FVtQ13TMxFyu3p0KTRo5x%2Fimage.png?alt=media&amp;token=73369400-dfd0-4fee-94d8-9a12073fad69">image.png</a></td></tr><tr><td><strong>Figma</strong></td><td>Component formats ready for direct use in GUI or Figma projects.</td><td></td><td><a href="https://www.figma.com/design/xgw7oUarEulRs37vixj90u/Silicon-Brand-Assets?node-id=0-1&#x26;m=dev">https://www.figma.com/design/xgw7oUarEulRs37vixj90u/Silicon-Brand-Assets?node-id=0-1&#x26;m=dev</a></td><td><a href="https://3466272701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaHfmA7e2D7Khx2y9x47r%2Fuploads%2FhRdPzfbSqad6BOZY80lo%2Fimage.png?alt=media&amp;token=53b06306-3475-4e9c-aff1-ce69853c3e77">image.png</a></td></tr></tbody></table>


# Security

Silicon is a zkEVM based Ethereum layer 2 network, using the Polygon CDK.\
Its security inherits from Ethereum and Polygon. Check out the Polygon zkEVM audit report at the link below.

{% embed url="<https://github.com/0xPolygonHermez/zkevm-rom/blob/main/audits/Polygon-zkEVM-Public-v1.1-verichains-19-03-2024.pdf>" fullWidth="false" %}
Audit report of Polygon zkEVM
{% endembed %}


# Terms of use

#### Last Updated: December 12, 2024

***

### 1. Introduction

**1.1 Purpose:** These Terms of Use ("Terms") govern the conditions under which you may access and use the services provided by Silicon Network (the "Network").

**1.2 Acceptance:** When a user accesses the Silicon Network website, a popup containing important notices about these Terms will be displayed. By reviewing the Terms in the popup and clicking the 'Accept' button, the user is deemed to have accepted these Terms.

**1.3 Changes to Terms:** The Network reserves the right to modify these Terms at any time. Significant changes will be communicated in advance. Continued use of the services after changes are made constitutes your acceptance of the new Terms.

### 2. Provision and Use of Services

**2.1 Service Description:** The Network provides a Layer 2 solution for Ethereum, enabling users to conduct blockchain transactions and operate decentralized applications (dApps) quickly and at low gas fee, compared to Ethereum.\[L1]&#x20;

**2.2 User Access:** While the Network's services are generally accessible to all, certain services may require non-custodial wallet\[L2] . Your account is for your personal use only and must not be shared or transferred to any third party.

**2.3 Service Interruptions:** The Network does not guarantee uninterrupted service and may suspend or discontinue services temporarily for maintenance or technical issues without prior notice.

### 3. User Responsibilities

**3.1 Compliance:** You agree to use the Network in compliance with all applicable laws and regulations. You must not upload, distribute, or use illegal content or misuse the services.

**3.2 Account Security:** You are responsible for maintaining the confidentiality of your account information (such as your password) and for all activities that occur under your account. The Network is not liable for any loss or damage arising from your failure to protect your account.

**3.3 Prohibited Conduct:** You must not engage in any activity that disrupts or harms the Network's operations or other users, including hacking, data corruption, or the distribution of malicious software. Violation of these terms may result in account suspension or termination.

### 4. Intellectual Property Rights

**4.1 Ownership:** All intellectual property rights in the Network, including software, trademarks, logos, and content, are owned by the Network or its licensors. You may not infringe upon these rights.

**4.2 User Content:** You retain ownership of any content you upload to the Network. However, by uploading content, you grant the Network a non-exclusive, royalty-free, worldwide license to use, reproduce, modify, and distribute your content within the Network's services.

**4.3 Reporting Infringements:** If you believe your intellectual property rights have been infringed, you may report it to the Network. The Network will investigate such claims and may remove or restrict access to the infringing content if necessary.

### 5. Disclaimers and Limitation of Liability

**5.1 Disclaimer of Warranties:** The Network provides the services "as is" and disclaims all warranties, whether express or implied, including but not limited to warranties of completeness, accuracy, fitness for a particular purpose, or non-infringement.

**5.2 Limitation of Liability:** The Network shall not be liable for any direct, indirect, incidental, special, or consequential damages arising from your use of the services, including but not limited to loss of data, loss of profits, or inability to use the services.

**5.3 Legal Exceptions:** In jurisdictions where the exclusion or limitation of certain warranties or liabilities is not permitted, the Network's liability will be limited to the maximum extent permitted by law.

### 6. Privacy Policy

**6.1 Data Collection:** The Network does not store or use any personal information. All transactions conducted through the Network ensure user anonymity and are recorded on the blockchain without any personally identifiable information.

**6.2 Data Protection:** The Network takes reasonable security measures to protect your personal data, but cannot guarantee absolute security due to the nature of internet transmissions.

**6.3 Privacy Policy:** For detailed information on how the Network handles your personal data, please refer to our separate Privacy Policy.

### 7. Modifications and Termination

**7.1 Service Modifications:** The Network reserves the right to modify, suspend, or discontinue any aspect of the services at any time. Users will be notified of significant changes via email or through the service itself.

**7.2 Termination of Services:** The Network may, at its discretion, terminate or suspend the provision of all or part of the services. Users will be notified in advance, and following termination, you may lose access to your data within the service.

### 8. Governing Law and Dispute Resolution

**8.1 Governing Law:** Any disputes arising out of or in connection with these Terms and the use of the Network shall be governed by the laws of the Republic of Korea. In the event of a dispute, you and us shall make efforts to resolve the issue through mutual consultation. If the dispute cannot be resolved through consultation, the Seoul Central District Court shall have exclusive jurisdiction as the court of first instance.

**8.2 Dispute Resolution:** Any claims or disputes arising under these Terms must be resolved on an individual basis, not as part of any class action or representative lawsuit ("Class Action Waiver"). By agreeing to these Terms, you agree not to participate in any class action or representative lawsuit in connection with any dispute related to these Terms, nor to act as a class representative or in any other representative capacity.

### 9. Miscellaneous

● These Terms of Service, along with any policies or operating rules posted by us on the Network, constitute the entire agreement between you and us. This agreement supersedes any and all prior or contemporaneous oral or written agreements, communications, or representations between you and us. We shall not be liable for any oral or written descriptions, consents, representations, warranties, or promises that are not expressly included or referenced in these Terms. This includes, without limitation, any representations made by third parties concerning the services provided to you under these Terms.

● Our failure to exercise or enforce any right or provision of these Terms shall not constitute a waiver of such right or provision.

● These Terms shall apply to the fullest extent permitted by law.

● We may assign these Terms, in whole or in part, at our sole discretion, to any individual or entity of our choosing at any time, and upon such assignment, we will notify you.

● We shall not be liable for any loss, damage, delay, or failure to act resulting from causes beyond our reasonable control.

● If any provision or part of a provision of these Terms is found to be unlawful, void, or unenforceable, such provision or part thereof shall be deemed severable from these Terms and shall not affect the validity and enforceability of the remaining provisions.

● No joint venture, partnership, employment, or agency relationship exists between you and us as a result of these Terms or your use of the Network.

● You agree that these Terms shall not be construed against us solely because we drafted them. Additionally, you waive any defense based on the electronic form of these Terms and the absence of signatures by the parties hereto to enforce these Terms.

### 10. Contact Information

**10.1 Inquiries:** For any questions or concerns regarding these Terms or the Network's services, please contact us at **<support@silicon.network>**.

**10.2 Legal Notices:** Legal notices to the Network can be sent to the email address provided, and legal notices to you will be sent to the email address you have provided to the Network.


# Privacy Policy

#### Last Updated: December 12, 2024

***

At Silicon network (referred to here as “service”), we respect and protect the privacy of those users and developers (“you” and “your” or “Users” and “Developers”, as relevant) who explore and use Silicon (“Silicon”) through the Silicon protocol or any other applications, tools, and features we operate (collectively, the “Services”).

Please note that we do not control websites, applications, or services operated by third parties, and we are not responsible for their actions. We encourage you to review the privacy policies of the other websites, decentralized applications, and services you use to access or interact with our Services.

### Article 1. Categories of Acquired Information and Purpose of Collection, The Period for Retaining and Using Personal Information

#### 1. Categories of Acquired Information and Purpose of Collection

Due to the nature of the service being a decentralized blockchain service, being non-real name and non-custodial form, no personal information of users (including the information under the Personal Information Protection Act, hereinafter referred to as "personal information") is collected.

\* The service does not request, store, or process personal information related to users, including but not limited to private keys, mnemonic keys, seed phrases, or any information equivalent to those. Consequently, users are responsible for managing the information safely, and the service is not responsible if damage occurs due to users’ negligence.

#### 2. The Period for Retaining and Using Personal Information.

The service does not store or use any personal information. All transactions conducted through the Network ensure user anonymity and are recorded on the blockchain without any personally identifiable information.

### Article 2. Outsourcing the Processing of Personal Information

The service does not outsource the processing of personal information.

### Article 3 Provision of Personal Information to Third Parties

There is no provision of personal information to third parties by the service. However, transaction data recorded on the blockchain is publicly accessible and considered public data rather than personal information.

### Article 4 Installation, Operation, and Refusal of Automatic Collection Tool for Personal Information

1\. In order to provide personalized services to users, the service may use 'cookies' to store and retrieve usage information.&#x20;

2\. A cookie is a small piece of information sent by the website's server (http), which is used to run a website, to the user’s browser, and the data may be stored on the user’s PC computer hard drive.

A. Purpose of using cookies: Cookies are used to provide users with optimal information by identifying their visits to services and websites, the way in which the sites are used, popular search terms, secure access, etc.

B. Cookie Installation, Operation, and Refusal: Cookies can be enabled or disabled using the basic functions of a web browser. Detailed instructions for setting cookies are provided in each browser's instructions.

C. Refusing to save cookies may lead to limitations in customized services.

### Article 5 Collection, Use, Provision, and Refusal of Behavior Information

This service employs Google's behavioral information analysis tools and related services to enhance service quality, support research initiatives, and generate statistical insights. You may review and manage your data, delete information, disable settings, or withdraw consent by following the instructions outlined in each section below.

1\. Google LLC, (<googlekrsupport@google.com>) (U.S.A)

* Method of collection: Transmission through the network at the time of a visitor’s using the service on the website
* Collected Items: First-party cookies, device/browser data, and activity within the site/app
* Opt-out Method: <https://tools.google.com/dlpage/gaoptout>

※ The Company does not make use of online customized advertisements through the Google Analytics advertising function and only collects and uses behavioral information without combining it with identifiable information.

### Article 6 Third-Party Services

The Silicon network may integrate with third-party services, each of which may have its own privacy policy. Users are solely responsible for reviewing, understanding, and accepting the privacy policies of these third-party services before using them. The Silicon network does not assume any responsibility for the privacy practices or the content of these third-party services. Users use such services at their own risk.

### Article 7 Procedures and Methods for Destroying Personal Information

1\. Users personal information is not collected, used, stored, retained, or processed by the Service.

2\. In the event that the service holds personal information on a temporary for business purposes, or temporarily holds personal information due to unpredictable circumstances, if separate consent was obtained for the retention period of personal information, or if laws and regulations require that personal information be stored for certain periods, personal information is securely stored in accordance with the law and destroyed in a way that cannot be replicated.

### Article 8 Contact Information

If you have any inquiries or concerns regarding this Privacy Policy, please contact us at **<support@silicon.network>**. Your message will be directed to the designated representative responsible for matters related to this Privacy Policy.

### Article 9 Revision of Privacy Policy

This privacy policy may be revised and posted from time to time by the service. The revised policy is effective as of the posting date. Changes to privacy policy that are significantly detrimental to users will be posted at least 30 days in advance.


# Open Source License

### System Icons by Gregor Cresnar

{% embed url="<https://thenounproject.com/creator/grega.cresnar>" %}