The design of OKOK Bridge can be broken down into two parts, a group of relayers and a private codebase that verifies the transactions sent by the group of relayers. In OKOK Bridge terminology, this group of relayers is called “wardens,” and the private enclave is an “Intel SGX” application.

The foundational job of a warden is to monitor the Arbitrum and Base blockchains. When a warden sees a supported ERC-20 token sent to the OKOK Bridge’s contract they relay that information to the Intel SGX enclave. From there, the transaction is confirmed, and the token is either locked and minted (Arbitrum -> Base) or burned and released (Base -> Arbitrum). Notably, for a cross-chain transaction to be confirmed, three out of the four wardens must have reported to the enclave with the exact same information. To do its job, a warden consists of three components: a Golang server (which indexes Arbitrum and Base transactions and communicates directly with OKOK Bridge), an Base node, and an Arbitrum Nitro node. Together, these three components allow wardens to:

1. monitor both chains for potential cross-chain transactions

2. communicate with the bridge to relay information about cross-chain transactions and

3. track the wrapping and unwrapping of assets once the information has been relayed

In addition to tracking transactions, each warden stores a secret share from the Intel SGX enclave. This means that the private key of the enclave, which we will discuss shortly, is only available if 3/4 warden shares their private key at one time. Because of this, OKOK Bridge could potentially restart the Intel SGX enclave at any point, even if it were wiped out, as long as ¾ wardens shared their key successfully. Lastly, a warden is in charge of ensuring that information such as fees, minimum transfer requirements, and supported ERC-20 tokens are available to the public, as the Intel SGX enclave is not publicly accessible.

To put it simply, the SGX application is a private enclave that requires 3 out of 4 wardens to submit the same transaction before signing off on a bridge transfer between Arbitrum and Base. Notably, each warden communicates with the enclave independently via encrypted messages utilizing TLS and including HMAC signatures. Let’s dive into this at a deeper level. Intel Software Guard Extensions (SGX) is a code set that allows a system to operate with private regions of memory, called enclaves, where contents are protected and unreadable outside of any process or entity outside of the enclave itself. This SGX application, this enclave, is the core to the OKOK Bridge, as it signs off on cross-chain transfers. One of the biggest risks of the OKOK Bridge system is someone being able to fake a private enclave. OKOK Bridge relies on “remote attestation,” a computer science process wherein a third party (a warden) can attest that a remote entity (the enclave) is running the correct code and can be trusted. From there, a communication system can be established by the third party and the remote entity. In the context of OKOK Bridge, remote attestation by wardens force the enclave to prove its identity, show that its source code has not been tampered with, the enclave verifies its identity, that the source code hasn’t been tampered with, confirm that it’s running on a genuine SGX enabled platform and that it has the latest security updates. Furthermore, after each warden provides attestation of the enclave, it will post the report to a public JSON file. As discussed above, the private key of the OKOK Bridge enclave is protected because the key is split into four “secrets” and distributed to the four wardens. Each time the enclave is started up or the warden is asked for a secret share, the warden performs remote attestation with the enclave to ensure it is acting as it should. Once established, the enclave’s purpose is to communicate directly with wardens to learn about on-chain events and then sign off on cross-chain transfers between Arbitrum and Base, which includes the minting of wrapped ERC assets on Base and the release of ERC-20 tokens back to Arbitrum.

The design of OKOK Bridge can be broken down into two parts, a group of relayers and a private codebase that verifies the transactions sent by the group of relayers. In OKOK Bridge terminology, this group of relayers is called “wardens,” and the private enclave is an “Intel SGX” application.

The foundational job of a warden is to monitor the Arbitrum and Base blockchains. When a warden sees a supported ERC-20 token sent to the OKOK Bridge’s contract they relay that information to the Intel SGX enclave. From there, the transaction is confirmed, and the token is either locked and minted (Arbitrum -> Base) or burned and released (Base -> Arbitrum). Notably, for a cross-chain transaction to be confirmed, three out of the four wardens must have reported to the enclave with the exact same information. To do its job, a warden consists of three components: a Golang server (which indexes Arbitrum and Base transactions and communicates directly with OKOK Bridge), an Base node, and an Arbitrum Nitro node. Together, these three components allow wardens to:

1. monitor both chains for potential cross-chain transactions

2. communicate with the bridge to relay information about cross-chain transactions and

3. track the wrapping and unwrapping of assets once the information has been relayed

In addition to tracking transactions, each warden stores a secret share from the Intel SGX enclave. This means that the private key of the enclave, which we will discuss shortly, is only available if 3/4 warden shares their private key at one time. Because of this, OKOK Bridge could potentially restart the Intel SGX enclave at any point, even if it were wiped out, as long as ¾ wardens shared their key successfully. Lastly, a warden is in charge of ensuring that information such as fees, minimum transfer requirements, and supported ERC-20 tokens are available to the public, as the Intel SGX enclave is not publicly accessible.

To put it simply, the SGX application is a private enclave that requires 3 out of 4 wardens to submit the same transaction before signing off on a bridge transfer between Arbitrum and Base. Notably, each warden communicates with the enclave independently via encrypted messages utilizing TLS and including HMAC signatures. Let’s dive into this at a deeper level. Intel Software Guard Extensions (SGX) is a code set that allows a system to operate with private regions of memory, called enclaves, where contents are protected and unreadable outside of any process or entity outside of the enclave itself. This SGX application, this enclave, is the core to the OKOK Bridge, as it signs off on cross-chain transfers. One of the biggest risks of the OKOK Bridge system is someone being able to fake a private enclave. OKOK Bridge relies on “remote attestation,” a computer science process wherein a third party (a warden) can attest that a remote entity (the enclave) is running the correct code and can be trusted. From there, a communication system can be established by the third party and the remote entity. In the context of OKOK Bridge, remote attestation by wardens force the enclave to prove its identity, show that its source code has not been tampered with, the enclave verifies its identity, that the source code hasn’t been tampered with, confirm that it’s running on a genuine SGX enabled platform and that it has the latest security updates. Furthermore, after each warden provides attestation of the enclave, it will post the report to a public JSON file. As discussed above, the private key of the OKOK Bridge enclave is protected because the key is split into four “secrets” and distributed to the four wardens. Each time the enclave is started up or the warden is asked for a secret share, the warden performs remote attestation with the enclave to ensure it is acting as it should. Once established, the enclave’s purpose is to communicate directly with wardens to learn about on-chain events and then sign off on cross-chain transfers between Arbitrum and Base, which includes the minting of wrapped ERC assets on Base and the release of ERC-20 tokens back to Arbitrum.