Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Learn the basics of working with the EVM Developer Toolkit
Learn how to use Secret Network's EVM Toolkit to design dApps with confidential computing on the EVM.
Secret Network currently supports two cross-chain messaging solutions:
SecretPath (recommended)
There are currently 10+ supported chains. See the Gateway contracts to review supported chains.
See the Axelar Gateway contracts to review supported chains.
SecretPath consists of two core primitives: relayers and gateways.
Gateways are the onchain smart contracts that handle the broadcasting, receipt, packaging, and verification of messages. Gateways are also the mechanism by which application developers will interface with the SecretPath protocol.
These gateways are relatively simple and generic, primarily consisting of two capabilities. First, gateways can handle signature operations. For gateways on public blockchains, that means verification; for those on privacy-preserving blockchains, that means verification as well as signing. Second, gateways handle serdes operations: converting contract inputs into correctly formatted packets and vice versa.
Relayers watch for messages on one chain and then call another chain with that message. For SecretPath, the primary security-related concern is liveness, not resistance to node collusion or censorship. The relayer is not tasked with relaying funds/tokens from one chain to another, but rather with watching for encrypted messages that need to be passed. The relayer does not have access to encryption keys that can decrypt these messages or signing keys to generate new valid ones, meaning that the relayer cannot compromise the data in security or correctness.
The most a relayer can do is to not transmit the data as requested, which would cause liveness problems for the network, but would not compromise user funds, smart contract applications, or sensitive data. This also makes the requirements for running a relayer significantly lower: a relayer needs only to be able to watch for transactions on host chains and create transactions on destination chains based on those host chain transactions.
Gateways are the onchain smart contracts that handle the broadcasting, receipt, packaging, and verification of messages. Gateways are also the mechanism by which application developers will interface with the SecretPath protocol.These gateways are relatively simple and generic, primarily consisting of three capabilities.
First, gateways can handle signature operations. For gateways on public blockchains, that means verification; for those on privacy-preserving blockchains, that means verification as well as signing.
Second, gateways handle serialize/deserialize operations: converting contract inputs into correctly formatted packets and vice versa.
Third, gateways on privacy-preserving chains can re-encrypt their inputs under the key of the final compute contract.
For more background on how the high-level architecture of SecretPath differs from that of other interoperability networks, see section 4 of the Snakepath whitepaper.
Secret Network's EVM Toolkit is a cross-chain messaging and confidential computation SDK for EVM developers.
The toolkit allows EVM developers to build novel cross-chain applications such as private DAO voting mechanisms, secure random number generation (Secret VRF), confidential data access control via EVM NFTs, encrypted DeFi order books, and more.
Secret Network currently supports two cross-chain messaging solutions:
SecretPath (recommended)
There are currently 10+ supported chains. See the Gateway contracts to review supported chains.
Axelar GMP
See the Axelar Gateway contracts to review supported chains.
Learn how to use Axelar General Message Passing in order to send messages between EVM chains and Secret Network
Axelar enables secure interchain communication and token transfers, spanning consensus methods including Cosmos and Ethereum. Through the use of General Message Passing (GMP), developers building on Ethereum can execute smart contracts on Secret and vice versa. This means complete composability across Web3.
With GMP you can:
Call a contract on chain B from chain A.
Call a contract on chain B from chain A and attach some tokens.
Here you'll find a more in-depth overview with a detailed description of what the two core primitives (Gateways & Relayers) do. First, let us give you the core idea on what SecretPath really hinges on.
The core idea of SecretPath is the following:
The "master private gateway" is a confidential smart contract living on Secret Network.
Since this contract is confidential by default , we can store a (secret) private key, which only this smart contract can use to sign messages/packets and is unknown to the operators or to any contract administrators.
The only trust assumption that we have for this bridge model to work is therefore that the private key does not leak out the TEE (trusted execution environment)/confidential computation environment. In case the TEE breaks and that private signing keys could potentially leak, the encryption and verification keys can be rotated to new ones, keeping the bridge intact. Since we only rely on a smart contract to handle the core bridging functionality, we call this trustless. Some may argue that since we are using TEE's, we are not completely trustless but instead trust-minimized.
Everything else around this "master private gateway" is untrusted. We only use a lot of consistency checks and hashing to ensure that data weren't manipulated along any transmission path.
As outlined in the overview, the primary functions of the Gateway are:
For the "master public gateway" that is on a public blockchain, that means only verification of signatures. In our case, this public gateways verifies all secp256k1 signatures signed by the user or by the master private gateway.
The private master gateway does verification of the secp256k1 signed and encrypted user payloads. It also signs all outgoing messages using secp256k1 so that other user made private contracts as well as the public gateway contract can verify the validity of the message/packet.
Both gateways also handle serialize/deserialize operations. They convert contract inputs into correctly formatted packets and vice versa, while also doing the appropiate conversions between base64 (mainly used for secret) and hex (mainly used for EVMs) inputs.
Third, gateways on privacy-preserving chains can re-encrypt their inputs under the key of the final compute contract. The master private gateway can handle encrypted or unencrypted payloads. In the case of encrypted payloads, the payload is encrypted using a shared key that is generated via ECDH from a users randomly generated private key and the gateways encryption public key. We use the well known Chacha20-Poly1305 to do the symmetric encryption using that shared key.
To use SecretVRF (Random Number Generation) over SecretPath please checkout this tutorial .
If you like to use Encrypted Payloads to store data in a KV store, please look at the .
Learn how to use Axelar General Message Passing in order to send messages between EVM chains and Secret Network
Learn how to use Axelar General Message Passing in order to send messages between EVM chains and Secret Network
In this tutorial, you will learn how to use Axelar GMP to send a string
between Polygon and Secret testnets. To learn more about the flow architecture, see the Axelar documentation here.
For GMP to work, both chain A and chain B must be EVM or Cosmos with a deployed Axelar Gateway contract. For this tutorial we will be using the Polygon testnet Axelar Gateway contracts. We will go into this in more detail momentarily.
Have Metamask installed, Polygon Mumbai Network added to your wallet, and your wallet funded with Polygon tokens.
Add Polygon Mumbai Network to your Metamask wallet by navigating to the Polygon testnet explorer and clicking "Add Mumbai Network" in the bottom righthand corner of the homepage.
In order to execute a smart contract on Secret network, you must first upload and instantiate a smart contract on Polygon that can execute messages using Axelar GMP. Axelar has a github repository of example contracts that can be used for GMP. We will be uploading the SendReceive.sol contract to Polygon for this demo.
The Cosmwasm smart contracts in this Axelar repository are not compatible with Secret Network out of the box due to dependency issues. However, we will modify the SendReceive contract to be compatible with Secret Network.
To upload the contract, we will use Remix Online IDE, which is a powerful toolset for developing, deploying, debugging, and testing Ethereum and EVM-compatible smart contracts.
First, navigate to Remix and create a new blank workspace:
Next, create a new file called SendReceive.sol
and paste the Axelar GMP solidity code. This will autofill your workspace with the necessary dependencies for your SendReceive.sol contract 🤯
Now all that's left is to compile and upload the contract. Navigate to the Solidity compiler using the sidebar and click "Compile SendReceive.sol". Then, navigate to "Deploy and run transactions." Toggle the Environment from "Remix VM (Shanghai)" to "Injected Provider - MetaMask" and make sure that in your MetaMask wallet you have currently selected Mumbai network.
The constructor
of SendReceive.sol contains 3 variables that you must now input in order to instantiate the contract and link it to Axelar's Polygon gateway contract and gas receiver contract, as well as the Polygon Mumbai chain name:
Input these strings like so and then click "Transact":
Upon successful instantiation, the contract address will be returned in the Remix terminal, which you can then view on Polygonscan. And the deployed contract can now be interacted with in the "Deployed Contracts" window:
Congrats, you've just deployed an Axelar GMP-compatible contract to Polygon testnet that can send and receive messages to and from a Secret Network smart contract 🎉
Now that you've uploaded a GMP-compatible contract to Polygon, let's do the same on Secret Network so that the contracts can communicate with each other across the Cosmos!
First, clone this Secret Network examples repository:
Then, cd
into the examples/secret-ethereum-gmp
folder
and compile the contract by running make build-mainnet
in your terminal.
If this is your first time working with a Secret contract, visit the Getting Started docs to properly configure your developer environment.
Now, open a new terminal window and cd
into examples/secret-ethereum-gmp/node
and then run npm install
to install the package.json
dependencies.
Create a .env
file in examples/secret-ethereum-gmp/node
and add your wallet mnemonic in order to upload the contract:
You can then upload and instantiate the contract by running node index.js
.
Upon successful instantiation, a Secret contract address is returned that you can then use to send messages to and from Polygon:
Now let's send a string
from Polygon to Secret! 🚀
Now that you have a GMP-compatible contract instantiated on Secret Network, you have all of the variables needed in order to send a cross-chain message using the SendReceive.sol
contract.
In order to send messages using Axelar GMP, the user prepays the relayer gas fee on the source chain to Axelar’s Gas Services contract.
You can do this in Remix by navigating to the "Deploy and run transactions" tab in the sidebar and adding gas to prepay the gas fee.
To make sure you have enough gas, add .40 Matic, (roughly .20 USD or 400000000000000000 Wei), to the transaction:
Now all that's left is to execute the transaction! From the "Deployed contracts" section of Remix, open the dropdown for the send
function, which should have three inputs: destinationChain
, destinationAddress
, and message
. Input the following:
Once you have inputed these strings and your contract address, select "transact." Congratulations! You've just sent a string
from Polygon to Secret Network! 🎉
Use Polygonscan to track the transaction on Polygon. Here is an already deployed contract for reference. Transaction times vary depending upon Poygon network congestion; you might want to "speed up" the transaction in Metamask.
Now that you've successfully executed a cross-chain message from Polygon to Secret using Axelar GMP, let's query the message on Secret Network to see if the message was actually received by the Secret contract.
First, confirm that the transaction has been successfully relayed by Axelar.
The Axelarscan status diagram indicates the following 5 steps were executed successfully:
Once the transaction has been executed successfully, you can use Secret.js to query the message:
To execute this query, navigate to the query.js
file in examples/secret-ethereum-gmp/node
and replace the contractAdress
and contractCodeHash
with your contract address and code hash, respectively.
Then run node query
.
If the message was executed successfully, the query will return the Ethereum wallet address that sent the transaction as well as the message that the wallet included:
Great work! Now let's send a string from Secret to Polygon!
To execute the SendMessageEvm transaction, navigate to the execute.js
file in examples/secret-ethereum-gmp/node
and replace the contractAdress
and contractCodeHash
with your contract address and code hash.
Then, update destinationAddress
to your Polygon contract address, and myMessage
to the message that you want to send:
Next, in order to send a GMP message from Secret to Polygon, you need to acquire some AXL tokens and include the correct IBC denom representing those tokens to your transaction to pay for gas, so that the message can be executed over IBC
Learn more about IBC denoms here.
The correct IBC denom is already included in the secret.js transaction, but in order for it to execute successfully, you need to have this IBC denom funded in your wallet. To add this token to your wallet, you can send Axelar tokens to your Secret wallet address over IBC.
If this is your first time sending Axelar testnet tokens over IBC, see an Axelar Gas Token video tutorial here, which guides you through the following steps:
Add Axelar testnet to your Keplr wallet by visiting Axelar Satellite (upon visiting the website, a Keplr notification will pop up that says, "https://testnet.satellite.money would like to add blockchain axelar-testnet-lisbon-3 to Keplr")
Procure AXL testnet tokens from the Axelar faucet.
Send AXL testnet tokens to your Secret testnet wallet address over IBC using Axelar Satellite.
Upon successful transfer, you should now see the new AXL IBC token in your Keplr Wallet:
Once you have properly configured your execute.js
file and procured the IBC denom needed to execute the transaction, all that's left is to run node execute.
The transaction should return a transactionHash
as well as data about the IBC routing:
Now, navigate to Axelarscan to monitor the status of the transaction.
And for good measure, view the transaction on Polygonscan to see that the message was received!
To actually see the message that you sent, click on "Click to see more":
And then at "Input Data", view the input as UTF-8 to reveal the decoded message! 👀
Congratulations! You now have all of the tools to send a message from Secret Network to Polygon using Axelar GMP! 🎉
In conclusion, Axelar's General Message Passing (GMP) offers a powerful solution for achieving secure interchain communication and token transfers across diverse blockchain ecosystems, including Cosmos and Ethereum. With GMP, developers can seamlessly execute smart contracts on one blockchain from another, fostering complete composability within the Web3 landscape. This documentation has guided you through the process of deploying GMP-compatible contracts on both Polygon and Secret Network, illustrating how to send messages across these networks. By following these steps, you have unlocked the potential for seamless interoperability and enhanced functionality in your blockchain applications. Axelar GMP paves the way for a more interconnected and efficient blockchain ecosystem. Congratulations on your successful journey with Axelar GMP!
If you run into any errors or questions, ping the #dev-issues channel on Secret Network's Discord and somebody will get back to you shortly 😊
A first-price sealed-bid auction, also known as a "blind auction", is a type of auction in which all bidders simultaneously submit sealed bids so that no bidder knows the bid of any other participant. The highest bidder pays the price that was submitted. In this tutorial you will learn how to create a cross-chain sealed bid auction dApp with encrypted bids using SecretPath.
See a live demo here!
Contract Deployment: Participants initiate the process by deploying a Sealed Bid Contract to the Secret Network. This contract contains their auction items and encrypted bids, safeguarding the bid details from public exposure.
Contract Execution via Public Gateway:
The execution sequence begins when the Sealed Bid Contract is interacted with via the Ethereum Virtual Machine (EVM).
The SecretPath Public Gateway Smart Contract serves as the intermediary, facilitating communication between the EVM and Secret Network.
Secure Message Transmission:
Messages and transactions pass through the Public Gateway to the Private Gateway Smart Contract, utilizing ECDH to ensure that the data exchanged remains confidential and tamper-proof, maintaining the integrity of the sealed bid throughout the process.
Finalization:
Once the bidding period concludes, the Sealed Bid Contract processes the bids to determine the winner securely.
The outcome is then communicated back through the gateway contracts to the relevant parties on the EVM.
One of SecretPath's key features is the ability to use encrypted payloads to send over confidential messages to a Secret Smart contract.
SecretPath can seamlessly handle encrypted payloads, as the master gateway contract on Secret automatically decrypts the payload and hands the decrypted payload over to the target contract.
The encryption of the payload is done using the ChaCha20-Poly1305, an authenticated encryption with additional data (AEAD) algorithm.
The key for this symmetric encryption is created by using the Elliptic-curve Diffie-Hellman (ECDH) scheme, comprising of two components:
An extra encryption public key provided from the Secret Gateway Contract
A randomly created (ephemeral) encryption private key on the user side (independent of the user wallet's private key)
Combining both of these keys together via the ECDH Scheme yields our encryption key, which we use to encrypt the payload with ChaCha20-Poly1305.
As a first example for this, we have used SecretPath to encrypt a string
and subsequently store it in a Secret contract.
Learn how to use SecretPath on EVM to encrypt payloads.
SecretPath seamlessly handles encrypted payloads on the EVM, which means EVM developers can use SecretPath to encrypt and decrypt messages cross-chain with little-to-no Rust experience required.
This tutorial explains how to upload your own Key-value store contract on Secret Network, which you can use to encrypt values on the EVM, as well as how to encrypt payloads and transmit them cross-chain. After this tutorial, you will have the tools you need to use SecretPath to encrypt messages on any EVM-compatible chain.
To get started, clone the SecretPath tutorials repository:
cd
into encrypted-payloads/evm-contract
Install the dependencies:
Create an env
file and add your:
EVM wallet private key
Infura API endpoint (Sepolia testnet)
See here for a properly configured example env file
Get sepolia tokens from faucet:
This tutorial is for Sepolia testnet, but there are 10+ chains currently configured that are also compatible by simply swapping out the SecretPath gateway address.
Now that your developer environment is properly configured, you're ready to encrypt your first payload with SecretPath!
cd
into encrypted-payloads/secret-contract
Compile the Secret Network key value store contract:
cd
into secret-contract/node
Install the dependencies:
Open the upload.js file and review the instantiate message at line 70:
gatewayAddress is the SecretPath gateway contract address for testnet
gatewayHash is the SecretPath gateway contract hash for testnet
gatewayKey is public key used for SecretPath encryption on Secret testnet
These three parameters remain constant and must be passed for every Secret Network contract that implements SecretPath. They can be found here for testnet.
To upload and instantiate the contract, run node upload
:
Upon successful upload, a contractHash
and address
will be returned:
Now that you have your key value store smart contract uploaded on Secret Network, let's use it to store encrypted messages. Most of the ECDH cryptography has been abstracted away so there are only a few values you need to change.
cd
into encrypted-payloads/evm-contract:
Open encrypt.js
in evm-contract/scripts and navigate to lines 43-49.
Update the routing_contract
and routing_code_hash
to the contract address and codehash
of the Secret Network smart contract that you instantiated:
publicClientAddress
is the gateway contract address for Sepolia, which is found in Secret's gateway contract docs here.
Next, update lines 73-77 with the EVM wallet address associated with the private key in your env file (myAddress)
, a key (any string
of your choosing), a value, (any string
of your choosing), and a viewing_key (any string
of your choosing).
value
is the the data that you want to encrypt, key
and viewing_key
are parameters you pass to encrypt the value.
Next, you are going to set the handle
variable to call the store_value
function inside of the Secret contract that you instantiated earlier. You do this with line 80, which corresponds to the store_value
function in the Secret contract:
Once you have decided upon these parameters, simply run encrypt.js:
Upon successful encryption, your payload hash will be returned:
Congrats, you have encrypted your first cross-chain payload with SecretPath!
To decrypt your encrypted payload, cd
into secret-contract/node
Open decrypt.js and update lines 8-9 with your key
and viewing-key:
Then run node decrypt:
Your decrypted payload will be returned:
Congrats! You have now used SecretPath to encrypt and decrypt cross-chain payloads! 🔥
SecretPath is a powerful addition to Secret Network’s cross-chain messaging capabilities. Along with IBC and Axelar GMP, and eventually to be joined by additional bridging technologies like Wormhole and Union, it enables groundbreaking new use-cases for Web3 applications by providing access to confidential computation. This facilitates novel applications such as private voting for DAOs, secure random number generation, confidential data access control via NFTs, encrypted DeFi order books, sealed-bid auctions, and storing encrypted data.
We also encourage developers to check out our grants program to get funding for building with SecretPath, and to join our Discord and Telegram to get involved with our community. You can also contact our team directly if you have any questions about building on Secret.
A first-price sealed-bid auction, also known as a "blind auction", is a type of auction in which all bidders simultaneously submit sealed bids so that no bidder knows the bid of any other participant. The highest bidder pays the price that was submitted. In this tutorial you will learn how to create a cross-chain sealed bid auction dApp with encrypted bids using SecretPath.
You will start by configuring your developer environment and then learn how to use SecretPath to enable cross-chain encryption and decryption, using Secret Network as a Confidential Computing Layer (CCL) for the EVM.
To get started, clone the SecretPath tutorials repository:
Fund your Sepolia wallet.
cd
into sealed-bid-auctions/sealed-bid-contract
Update the env
file with your Secret Network wallet mnemonic, and rename it ".env" instead of ".env.example"
Compile the contract
cd
into secret-contract/node:
Install the node dependencies
Set SecretPath parameters:
Open upload.js and configure the SecretPath gatewayAddress
, gatewayHash
, and gatewayPublicKey
:
gatewayAddress, gatewayHash, and gatewayPublicKey are needed for instantiating contracts that utilize SecretPath and can be found in the docs here. You will always use these same 3 parameters for instantiating a SecretPath-compatible contract on testnet.
Upload and instantiate the contract:
Upon successful upload and instantiation, add the contract codehash and address to your env.
Now that you've instantiated a sealed bid contract on Secret Network, it's time to create your first auction item with SecretPath!
cd
into sealed-bid-auctions/evm-contract
:
Install the dependencies
Configure env
Configure the env
with your sealed bid auction contract address and codehash, and rename it ".env" instead of ".env.example".
Configure SecretPath
Open scripts/create_auction.js and navigate to line 44, the publicClientAddress
. This is the SecretPath gateway address for Sepolia testnet.
If you wanted to send messages on another chain, such as Base or Polygon, you would simply update this publicClientAddress with the corresponding address found here.
Similarly, there is a SecretPath gateway encryption key, which is on line 63. This is used for ChaCha20-Poly1305 Payload encryption and can be found in the docs here.
If you wanted to do this for mainnet, you would simply use the mainnet encryption key.
Next, configure the auction name
, description,
and end_time
to your liking (end_time
is the amount of minutes that the auction will be live for), and note the handle
variable, which is the function that is actually being called in the Secret contract that you deployed. You are executing the create_auction_item
handle, which executes the create_auction-item
function in your sealed bid contract.
Now that you have all of your SecretPath code configured, execute the SecretPath Sepolia public gateway contract to send your auction item to the Secret contract:
Each auction item you create will have an associated ID; the first auction item has ID 1, the second has ID 2, and so on.
Upon successful execution, info about your SecretPath payload will be returned:
Now it's time to place an encrypted bid on your listed auction item. Open bid.js and adjust the amount that you want to bid as well as the index of the auction item.
Note that the sealed bid contract is designed so that each auction item has an ascending index number starting with 1. So the first auction item you list is index 1, the second is index 2, and so on.
Once you have set your bid, execute the bid function:
Upon successful execution, info about your SecretPath payload will be returned. Now let's query your auction item and bids with secret.js.
cd
into sealed-bid-auctions/sealed-bid-contract/node
:
Make sure you have added your Sealed bid contract address and codehash to your env file, and then query the auction item with node query_auction
:
Note that you are querying with key 1, because the first auction item is stored at index 1, the second auction item is stored at index 2, and so on.
If your auction item was submitted successfully, it should be returned like so:
NOTE: end_time
is converted from minutes to Secret Network block height in the sealed bid auction contract 😎
Now, query the encrypted bids by running node query_bid
:
If the bidding is still open, it will return the message:
If the bidding is closed, it will return the highest bid:
This is programmed in the retrieve_bids_query function of the Sealed Bid contract and can be adjusted to your liking 😊
NOTE: Be sure to update the index of the query for subsequent auction item queries
Congrats! You deployed your very own sealed bid auction contract on Secret Network and used SecretPath to send cross-chain encrypted bids on Sepolia testnet. See the fullstack demo here. You now have all of the tools you need to start building your own cross-chain SecretPath contracts on the EVM 🎉
Note that the end user of the application is not exposed to Secret Network and is only working directly in the EVM environment. However, the data is fully protected and cannot be viewed by anyone.
If you have any questions or run into any issues, post them on the Secret Developer Discord and somebody will assist you shortly.
Learn how to use Secret Network smart contracts to encrypt and decrypt votes on Polygon testnet.
For a detailed demonstration, you can watch our video tutorial available here:
After we've gone through an extensive example on how our example contract works, here's how to implement SecretVRF via SecretPath in your own contract in 4 easy steps:
First, import the ISecretVRF
interface into your Solidity Contract:
Now, we implement the function that calls the SecretVRF Gateway on EVM. Note that you have to pay an extra amount of your gas token as CallbackGas:
The callback gas is the amount of gas that you have to pay for the message coming on the way back. If you do pay less than the amount specified below, your Gateway TX will fail:
From here, the SecretVRF Gateway will take care of everything, just wait 1-2 blocks for Gateway to provide you the random number by getting it from the Secret Networks on chain VRF and do the callback.
The SecretVRF gateway contract will always call the contract that called the VRF contract (using msg.sender
) with the function selector bytes 0x38ba4614
, which is the function:
Now, the SecretVRF Gateway contract will verify the validity of the call and when all checks pass, it will call this function. In this case, we just emit a log as an example to finish our demo. Emitting a log is not obligatory and optional.
Learn how to use SecretPath to vote confidentially on the EVM
In this developer tutorial, you will learn how to use SecretPath to enable confidential voting on the EVM.
At a high level, you can think of SecretPath as a confidential bridge that passes encrypted data from your EVM chain to a Secret Network smart contract where the data remains encrypted.
To work with SecretPath, you must first create a Secret smart contract that stores the encrypted data that you want to send from the EVM. For our purposes, we have created a Secret smart contract with 2 functionalities:
Create proposals
Vote on existing proposals
You create and vote on proposals from the EVM, and then that data is sent to your Secret smart contract via SecretPath where it remains encrypted . Pretty cool, right!? 😎 Let's start by examining our Secret voting contract, and then we will breakdown how to send messages to it from the EVM with SecretPath.
cd into secretpath-tutorials/secretpath-voting/voting-contract:
Compile the contract
cd
into voting-contract/node:
Install the node dependencies
Set SecretPath parameters:
Upload and instantiate the contract:
Now that you have instantiated your confidential voting contract on Secret Network, it's time to pass your encrypted data from the EVM to Secret Network. Remember the create_proposal
and create_vote
functions from the Secret contract? Now you will execute those functions and send encrypted data to the voting contract! 🤯
Let's create and vote on your first proposal with SecretPath!
cd
into secretpath-voting/frontend
:
Install the dependencies
Configure env
Run the application
You should see the following React application running locally in the browser:
Now, create and vote on a proposal to understand the frontend functionality. Then, let's look at the underlying code to understand how we are passing encrypted data from the EVM to Secret Network 🙂
Passing Encrypted Data with SecretPath
Create a Voting Proposal
The majority of the handleSubmit
function is boilerplate code used for SecretPath verification, signing, and converting contract inputs into correctly formatted packets and vice versa.
Now that you have all of your SecretPath code configured, execute the frontend to send your voting proposal to the Secret contract!
Vote on a Proposal
The voting contract is designed so that each proposal has an ascending index starting with 1. The first proposal you create is index 1, the second is index 2, etc. So when you vote, the React application passes the corresponding index of the proposal that is to be voted on 🙂
Execute the frontend to vote on an existing proposal and send the encrypted vote to the Secret contract!
Secret Queries - retrieving proposals and votes from Secret contract storage
These queried proposals and their associated votes are then displayed in our React frontend.
Note: the end user of the application is not exposed to Secret Network and is only working directly in the EVM environment. However, the data is fully protected and cannot be viewed by anyone because it is stored in encrypted Secret contracts 😮💨
Learn how to use Secret Network smart contracts to encrypt and decrypt votes on Polygon testnet.
In this tutorial you will learn how to encrypt and decrypt votes on the EVM with Secret Network smart contracts so that you can build confidential voting on any EVM chain of your choosing. You will be working with two smart contracts:
The EVM contract stores encrypted proposals and votes, and the Secret contract decrypts the stored votes and reveals them in a query.
You will start by configuring your developer environment and then learn how to generate cryptographic keys in a Secret Network smart contract which you will use to encrypt votes on the EVM.
cd
into examples/evm-confidential-voting/polygon:
Install the node dependencies:
Make sure your Infura API key is configured for Polygon Matic testnet 😎
Next, generate encryption keys for your EVM contract and automatically add them to your env
file by running create_keys.js
:
cd
into examples/evm-confidential-voting/secret-network:
Compile the Secret Network smart contract:
If you are on a Mac and run into compilation error:
error occurred: Command “clang”
cargo clean
cd
into examples/evm-confidential-voting/secret-network/node
Install the node dependencies:
Upload the Secret Network smart contract:
Upon successful upload a codeHash
and contract address
is returned:
Update the env
file with your codeHash
and contract address
:
To create encryption keys, run node create_keys
:
After you generate your keys successfully, query your public key:
Which returns your public key as a string
:
Add the public_key to your env
file:
Now it's time to upload a Voting contract to the EVM, which you will use to store encrypted votes that can only be decrypted by your Secret Network smart contract.
cd
into examples/evm-confidential-voting/polygon:
Compile your Solidity smart contract:
Once the contract is compiled successfully, upload the contract to Polygon testnet:
Note the contract address:
Add the Polygon testnet contract address to your env
file:
For testing purposes, set quorum
to 1 unless you want to test with multiple wallet addresses
Then run create_proposal.js
:
A transaction hash
will be returned upon successful execution:
You can query the proposal by running query_by_proposal_id
:
Which returns your proposal:
Each time you create a proposal, the proposalId
is incremented by 1. Your first proposalId
is 1, your next proposalId
will be 2, and so on.
proposal.id
and proposal.description
will match the proposal info you input for getProposalById.
This means that each time you vote, you need to make sure you update the proposal_id
number that you pass to getProposalById()
so that it matches the proposal you want to vote on!
Once you have updated your vote
and proposalId
, execute the vote script:
Your encrypted data and transaction hash are returned upon successful execution:
Now it's time to decrypt your vote! First, query that the vote was successfully added to the proposal by running query_proposal_votes.js
:
query_proposal_vote
returns your encrypted vote for the supplied proposalId
:
Run decrypt.js
to decrypt the vote:
Which returns your decrypted vote:
Got improvements or suggestions on how to improve SecretVRF or this tutorial ? Please ask in the Secret Network or Discord.
Second, set your gateway address to the Secret VRF Gateways that you can find and . You only need to make sure that your contract knows the correct SecretVRF Gateway address, for example:
Since this check is dependent on the current block.basefee
of the block it is included in, it is recommended that you estimate the gas fee beforehand and add some extra overhead to it. An example of how this can be implemented in your frontend can be found in this and here:
enables EVM developers to use Secret Network as a Confidential Computation Layer (CCL) for .
See a fullstack cross-chain voting demo .
.
.
To get started, clone the :
Open and examine the match
statement at :
This handle msg
is where you define the functionality of your SecretPath contract. For our purposes, we have written the functions and . You can examine those functions in more detail if you'd like and make adjustments as you see fit 🤓.
Update the file with your Secret Network wallet mnemonic, and rename it ".env" instead of ".env.example"
Open and configure the SecretPath gatewayAddress
, gatewayHash
, and gatewayPublicKey:
gatewayAddress, gatewayHash
, and gatewayPublicKey
are needed for instantiating contracts that utilize SecretPath and can be found in the docs . You will always use these same 3 parameters for instantiating a SecretPath-compatible contract on testnet.
Upon successful upload and instantiation, add the contract codeHash
and address
to your.
Configure the with your confidential voting contractAddress
and codeHash.
As stated above, we have two functions we are executing with SecretPath: create_proposal
and create_vote
. In our React application, there are two corresponding components which execute these functions: and .
Open CreateProposal.js and navigate to the function, which contains all of our SecretPath logic.
For our purposes, we only need to examine 2 lines of code, data
and handle
on
data
is the encrypted data that we are passing from the EVM to the Secret Network voting contract. It takes a user input of name
, description,
and end_time
. This corresponds with the in the Secret contract.
handle
is the function that is actually being called in the Secret contract that you deployed. You are passing the create_proposal
handle, which executes the function in your Secret voting contract.
Upon successful execution, your SecretPath will be logged in the console.
Open and navigate to the function, which, again, contains all of our SecretPath logic.
is the encrypted data that we are passing from the EVM to the Secret Network voting contract. It takes a user input of vote
, ("yes" or "no"), wallet_address
(the wallet address of the voter), and index.
This corresponds with the in the Secret contract.
handle:
You are passing the create_vote
handle, which executes the function in your Secret voting contract.
Upon successful execution, your SecretPath will be logged in the console.
Perhaps you are wondering how the React frontend queries the Secret voting contract to display the data that we pass from the EVM. This is possible with , the javascript SDK for Secret Network.
We have defined in our Secret voting contract, RetrieveProposals
and RetrieveVotes.
Once you have created proposals with votes, you can use execute these query functions with secret.js to:
Congrats! You deployed your very own confidential voting contract on Secret Network and used SecretPath to send cross-chain encrypted votes on an EVM chain. See the fullstack demo . You now have all of the tools you need to start building your own cross-chain SecretPath contracts on the EVM 🎉
If you have any questions or run into any issues, post them on the and somebody will assist you shortly.
Let's dive a little deeper into the boilerplate SecretPath code to understand how our data is encrypted, signed, and formatted by SecretPath. The following comments are for the function of our CreateProposal component:
deployed on Polygon testnet (voting contract)
deployed on Secret testnet (decryption contract)
See a , configured for Polygon testnet! (To use the demo, make sure Polygon testnet is added to your Metamask wallet)
To get started, clone the :
.
.
.
.
Update the env
with your Secret Network wallet mnemonic, EVM wallet private key, and API key:
Now you are ready to upload the smart contracts!
Make sure you have the of Xcode installed and then update your clang path by running the following in your terminal:
AR=/opt/homebrew/opt/llvm/bin/llvm-ar CC=/opt/homebrew/opt/llvm/bin/clang cargo build --release --target wasm32-unknown-unknown
See for instructions on updating your clang path.
Now that your Secret Network smart contract is instantiated, you can execute the contract to generate encryption keys as well as decrypt encrypted messages. To learn more about the encryption schema, see the EVM encryption docs .
Now that your Polygon smart contract is instantiated, you can execute the contract to create voting proposals as well as vote on existing proposals. You can review the solidity contract .
To create a , you must include a proposal description (a "yes" or "no" question) as well as a quorum number, which is the number of unique wallet addresses required to vote on the proposal before it closes.
Open create_proposal.js
and update the to a "yes" or "no" question of your choice:
Be sure to update the proposalId
in with the proposalId
you want to query!
Now it's time to vote on the proposal you created. Open and update your proposal answer to either "yes" or "no" in the msg object:
Be sure to update the with the proposal you want to query.
In , update the with the proposal you want to query.
Congrats! You have now deployed smart contracts on Polygon and Secret Network and implemented private cross-chain voting. If you have any questions or run into any issues, post them on the and somebody will assist you shortly.
Need help with using encrypted payloads with Snakepath or want to discuss use cases for your dApp? Please ask in the Secret Network Telegram or Discord.
First, install all of the the dependencies via NPM:
Next, import the following into your code:
In your vite.config.ts
in the project, you need to add the support for bigInt
into the esbuildOptions:
To start, we first define all of our variables that we need for the encryption, as well as the gateway information:
First, we define the Gateway address that is specific to each chain, which can you can look up here Supported Networks.
Second, you need to input the private contract that you are going to call, in our case the Secret VRF RNG contact on Secret Network. The code for this example contract can be found here in case you want to deploy it yourself.
Next, init the Ethereum client that you are using to call the contract with. Here, we init the chainId to use the Ethereum sepolia testnet and use ethers.js to retrieve the address.
Next, you generate ephermal keys and load in the public encryption key for the Secret Gateway that you can look up in Supported Networks. Then, use ECDH to create the encryption key:
Next, you define all of the information that you need for calling the private contract on Secret + add the callback information for the message on its way back.
We begin by defining the function that we are going to call on the private secret contract, here it's request_random
. Next, we add the parameters/calldata for this function, which is ("{ numWords: Number(numWords) }"
and convert it into a JSON string.
Next, we define the callback Information. In this case, we are using the gateway contract as an example callback. Here, you would typically put in your own custom callback address and callback selector in.
After defining the contract call and callback, we now construct the payload:
Next, we encrypt the payload using ChaCha20-Poly1305. Then, we hash the encrypted payload into a ciphertextHash
using Keccak256.
Next, we use Metamask to sign the ciphertextHash
using personal_sign
. Then, we recover the user_pubkey
from this signed message, which will be also passed into the Public Gateway.
Internally, Metamask takes the ciphertextHash
, preprends the "\x19Ethereum Signed Message:\n32"
string and then hashes it using Keccak256, which results the payloadHash
. Metamask actually signs the payloadHash
to get the signature. Keep this in mind when verifying the signature against the payloadHash
and NOT the ciphertextHash
.
The callback gas is the amount of gas that you have to pay for the message coming on the way back. If you do pay less than the amount specified below, your Gateway TX will fail:
Since this check is dependent on the current block.basefee
of the block it is included in, it is recommended that you estimate the gas fee beforehand and add some extra overhead to it. An example of how this can be implemented in your frontend can be found in this example and here:
Lastly, we pack all the information we collected during previous steps into an info
struct that we send into the Gateway contract. We the encode the function data. Finally, we set the tx_params. Please make sure to set an approiate gas amount for your contract call, here we used 150k gas. For the value of the TX, we send over the estimated callback gas that we calculated above.
Coming soon 😎
Coming soon 😎
SecretVRF stands out in the competitive landscape of verifiable random functions (VRFs) by offering a significant cost and speed advantage over its principal competitors. Notably, it provides approximately a 4 times cost benefit, which is a massive saving for projects that rely on random number generation at scale. This economic efficiency is largely due to its optimized gas usage, which minimizes the on-chain transaction cost.
In addition to its cost benefits, SecretVRF is also twice as fast as its closest competitor. This speed improvement is critical for applications that require almost real-time randomness, such as gaming, lotteries, and various DeFi protocols.
To demonstrate, we have this small video here outlining all of the advantages of SecretVRF vs. its biggest competitor:
An example contract call using SecretVRF on Ethereum Sepolia which requests 20 random words is compared for its gas usage. Here, we use the example contracts provided in the documentation of Chainlink. In both cases, response time for Secret VRF is at around 1-2 blocks, so around 10s.
94k Gas with Secretpath: Etherscan Sepolia
300k+ Gas for Chainlink VRF with their example project: Etherscan Sepolia
55k gas with Secretpath: Etherscan Sepolia
200k+ gas for Chainlink VRF with their example project: Etherscan Sepolia
In total, we also do not need to pay in special LINK tokens and instead can just pay in the native gas token of the chain (here: Sepolia ETH), which saves you additional costs.
To summarize, SecretVRF's combination of cost efficiency, speed, and EVM chain compatibility makes it a compelling choice for developers and projects seeking reliable and economical verifiable random functions. Its technical innovations position it as a leader in the space, offering tangible benefits that can significantly enhance the performance and cost-effectiveness of a wide range of blockchain applications.
Learn how to use SecretPath on EVM to access on-chain verifiable random numbers.
SecretVRF over SecretPath enables EVM developers to access on-chain verifiable random numbers at a fraction of the cost and block time of traditional RNG oracles such as ChainlinkVRF. With fewer than 100 lines of code, you will have access to an infinite supply of randomness.
See a fullstack cross-chain SecretVRF demo here
To learn how SecretVRF works underneath the hood, refer to the docs here. 🤓
To get started, clone the Secret Labs examples repo:
cd
into examples/EVM-snakepath-RNG:
Install the node dependencies:
Update the env
file with your EVM wallet private key and Infura API key.
Make sure your Infura API key is configured for Polygon Matic testnet 😎
Compile your Solidity smart contract:
Once the contract is compiled successfully, upload the contract to Polygon testnet:
Note the contract address:
Add the RandomnessReceiver
contract address to your env
file:
Now that you've uploaded your contract, it's time to set the SecretPath gateway address for Polygon Mumbai and then request on-chain verifiable random numbers!
Gateways are the on-chain smart contracts that handle the broadcasting, receipt, packaging, and verification of messages.
First, set the gateway address for Polygon Mumbai testnet. You can do this by executing set_gateway.js
:
This tutorial is for Polygon testnet,, but you can find a list of additional EVM gateway contract addresses here.
Next, create an event listener so you can listen to when the random numbers that you request have been fulfilled.
Open a new terminal window and cd
into examples/EVM-snakepath-RNG:
Then, create the event listener by executing fulfill_randomness_event.js
:
Now it's time to request random numbers! Currently, request_random.js
is configured to request 3 random numbers, but you can update how many numbers you would like to request here (up to 2000 for this example).
Once you have configured how many random numbers you want to request, execute request_random.js
:
Upon successful execution, your terminal will log the following:
Navigate to your event listener terminal to see the returned random numbers:
Congrats! You've just used SecretPath to request your first verifiable on-chain random numbers! 🎉
If you don't see your random numbers returned, it means that our testnet relayer might have dropped the transaction. See below to learn how to relay your transaction manually.
To relay your random numbers manually, you can use Polygonscan and Secret.js!
After you execute request_random.js
and have a task_id
returned, you can now execute query_secret_network
for the given task_id.
Open query_secret_network.js
and update the task_id
to your task_id
. Then execute query_secret_network.js
:
The query will return info about your transaction for the given task_id
:
Now, open Polygonscan for the Mumbai proxy contract and then input the returned query info into the postExecution
field:
Once you have entered your transaction info, select "Write" to execute the transaction.
Congrats! You've just used SecretPath to request your first verifiable on-chain random numbers! 🎉
Secret VRF offers an innovative and cost-effective solution for EVM developers seeking access to verifiable random numbers. By following this guide, you've successfully set up your environment, deployed the RandomnessReceiver.sol
contract, and interacted with the SecretPath network to request and receive random numbers. Dive into the world of decentralized randomness with SecretPath, where security meets simplicity. 🌟
To access the SecretPath gateways, please refer to the gateway contracts for testnet and mainnet here:
To access configuration files for SecretPath, please refer to the repository here:
Converting from Chainlink VRF to Secret VRF is easier than you expect. Within four easy steps you can free your contract from bloat and use the lightweight and faster Secret VRF solution.
In the first step, we remove the imports and the inheritance of the VRFConsumerBaseV2 and add our SecretVRF interface from this. There is no
to get to this:
Here, the behavior of the callbackGasLimit
is different than in ChainlinkVRF. The callback Gas limit is simply all of the gas that you need to pay in order to make callback, which includes the verification of the result as well. The callback gas is the amount of gas that you have to pay for the message coming on the way back. We recommend at least using 100_000+
in Callback gas to ensure that enough gas is available. In case you did not pay enough gas, the contract callback execution will fail.
Next, we can also simplify the constructor since we do not need to define any extra variables or subscriptionIds. Going from this:
to this
Next, we need to slightly adjust the behavior of the function rollDice(address roller)
function and how it calls the Request Randomness function within Secret VRF. Here, we need to use the Secet VRF gateway and call it directly instead.
Make sure to now mark this function as payable
!
Please make sure to actually prepay the right amount of callback gas directly as a value transfer into the contract. The callback gas is the amount of gas that you have to pay for the message coming on the way back. If you do pay less than the amount specified below, your Gateway TX will fail:
Lastly, we'll add a small check to ensure that we actually got an incoming call from the SecretVRF gateway contract. For this, remove the internal
and override
flags on the function and add the require:
That's all that you need to convert your contract from ChainlinkVRF to SecretVRF.
Got improvements or suggestions on how to convert your ChainlinkVRF contract to SecretVRF ? Please ask in the Secret Network or Discord.
We start off with the example code from Chainlink from :
Since this check is dependent on the current block.basefee
of the block it is included in, it is recommended that you estimate the gas fee beforehand and add some extra overhead to it. An example of how this can be implemented in your frontend can be found in this and here:
For the Secret Network mainnet (secret-4) side, the gateway contract information are:
Gateway contract code id: 1533
Gateway contract address: secret1qzk574v8lckjmqdg3r3qf3337pk45m7qd8x02a
Gateway contract code hash: 012dd8efab9526dec294b6898c812ef6f6ad853e32172788f54ef3c305c1ecc5
Gateway encryption key for ChaChaPoly1305: AqDWMqzQ0vXaAvw4XqMKjeq01WOdGoIaOlUmJa0PF1nQ
Public key: 0x04a0d632acd0d2f5da02fc385ea30a8deab4d5639d1a821a3a552625ad0f1759d0d2e80ca3adb236d90caf1b12e0ddf3a351c5729b5e00505472dca6fed5c31e2a
Derived Ethereum Address from Public Key: 0x88e43F4016f8282Ea6235aC069D02BA1cE5417aB
The RNG contract that provides the Randomness is:
RNG contract code id: 1534
RNG contract address: secret16pcjalfuy72r4k26r4kn5f5x64ruzv30knflwx
RNG contract code hash: 49ffed0df451622ac1865710380c14d4af98dca2d32342bb20f2b22faca3d00d
Can't find your network here? Please ask in the Secret Network Telegram or Discord to support it.
Network | Chain-ID | Gateway Address | Proxy Admin | Contract Version |
---|---|---|---|---|
Can't find your network here? Please ask in the Secret Network or Discord to support it.
Network | Chain-ID | Gateway Address | Proxy Admin | Contract Version |
---|
Ethereum
1
0xfaFCfceC4e29e9b4ECc8C0a3f7df1011580EEEf2
0xdDC6d94d9f9FBb0524f069882d7C98241040472E
0.1.0
Binance Smart Chain (BSC)
56
0xfaFCfceC4e29e9b4ECc8C0a3f7df1011580EEEf2
0xdDC6d94d9f9FBb0524f069882d7C98241040472E
0.1.0
Polygon PoS
137
0xA91712bb011eFB27622ca2BAB940E2589954d3d7
0xf0ddC73F201409040afC2a8633014B339ce80176
0.1.0
Optimism
10
0xfaFCfceC4e29e9b4ECc8C0a3f7df1011580EEEf2
0xdDC6d94d9f9FBb0524f069882d7C98241040472E
0.1.0
Arbitrum One
42161
0xfaFCfceC4e29e9b4ECc8C0a3f7df1011580EEEf2
0xdDC6d94d9f9FBb0524f069882d7C98241040472E
0.1.0
Avalance C-Chain
43114
0xfaFCfceC4e29e9b4ECc8C0a3f7df1011580EEEf2
0xdDC6d94d9f9FBb0524f069882d7C98241040472E
0.1.0
Base
8453
0xf50c73581d6def7f911aC1D6d0d5e928691AAa9E
0x0f119D36896631E7202F20E6aC5a66485Fe871Cd
0.1.0
Linea
59144
0xfaFCfceC4e29e9b4ECc8C0a3f7df1011580EEEf2
0xdDC6d94d9f9FBb0524f069882d7C98241040472E
0.1.0
Scroll
534352
0x59D8C9591dB7179c5d592c5bCD42694021885aFC
0x11791a1D6Ade2A398f186Efa6992AdA12F9f87b4
0.2.0-beta
Metis
1088
0x874303B788c8A13a39EFA38ab6C3b77cd4578129
0xd3C10BA03470fbD905046705824DeB047B8aAB54
0.2.0
XDC Network
50
0x8EaAB5e8551781F3E8eb745E7fcc7DAeEFd27b1f
0xb352D4449dC7355d4478784027d7AfAe69843085
0.2.0
Near Aurora
1313161554
0xEAe7aC0A51a0441D71A1Ee21005363B36f16EffC
0x8EaAB5e8551781F3E8eb745E7fcc7DAeEFd27b1f
0.2.0
Ethereum Sepolia |
|
|
|
|
Scroll Sepolia |
|
|
|
|
Polygon Amoy |
|
|
|
|
Optimsm Sepolia |
|
|
|
|
Arbitrum Sepolia |
|
|
|
|
Base Sepolia |
|
|
|
|
Berachain Artio |
|
|
|
|
Tezos Etherlink |
|
|
|
|
Metis Sepolia |
|
|
|
|
Near Aurora Testnet |
|
|
|
|
Linea Sepolia |
|
|
|
|
XDC Apothem |
|
|
|
|
Lisk Sepolia |
|
|
|
|
For the Secret Network testnet (pulsar-3) side, the gateway contract information are:
Gateway contract code id: 3375
Gateway contract address: secret10ex7r7c4y704xyu086lf74ymhrqhypayfk7fkj
Gateway contract code hash: 012dd8efab9526dec294b6898c812ef6f6ad853e32172788f54ef3c305c1ecc5
Gateway encryption key for ChaChaPoly1305: A20KrD7xDmkFXpNMqJn1CLpRaDLcdKpO1NdBBS7VpWh3
Public key: 0x046d0aac3ef10e69055e934ca899f508ba516832dc74aa4ed4d741052ed5a568774d99d3bfed641a7935ae73aac8e34938db747c2f0e8b2aa95c25d069a575cc8b
Derived EVM Address from Public Key: 0x2821E794B01ABF0cE2DA0ca171A1fAc68FaDCa06
The RNG contract that provides the Randomness is:
RNG contract code id: 3376
RNG contract address:secret1fxs74g8tltrngq3utldtxu9yys5tje8dzdvghr
RNG contract code hash: 49ffed0df451622ac1865710380c14d4af98dca2d32342bb20f2b22faca3d00d
SecretPath is a protocol for lightweight, secure, privacy preserving message-passing between chains. Its purpose is to serve as a critical building block for bringing private data onchain in a useful yet privacy-preserving manner.
SecretPath itself does not store or compute over data. Rather, it connects public blockchains and their applications to privacy-preserving computation networks. This design allows public blockchain applications to build and operate private computation contracts on privacy-preserving chains while keeping their primary smart contract logic and liquidity on public blockchains.
Ultimately, SecretPath enables the building of new applications that combine the transparency, UX, and latency benefits of public blockchains with the trust-minimized and private computation features of privacy-preserving blockchains.
The following sections provide a detailed technical overview of the current relayer and gateway architecture for SecretPath.
As an user and developer, all you need to know is how to send messages to one gateway/receive messages from a gateway, which will be covered in those respective documentation sections. More tutorials with encrypted payloads are coming soon.
Need help with using SecretPath or want to discuss use cases for your dApp? Please ask in the Secret Network or Discord.
In technical terms, SecretPath is a message passing system for non-malleable, trustless interchain message passing. In more practical terms, SecretPath enables public chains to call arbitrary functions on private compute chains while preserving the privacy of the inputs and validity of the outputs. SecretPath is built using a primitive that we call TNLS ("Transport Network Layer Security") which is effectively a blockchain derivative of the .
To get an overview of the Architecture go here:
If you like to use SecretVRF in the most elegant way for you as an EVM developer, go here:
To review supported EVM chains, go here:
As a maintainer, you might want to look more closely at the relayer section of the codebase as well here:
You can try a demo of SecretPath that bridges Secret VRF into EVMs here:
This documentation was adapted from , courtesy of Leor Fishman.
Learn how to connect your Metamask wallet address to a Secret wallet address.
Connect your Metamask wallet here to receive your Secret testnet wallet address
Fund your Secret testnet wallet address with the testnet faucet
Now you have a Secret testnet wallet address that you can use to sign transactions with your Metamask wallet!