# API Reference Source: https://docs.solayer.org/documentation/api-reference/devnet-rpc Complete reference for Solayer's RPC API endpoints Solayer's RPC API provides compatibility with Solana's JSON RPC API while introducing optimizations for the Solayer Chain architecture. This reference documents all supported methods, upcoming features, and deprecated endpoints. ## HTTP Endpoint ``` https://devnet-rpc.solayer.org ``` ## Currently Supported Methods The following methods are fully implemented and available for use: | Method | Description | | ------------------------ | -------------------------------------------------------------------- | | `getAccountInfo` | Returns all information associated with an account | | `getBalance` | Returns the balance of an account | | `getBlock` | Returns identity and transaction information about a confirmed block | | `getBlocks` | Returns a list of confirmed blocks | | `getLatestBlockhash` | Returns the latest blockhash | | `getSignatureStatuses` | Returns the statuses of a list of signatures | | `getTokenAccountBalance` | Returns the token balance of an account | | `getTokenSupply` | Returns information about the total supply of an SPL Token type | | `getTransaction` | Returns transaction details | | `sendTransaction` | Submits a signed transaction to the cluster | ### Modified Methods | Method | Modification Details | | ---------------- | ----------------------------------------------------------------------------------------------------------- | | `requestAirdrop` | Modified to airdrop exactly 0.1 SOL (Solayer devnet). The amount parameter has been removed for simplicity. | ## Coming Soon These methods are under development and will be available in future updates: * `getFeeForMessage` * `getLargestAccounts` * `getProgramAccounts` * `getRecentPrioritizationFees` * `getSignaturesForAddress` * `getTokenAccountsByDelegate` * `getTokenAccountsByOwner` * `getTokenLargestAccounts` ## Unsupported Methods The following methods are not supported: * `getClusterNodes` * `getHighestSnapshotSlot` * `getInflationGovernor` * `getInflationRate` * `getInflationReward` * `getLeaderSchedule` * `getMaxRetransmitSlot` * `getMaxShredInsertSlot` * `getSlotLeader` * `getSlotLeaders` * `getStakeMinimumDelegation` * `getSupply` * `getVoteAccounts` * `minimumLedgerSlot` ## Deprecated Methods These methods are supported but deprecated due to Solayer Chain's architecture changes: * `getBlockCommitment` * `getBlockHeight` * `getBlockProduction` * `getEpochInfo` * `getEpochSchedule` * `getBlockTime` * `getFirstAvailableBlock` * `getGenesisHash` * `getHealth` * `getIdentity` * `getMinimumBalanceForRentExemption` * `getRecentPerformanceSamples` * `getSlot` * `getTransactionCount` * `getVersion` * `isBlockhashValid` ## Notes on Deprecated Methods Methods marked as deprecated are still functional but may not provide meaningful information due to Solayer's architectural differences from Solana. For example, concepts like epochs and slots are handled differently in Solayer Chain's high-throughput architecture. ## Error Handling All RPC methods follow standard JSON-RPC 2.0 error handling conventions. Errors will be returned in the following format: ```json theme={null} { "jsonrpc": "2.0", "error": { "code": number, "message": string, "data": object }, "id": number } ``` ## Rate Limits The devnet RPC endpoint has rate limiting in place to ensure fair usage. For production applications requiring higher limits, please contact the Solayer team. # Solayer Chain Historical Data Access Source: https://docs.solayer.org/documentation/archival-data Access Solayer's archival data via Delta Sharing # Historical Data Access Solayer provides historical Solayer Chain data access through **Delta Sharing**, an open protocol for secure, cross-platform data sharing. This allows you to access historical blockchain data, transaction records, and protocol analytics directly from your preferred tools and environments. This historical data is for **Solayer Chain Mainnet** only. ## Overview Delta Sharing enables secure data sharing without copying data. You can read and analyze the shared data using various tools including: * **Python** (with Pandas) * **Apache Spark** * **Power BI** * **Tableau** * **Snowflake** and other Iceberg clients Access persists as long as the credential is valid. Updates to the data are available in near real time. You can read and make copies of the shared data for your analysis. ## Available Tables Two tables are available through Delta Sharing: | Table | Description | Partition Column | | -------------- | ------------------------------------------------------------ | ---------------- | | `transactions` | All Solayer Chain transaction records with execution results | `block_date` | | `blocks` | Block-level metadata including hashes and timestamps | `block_month` | ### Transactions Table The `transactions` table contains detailed records of all Solayer Chain transactions. | Column | Type | Description | | ------------------------- | -------------- | -------------------------------------------------------------------- | | `signature` | STRING | Unique transaction signature (not null) | | `slot` | BIGINT | Slot number (not null) | | `shred_index` | BIGINT | Shred index within the slot (not null) | | `block_unix_timestamp` | BIGINT | Unix timestamp of the block (not null) | | `block_date` | DATE | Partition column, auto-generated from timestamp | | `versioned_tx` | VARIANT | Nested JSON containing signatures, message, etc. (not null) | | `execution_result` | VARIANT | Full Ok/Err structure: `{"Ok": null}` or `{"Err": {...}}` (not null) | | `job_effect_diff` | VARIANT | Contains pre\_accounts, diffs, pre\_balances, account\_diff\_ops | | `status` | STRING | "Success" or "Fail" | | `err` | STRING | Error details (only present when status = "Fail") | | `log_messages` | ARRAY\ | Array of log message strings | | `inner_instructions` | VARIANT | Nested structure for inner instructions | | `return_data` | VARIANT | Transaction return data | | `executed_units` | BIGINT | Compute units consumed (not null) | | `accounts_data_len_delta` | BIGINT | Change in account data length (not null) | | `fee` | BIGINT | Transaction fee in lamports (not null) | To filter successful transactions, use `execution_result:Ok IS NOT NULL` in your queries. ### Blocks Table The `blocks` table contains block-level metadata. | Column | Type | Description | | ---------------------- | ------ | ---------------------------------------- | | `slot` | BIGINT | Slot number, primary key (not null) | | `block_unix_timestamp` | BIGINT | Unix timestamp of the block (not null) | | `block_month` | DATE | Partition column, first day of the month | | `blockhash` | STRING | Block hash (not null) | | `parent_blockhash` | STRING | Parent block hash | ## Credential File To access Solayer's historical data, save the credential file below as a `.share` file (e.g., `solayer.share`) on your local system: ```json theme={null} { "shareCredentialsVersion": 1, "bearerToken": "ZWatTOE294P9bB30V-SBjZYnhgz5CM3DySSrDBoedk1UgL0YCJJdC0lDktWPnc4y", "endpoint": "https://oregon.cloud.databricks.com/api/2.0/delta-sharing/metastores/7a9fc20e-6a36-4fef-98fb-3c6c7c72f622", "expirationTime": "2027-01-14T19:43:33.280Z", "icebergEndpoint": "https://oregon.cloud.databricks.com/api/2.0/delta-sharing/metastores/7a9fc20e-6a36-4fef-98fb-3c6c7c72f622/iceberg" } ``` This credential expires on **January 14, 2027**. If you need access after this date, please contact the Solayer team. ## How to Access the Data For detailed instructions on how to read and query the shared data using your preferred tool, please refer to the official Databricks documentation: Complete guide for reading data shared via Delta Sharing with bearer tokens, including examples for Python, Spark, Power BI, Tableau, and more. ## Support If you encounter any issues or have questions about accessing the historical data: * Join our [Discord community](https://discord.com/invite/solayerlabs) * Follow us on [Twitter/X](https://twitter.com/solayer_labs) for updates # Introduction Source: https://docs.solayer.org/documentation/block-propagation/introduction Solayer Chain Synchronization ## Solayer Chain Synchronization This article covers the synchronization between Solayer Chain leader node, verifier nodes, and RPC nodes. It covers contents to sync, and also data frame specification between clients. ## Stakeholders **Leader Node**: The leader node / sequencer node is the node that is responsible for consuming, scheduling, executing, and committing transactions to produce new blocks. The leader node streams shreds (incomplete blocks) to the subscribers. **Verifier Node**: The verifier node is the node that is responsible for verifying the transactions and the state of the leader node with streams directly from the leader node. The verifier node can forward streams to RPC nodes. The verifier node must stake \$LAYER token to operate. **RPC Node**: The RPC node is the node that is responsible for serving the requests from the clients. The RPC node can connect to the leader node or verifier node to receive state and transaction data. The RPC node can choose to index information like transaction history, account history, etc. The RPC does not need to stake \$LAYER token to operate but is recommended. ## Data Streams **Shreds**: Shreds are the basic unit of data in Solayer Chain. They are the smallest unit of data that can be sent and received. A shred contains a set of transactions and a set of account updates. Shreds are sent to the subscribers before the leader node commits a slot. **Slots**: Slots are the unit of block in Solayer Chain. A slot contains a set of shreds and the slot hash that hashes all state changes in the slot. # Protocol specification Source: https://docs.solayer.org/documentation/block-propagation/protocol-specification # Protocol Specification Solayer Chain uses gRPC to communicate for synchronization purposes, including streaming the latest slot information. gRPC is chosen over QUIC because it is better supported by SDN switches, which the sequencer uses for packet preprocessing, forwarding, and load balancing. In addition to gRPC streaming, Solayer Chain also uses HTTP to serve snapshots that allows for verifier and RPC nodes to sync. The HTTP service is expected to be exposed to public users, with CDN and PCDN enabled. ## Protobuf Definition The protobuf definition below specifies the gRPC service interface and message formats used for Solayer Chain synchronization. The protocol uses bincode+zstd for transaction data to optimize network bandwidth and includes detailed metadata to support both streaming and repair operations. Key methods and streaming endpoints: * **GetLatestSlot**: Retrieves current slot information for synchronization (equivalent to Solana RPC `getSlot` with `confirmed` finality). * **StartReceivingSlots**: Streams slot data from the leader node, including blockhash, parent blockhash, timestamp, and shred IDs (equivalent to Solana RPC `getSlot` with `confirmed` finality). * **SubscribeTransactionBatches**: Streams real-time transaction batch notifications containing slot number, timestamp, and all transactions with state changes (equivalent to Solana RPC `getSlot` with all transactions at `processed` finality). ```proto theme={null} syntax = "proto3"; package infinisvm.sync; message StartReceivingSlotsRequest { } message SlotDataResponse { uint64 slot = 1; bytes blockhash = 2; bytes parent_blockhash = 3; uint64 timestamp = 4; repeated uint64 job_ids = 5; } message GetLatestSlotRequest { } message GetLatestSlotResponse { uint64 slot = 1; bytes hash = 2; bytes parent_blockhash = 3; uint64 timestamp = 4; repeated uint64 shred_ids = 5; } // Transaction batch notification messages message TransactionBatchRequest { } message TransactionInfo { bytes signature = 1; uint64 slot = 2; uint64 timestamp = 3; bool success = 4; optional string error_message = 5; bytes accounts_involved = 6; // Compressed account keys uint64 fee = 7; uint32 compute_units_consumed = 8; } message CommitBatchNotification { uint64 slot = 1; uint64 timestamp = 2; uint32 batch_size = 3; bytes compressed_transactions = 4; // zstd compressed serialized transactions uint64 compression_ratio = 5; // original_size / compressed_size * 100 } service InfiniSVMService { rpc StartReceivingSlots(StartReceivingSlotsRequest) returns (stream SlotDataResponse); rpc GetLatestSlot(GetLatestSlotRequest) returns (GetLatestSlotResponse); rpc SubscribeTransactionBatches(TransactionBatchRequest) returns (stream CommitBatchNotification); } ``` ## HTTP endpoints | Endpoint | Cachable | Purpose | Response | | ------------------------------ | -------- | ------------------------ | --------------------------------- | | GET /solayer/snapshots | No | List available snapshots | JSON array of snapshot file names | | GET /solayer/files/\ | Yes | Download snapshot | zstd compressed snapshot | # Rate limit Source: https://docs.solayer.org/documentation/block-propagation/rate-limit # Rate Limit To combat the DoS attack, Solayer Chain uses rate limit to limit the number of requests from a node to the current leader node. We plan to provide two phases of rate limit as the network matures. Note that the rate limit only applies to the leader node. RPC nodes can connect to upstream nodes like other RPC nodes or verifier nodes and the rate limit is under discretion of the upstream nodes. In phase one, every IP address is allowed to connect to the network and send requests to the sequencer with bandwidth not exceeding 200Mbps, which is the minimum bandwidth required to sync at real time under 300K TPS of transfer transactions. In phase two, each node is represented by a public key with a unique IP address. when connecting to the sequencer (i.e., the leader node), the node shall provide a signature of the IP address using the private key of the node. Each node can receive bandwidth a minimum of 100Mbps after minimum stake of K \$LAYER token on that public key. With more stake, the node can receive more bandwidth. Phase two will be activated after the network is fully deployed and the participants of the network exceeds a certain threshold. # Sync stages Source: https://docs.solayer.org/documentation/block-propagation/sync-stages # Sync Stages The Solayer Chain synchronization process consists of two main phases: **initial sync** and **incremental sync**. During initial sync, a node retrieves snapshots from upstream peers (e.g., current leader node or verifier nodes) and downloads the most recent one to initialize its local Bank. After this bootstrap, the node transitions to incremental sync mode. In normal **real-time mode**, the node continuously receives slot-change notifications and their accompanying shreds via a stream, stores the shreds in an overlay database, and commits the data at each slot boundary while verifying correctness by recalculating the Bank's root hash. When the stream fails to deliver consecutive slots, the node automatically enters **repairing mode**, fetching missing slots from upstream peers (or restarting from an initial snapshot if unavailable), replaying the recovered slots, re-validating the root hash, and then returning to real-time streaming. Failure handling follows a consistent pattern: dropped streams trigger repair and fresh stream creation; non-consecutive data from upstream initiates targeted repair before resuming real-time sync; and upstream data expiry that leaves queries empty is treated as fatal, prompting operators to clear local state and restart. Integrity is guaranteed by Solana-style state validation—each block hash is the SHA-256 of its parent hash concatenated with the Merkle-rooted account-state delta, signature count, and parent blockhash, while every account hash is derived from its serialized fields. ## Initial Sync The initial synchronization phase bootstraps a new node: * Query for available snapshots from upstream peers. * Download the latest snapshot to provision the Bank. ## Incremental Sync After initial sync, nodes enter incremental sync with two operational modes: ### Real-Time Mode Normal operation mode for continuous synchronization: * Receive latest slot changes and shreds through real-time streaming from upstream peers. * Save shreds to a database overlay. * Store slot changes. * Calculate root hash and validate. * Merge the database overlay into the Bank. ### Repairing Mode Activated when the real-time stream doesn't deliver consecutive slot changes or the root hash is inconsistent: * Fetch missing slots from upstream nodes. * If missing slots are not found upstream, restart from initial sync. * Replay slot changes. * Calculate root hash and validate. * Switch back to real-time mode. ## Failure Scenarios **Real-Time Stream Disconnection**: When the streaming connection is lost, the node initiates a repair process to the latest slot, re-creates the stream connection, and then resumes real-time mode synchronization. **Non-Consecutive Slot Delivery**: When upstream nodes don't deliver consecutive slots, the node performs a repair operation to the received slot data and then resumes real-time mode synchronization. **Empty Slot Query Response**: This typically occurs when slot data in upstream nodes expires. In this scenario, the node reports a fatal error, logs the message "need to cleanup current chain data and start over", and exits the process. ## Validation After each slot is committed, RPC nodes and verifier nodes perform state validation by calculating the root hash of the Bank and comparing it with the root hash provided in the slot data. If the calculated root hash differs from the expected value, the node will transition to repairing mode to resolve the inconsistency. Solayer Chain adopts Solana's state hash calculation methodology, excluding proof-of-history (PoH) components, to compute the root hash: ``` hash = sha256(parent_hash || account_db_delta || signature_count || parent_blockhash) account_db_delta = merkle_root(account_hashes_order_by_pubkey) account_hashes_order_by_pubkey = sha256(lamports | data_len | data | owner | executable_flag | rent_epoch) ``` ## Pseudocode ``` func sync(): snapshot = http download_snapshot() bank = Bank.new(snapshot) need_repair = false last_slot = bank.current_slot() while True: if need_repair: repair(bank) need_repair = false try: stream_slot = create_slot_stream() stream_shred = create_shred_stream() while shred <- stream_shred: bank.db.add_shred(shred) while slot <- stream_slot: # deliver non-consecutive slots if last_slot < slot_data.slot: repair(bank) last_slot = bank.current_slot() else bank.commit(slot_data) last_slot = slot_data.slot except StreamDisconnected: need_repair = true continue func repair(bank): loop: current_slot = bank.current_slot() if current_slot >= grpc_get_latest_slot(): break slot_data = http_download_slot(current_slot) bank.process_slot_data(slot_data) ``` # Solayer Chain Consensus Source: https://docs.solayer.org/documentation/consensus/overview Overview of Solayer's hybrid consensus mechanism ## Overview The verifier set and their corresponding stake weights are derived at the start of each epoch from the Solana contract, and a verifier's voting power is directly proportional to its staked amount. Each stake can be delegated to multiple verifiers, while for each vote, the stake can only be used by the first verifier that submits. ## Consensus Flow For each block produced by the sequencer, the payload—including the hash, transaction batch, and associated state diff—is broadcast to the active verifier set. Each verifier probabilistically ignores blocks (to allow for higher TPS) and, for selected blocks, independently re-executes the transactions against its current state to derive a local state diff. If the locally computed state diff hash matches the block's declared state diff hash, the verifier signs the block hash using its BLS private key and returns the signature to the sequencer. Upon collecting signatures representing at least 51% of the total stake, the sequencer performs a BLS aggregation and finalizes the shard by sealing it with the aggregate signature. ## Failure Handling In the event that a quorum of verifier signatures is not reached within the predefined timeout, the sequencer initiates a retry of the round, re-broadcasting the block for revalidation. If the retry attempt also fails to secure the required 51% threshold, the consensus protocol enters a reorganization phase. At this point, the current sequencer forfeits its role, and the chain reverts to the last block that achieved successful verification. Leadership is then rotated to the next sequencer, as determined by an on-chain contract deployed on Solana. If the sequencer becomes unresponsive or fails to propagate blocks to the verifier set, verifiers independently detect the stall and invoke a timeout procedure on the Solana contract, which performs round-robin sequencer rotation. Additionally, to preserve protocol integrity, the sequencer may challenge the verifiers by submitting deliberately malformed blocks. If any verifier incorrectly signs such an invalid block, the sequencer can initiate a formal dispute on-chain by submitting both the invalid block and the verifier's signature. If validated, the verifier is penalized by slashing and removal. ## Architecture Diagrams Consensus Flow Sequencer Rotation # Consensus Specification Source: https://docs.solayer.org/documentation/consensus/specification Detailed specification of Solayer's consensus mechanism Sequencer: ```python theme={null} function buildBlock(txQueue, lastBlockHash): diff = execAll(txQueue, globalState) sdh = HASH(encode(diff)) sh = HASH(SALT || lastBlockHash || sdh || batchNumber) header = {batchNumber, lastBlockHash, sdh, sh, sig=""} return Block{header, txQueue, diff} ``` Verifier: ```python theme={null} on BlockReceived(block): localDiff = execAll(block.txs, globalState) if HASH(encode(localDiff)) == block.header.stateDiffHash: sig = BLS.sign(privᵥ, block.header.blockHash) transmit ``` Solana Contract ```rust theme={null} struct verifier { operator_address; // for bls admin_address; // for staking, unstaking etc., can be a multisig } block_consensus { // --- Epoch Management ------------- fn stake(amount: u64) // Verifier, add to verifier_queue, promote to verifier set next epoch fn unstake() // after exit delay read fn verifier_set() // get current verifier set fn submit_epoch_change() // only current sequencer can call fn sequencer_set() fn join_sequencer_set() fn leave_sequencer_set() // --- Sequencer Selection ---------- fn elect_next_sequencer() // round‑robin fn ping_timeout(old_seq_id) // called by verifiers // --- Disputes & Slashing ---------- fn submit_dispute(invalid_block, sig_v) // by sequencer fn resolve_dispute(dispute_id) // off‑chain worker posts verdict } ``` Protobuf: ```proto theme={null} syntax = "proto3"; package solayer; message QuorumCert { bytes block_hash = 1; bytes aggregate_signature = 2; // Σ sig_i (BLS aggregate) repeated StakeInfo participants = 3; // who signed & with what weight uint64 total_stake = 4; // convenience field (sum) } message Vote { bytes block_hash = 1; // must match header.block_hash bytes bls_signature = 2; // sig_i = sign(sk_i, block_hash) } message Envelope { oneof msg { Vote vote = 2; QuorumCert qc = 3; } } service Consensus { // A single long‑lived bidi stream. Either side may push: // • Block (Sequencer → Verifiers) // • Vote (Verifiers → Sequencer) // • QuorumCert (Sequencer → Verifiers once 51 % reached) rpc Stream(stream Envelope) returns (stream Envelope); } ``` # Explorer Source: https://docs.solayer.org/documentation/devnet/explorer Navigate and explore the Solayer Chain blockchain # Block Explorer The Solayer Block Explorer provides an interface to monitor and analyze activity on the Solayer Chain blockchain. Solayer Block Explorer Overview ## Accessing the Explorer Access the Solayer Block Explorer at: ``` https://explorer.solayer.org ``` ## Explorer Features ### Dashboard Overview The explorer dashboard provides real-time insights into the Solayer Chain network: * **Transaction throughput metrics**: Monitor the current TPS and performance * **Block production rate**: View how quickly new blocks are being created * **Chain statistics**: Total transactions, epoch status, and slot information Solayer Block Explorer Stats ### Search Functionality The search bar allows you to find detailed information by entering: * Account addresses * Transaction signatures * Block IDs * Program IDs * Token addresses ## Integrated Faucet The explorer includes an integrated faucet for obtaining devnet SOL: 1. Navigate to the Faucet tab 2. Enter your wallet address 3. Receive 0.1 SOL for testing purposes The explorer is continuously being enhanced with new features to support developer needs. During the devnet phase, some advanced features may be under development. # Faucet Source: https://docs.solayer.org/documentation/devnet/faucet Get devnet SOL tokens for testing and development The Solayer Devnet Faucet provides developers with devnet 0.1 SOL to pay for fees while deploying programs or testing transactions on the Solayer devnet. This faucet is **only available on devnet** and is intended for **testing and development purposes**. For production applications, use the mainnet RPC endpoint: `https://mainnet-rpc.solayer.org` ## Receive Devnet SOL using the CLI ### 1. Configure your Solana CLI First, check your current configuration: ```bash theme={null} solana config get ``` Set your RPC configuration to Solayer's devnet (for testing): ```bash theme={null} solana config set --url https://devnet-rpc.solayer.org ``` ### 2. Request an Airdrop Use the following command to request an airdrop of 0.1 SOL (devnet) to your wallet: ```bash theme={null} solana airdrop --url https://devnet-rpc.solayer.org ``` This airdrop command only works on the devnet endpoint and is for testing purposes only. Replace `` with your development wallet's public key. ## Receive Devnet SOL using Solayer's Block Explorer For a more user-friendly experience, you can use the faucet interface on Solayer's block explorer: 1. Visit [Solayer Block Explorer](https://explorer.solayer.org) 2. Navigate to the Faucet section 3. Enter your wallet address 4. Request your 0.1 devnet SOL Each wallet address can receive 0.1 SOL per request through either the CLI or block explorer interface. # Rent Exemption Compatibility Source: https://docs.solayer.org/documentation/introduction/advanced-features/rent-exemption Solayer Chain uses **1% of Solana's rent** for account storage, making it **99% cheaper** to create accounts. However, this difference requires developers to use the correct instructions to avoid overpaying rent when creating tokens and accounts. ## Why This Matters Solana programs can fetch rent in two ways: | Method | Behavior | Result on Solayer Chain | | --------------------- | ---------------------------- | ------------------------------------------ | | `Rent::get()` syscall | Fetches rent from runtime | **Correct** - uses Solayer Chain's 1% rent | | `Rent::default()` | Uses hardcoded Solana values | **Wrong** - charges 100x too much | Instructions that rely on the **Rent sysvar account** internally use `Rent::from_account_info()`, which behaves like `Rent::default()` and returns Solana's hardcoded rent values. This causes **100x overpayment** on Solayer Chain. ## Token Program Instructions The original Token Program includes both legacy instructions (which use the Rent sysvar) and newer variants (which use the `Rent::get()` syscall). ### Instructions to Avoid | Instruction | Issue | | -------------------- | ----------------------------------------- | | `InitializeMint` | Requires Rent sysvar, uses hardcoded rent | | `InitializeAccount` | Requires Rent sysvar, uses hardcoded rent | | `InitializeMultisig` | Requires Rent sysvar, uses hardcoded rent | ### Recommended Instructions | Instruction | Benefit | | --------------------- | ---------------------------------------------------- | | `InitializeMint2` | Uses `Rent::get()` syscall, correct rent calculation | | `InitializeAccount2` | Uses `Rent::get()` syscall, correct rent calculation | | `InitializeAccount3` | Uses `Rent::get()` syscall, most efficient variant | | `InitializeMultisig2` | Uses `Rent::get()` syscall, correct rent calculation | ## Token 2022 Instructions Token 2022 (Token Extensions) follows the same pattern. Always use the "V2" or "V3" variants. ### Instructions to Avoid | Instruction | Issue | | -------------------- | -------------------- | | `InitializeMint` | Requires Rent sysvar | | `InitializeAccount` | Requires Rent sysvar | | `InitializeMultisig` | Requires Rent sysvar | ### Recommended Instructions | Instruction | Benefit | | --------------------- | ------------------------------------------ | | `InitializeMint2` | Uses `Rent::get()` syscall | | `InitializeAccount2` | Uses `Rent::get()` syscall | | `InitializeAccount3` | Uses `Rent::get()` syscall, most efficient | | `InitializeMultisig2` | Uses `Rent::get()` syscall | **Important for Token 2022:** Account sizes vary based on enabled extensions. Always calculate sizes dynamically rather than hardcoding values. ## Code Examples ### Creating a Mint with InitializeMint2 (TypeScript) ```typescript theme={null} import { Connection, Keypair, SystemProgram, Transaction, } from "@solana/web3.js"; import { TOKEN_PROGRAM_ID, MINT_SIZE, createInitializeMint2Instruction, } from "@solana/spl-token"; async function createMint( connection: Connection, payer: Keypair, mintAuthority: PublicKey, decimals: number ): Promise { const mint = Keypair.generate(); // Query rent from the chain - gets Solayer Chain's correct rent const lamports = await connection.getMinimumBalanceForRentExemption(MINT_SIZE); const transaction = new Transaction().add( SystemProgram.createAccount({ fromPubkey: payer.publicKey, newAccountPubkey: mint.publicKey, space: MINT_SIZE, lamports, // Correct rent from chain programId: TOKEN_PROGRAM_ID, }), // Use InitializeMint2, NOT InitializeMint createInitializeMint2Instruction( mint.publicKey, decimals, mintAuthority, null, // freeze authority TOKEN_PROGRAM_ID ) ); await sendAndConfirmTransaction(connection, transaction, [payer, mint]); return mint.publicKey; } ``` ### Creating a Token Account with InitializeAccount3 (TypeScript) ```typescript theme={null} import { Connection, Keypair, PublicKey, SystemProgram, Transaction, } from "@solana/web3.js"; import { TOKEN_PROGRAM_ID, ACCOUNT_SIZE, createInitializeAccount3Instruction, } from "@solana/spl-token"; async function createTokenAccount( connection: Connection, payer: Keypair, mint: PublicKey, owner: PublicKey ): Promise { const account = Keypair.generate(); // Query rent from the chain const lamports = await connection.getMinimumBalanceForRentExemption(ACCOUNT_SIZE); const transaction = new Transaction().add( SystemProgram.createAccount({ fromPubkey: payer.publicKey, newAccountPubkey: account.publicKey, space: ACCOUNT_SIZE, lamports, programId: TOKEN_PROGRAM_ID, }), // Use InitializeAccount3 for best efficiency createInitializeAccount3Instruction( account.publicKey, mint, owner, TOKEN_PROGRAM_ID ) ); await sendAndConfirmTransaction(connection, transaction, [payer, account]); return account.publicKey; } ``` ### Token 2022 with Extensions (TypeScript) ```typescript theme={null} import { Connection, Keypair, SystemProgram, Transaction, } from "@solana/web3.js"; import { TOKEN_2022_PROGRAM_ID, ExtensionType, getMintLen, createInitializeMint2Instruction, createInitializeTransferFeeConfigInstruction, } from "@solana/spl-token"; async function createMintWithTransferFee( connection: Connection, payer: Keypair, mintAuthority: PublicKey, decimals: number, feeBasisPoints: number, maxFee: bigint ): Promise { const mint = Keypair.generate(); // Calculate size dynamically based on extensions const extensions = [ExtensionType.TransferFeeConfig]; const mintLen = getMintLen(extensions); // Query rent for the dynamic size const lamports = await connection.getMinimumBalanceForRentExemption(mintLen); const transaction = new Transaction().add( SystemProgram.createAccount({ fromPubkey: payer.publicKey, newAccountPubkey: mint.publicKey, space: mintLen, // Dynamic size lamports, // Correct rent from chain programId: TOKEN_2022_PROGRAM_ID, }), // Initialize extension BEFORE mint createInitializeTransferFeeConfigInstruction( mint.publicKey, mintAuthority, mintAuthority, feeBasisPoints, maxFee, TOKEN_2022_PROGRAM_ID ), // Use InitializeMint2 createInitializeMint2Instruction( mint.publicKey, decimals, mintAuthority, null, TOKEN_2022_PROGRAM_ID ) ); await sendAndConfirmTransaction(connection, transaction, [payer, mint]); return mint.publicKey; } ``` ### Rust: Correct vs Incorrect Rent Usage When writing custom Solana programs, always use `Rent::get()` instead of `Rent::default()`. ```rust theme={null} use solana_program::rent::Rent; use solana_program::sysvar::Sysvar; // CORRECT: Uses syscall to fetch rent from runtime fn get_rent_correct() -> Result { Rent::get() } // INCORRECT: Returns hardcoded Solana rent values fn get_rent_wrong() -> Rent { Rent::default() // DO NOT USE - ignores Solayer Chain's rent } ``` ## Best Practices Summary 1. **Always query rent from the chain** ```typescript theme={null} const lamports = await connection.getMinimumBalanceForRentExemption(size); ``` 2. **Use "V2" or "V3" instruction variants** - They use the `Rent::get()` syscall internally 3. **Calculate account sizes dynamically for Token 2022** - Use `getMintLen()` and `getAccountLen()` with your extensions 4. **In Rust programs, use `Rent::get()`** - Never use `Rent::default()` which returns hardcoded values ## Quick Reference ### Safe Instructions (use `Rent::get()` syscall) * `InitializeMint2` * `InitializeAccount2` * `InitializeAccount3` * `InitializeMultisig2` ### Instructions to Avoid (use Rent sysvar) * `InitializeMint` * `InitializeAccount` * `InitializeMultisig` By following these guidelines, your applications will correctly use Solayer Chain's 99% cheaper rent and avoid overpaying for account creation. # Supported Wallets Source: https://docs.solayer.org/documentation/introduction/supported-wallets Wallets compatible with Solayer Chain Solayer Chain currently has native integration support for **WalletConnect (Reown)** and **Nightly**. *** ## WalletConnect (Reown SDK) WalletConnect lets you accept top Solana wallets such as Solflare, Phantom, Backpack, Jupiter, Ledger and many more ([see the full list here](https://explorer.walletconnect.com/?type=wallet\&chains=solana%3A4sGjMW1scdkeTD4KoVHUkJ3i4RLRo7pJXupAqhd1s7j)). Via their Reown SDK, you can also access building tools beyond wallet connections; including authentication, payment solutions and multichain tools. **Supported frameworks:** React, Next.js, Vue, JavaScript, React Native ### Quick Setup 1. Get a Project ID from [Reown Dashboard](https://dashboard.reown.com) 2. Install the SDK for your framework 3. Configure with Solana network settings Framework-specific setup guides for Reown SDK with Solana Lower-level Solana adapter for Wallet Adapter library users If you're new to the Wallet Adapter library, Reown recommends using the **Reown SDK** directly for a simpler multichain setup. *** ## Nightly Wallet [Nightly](https://nightly.app) is a non-custodial wallet with native Solana and SVM support, compatible with Solayer Chain. ### Detection Nightly follows the [Wallet Standard](https://github.com/wallet-standard/wallet-standard), making it detectable via `@wallet-standard/core`. ```bash theme={null} npm install @wallet-standard/core # or yarn add @wallet-standard/core ``` ```javascript theme={null} import { getWallets } from '@wallet-standard/core' import { isWalletAdapterCompatibleStandardWallet } from '@solana/wallet-adapter-base' const { get } = getWallets() const allWallets = get() // Filter for Solana-compatible wallets (includes Nightly) const solanaWallets = allWallets.filter(isWalletAdapterCompatibleStandardWallet) ``` You can also access Nightly directly via `window.nightly.solana`. Full guide for detecting and integrating Nightly Wallet on Solana # Proof of Authority & Stake Source: https://docs.solayer.org/documentation/introduction/system-architecture/consensus-scaling Traditional rollup-based designs rely on **commodity validators** to verify transactions, but **high-throughput verification (1Gb/s) exceeds the capabilities of most nodes**. Posting such data on Layer 1 (L1) is **bandwidth-intensive and costly**. **Solayer Chain** addresses these challenges with a **Proof-of-Authority-and-Stake (PoAS)** model that combines **sequencer-led verification, distributed proof generation, and fallback security on Solana**. ## PoA\&S Consensus Model Solayer Chain introduces a **sequencer-driven model** where transactions are **batched into shreds**, each containing: * **Slot number & transaction vector** * **Version metadata for accessed accounts** * **Linkage hashes for state continuity** Only a **minimal (Effect Hash, Shred Hash) pair** is posted on **Solana**, ensuring **data availability** while avoiding **L1 congestion**. PoAS ## Transaction Verification & Voting Mechanism Upon receiving a **shred**, a **prover** follows a **two-step validation process**: 1. **State Reconstruction & Effect Hash Verification** * The prover checks **account versions**. * If missing state, the prover **requests shreds** from the sequencer. * The prover **re-executes transactions** to derive an **effect hash**. * If the computed hash **matches the shred's embedded effect hash**, the prover **votes for acceptance**. 2. **Majority Vote Finalization** * A **51% vote** is required to mark a **shred as finalized**. * If all previous shreds are **finalized**, the sequencer **assembles proof** for the block. ## Handling Malicious Sequencers & Fault Tolerance * **Malicious Proposer Detection** * Honest provers detect invalid transactions via **effect hash mismatches** and **vote against them**. * If the sequencer **repeatedly submits invalid shreds**, it is **marked as offline**. * Failover to a **backup sequencer** occurs via **PoA voting on Solana**. * **Censorship Resistance** * If the sequencer **ignores transactions**, users can **force inclusion** by submitting transactions **directly to Solana**. ## Efficient Prover Selection & Incentives To prevent **hardware-intensive requirements** for provers: * The sequencer uses a **round-robin method** to select **2/3 of online provers**. * **Subdivided verification tasks** allow provers to distribute workload across **multiple nodes**. * **Elastic cloud scaling** allows provers to handle surges in verification demand. Prover **reward structure**: * Earn **fees from processed shreds** and **inflationary \$LAYER rewards**. * **Malicious or inactive provers face slashing**: * **1st violation**: Loss of epoch fees. * **2nd violation**: **1%** slash on staked tokens. * **Subsequent violations**: **5%** stake slash per offense. The **PoAS model** in **Solayer Chain** achieves: * **Scalable, high-throughput consensus** without **overloading L1**. * **Efficient, decentralized validation** via **sequencer-led voting**. * **Fallback security** via Solana when the sequencer is offline or malicious. By **optimizing prover participation**, **reducing L1 bandwidth costs**, and **ensuring censorship resistance**, **Solayer Chain** scales consensus while maintaining **decentralization and integrity**. # Multi-Executor Architecture Source: https://docs.solayer.org/documentation/introduction/system-architecture/multi-executor The **Solayer Chain** transaction processing pipeline adopts a **microservices architecture**, decoupling **signature verification, deduplication, scheduling, banking, and storage** into independent services. This design enables **dynamic scaling, speculative execution, and reduced processing overhead**, ensuring **high throughput and consistency**. ## Decoupling Transaction Processing with Microservices Unlike traditional **monolithic blockchain architectures**, Solayer Chain decomposes key stages into **independent microservices** running across an **elastic compute fabric**: 1. **Signature Verification & Deduplication** * Offloaded to **distributed microservices**, reducing bottlenecks at the execution layer. * **Parallelized verification** ensures **low-latency transaction ingestion**. 2. **Dynamic Resource Provisioning** * A **feedback-driven control plane** monitors transaction rates and **automatically scales processing capacity**. * Enables **adaptive load balancing** based on network congestion and transaction spikes. 3. **Speculative Execution & Simulation** * Transactions **pre-execute against the latest committed state**, reducing contention in the banking stage. * **Non-conflicting transactions** execute in parallel, bypassing unnecessary dependencies. ## Speculative Execution & Conflict Resolution A key insight in **Solayer Chain** is that **most transactions do not require full re-execution** if they do not introduce **read-write conflicts**. 1. **Pre-Execution & Snapshotting** * Transactions are **speculatively executed**, capturing **intermediate execution snapshots** at **account access boundaries**. * **Only 2% of transactions** require full re-execution, as most do not conflict. 2. **Read-Only Transactions at the Edge** * Transactions performing **only read operations** are **validated and finalized at the edge**, bypassing the **central banking stage**. 3. **Handling Hot Accounts with Predictive Modeling** * Accounts with **high access frequency** use a **Winter-Holt Double Exponential Smoothing (DESP) model** for **predictive execution**. * **Pre-executed transactions account for all possible future values** of hot accounts, reducing conflicts. 4. **Rapid Conflict Resolution** * For remaining conflicts, execution state is reconstructed **from the nearest valid snapshot**, eliminating **full re-execution overhead**. ## Impact on Performance & Scalability This pipeline improves scalability and efficiency: * **Lower computational overhead** by shifting execution bottlenecks **away from centralized banking**. * **Higher transaction throughput** through **parallel speculative execution** and **adaptive scaling**. * **Reduced latency** for **read-only transactions**, finalized at the network edge. By decoupling execution into microservices, using speculative pre-execution, and resolving conflicts from snapshots, Solayer Chain processes transactions with high throughput and minimal contention. # RDMA & InfiniBand Source: https://docs.solayer.org/documentation/introduction/system-architecture/rdma-infiniband **Remote Direct Memory Access (RDMA)** is a high-performance networking technology that enables **zero-copy data transfers** directly between application memory spaces across networked systems. By **bypassing the operating system (OS) networking stack**, RDMA eliminates **CPU overhead and context switches**, significantly reducing latency and improving throughput. ## RDMA Architecture & Mechanism RDMA operates through **specialized network interface cards (RNICs)** that handle transport protocol processing and **direct memory operations in hardware**. Key features include: * **Zero-Copy Data Transfers**: Applications can read/write remote memory **without CPU intervention**. * **Bypassing Kernel Overhead**: Eliminates traditional network stack processing, reducing **latency to sub-microsecond levels**. * **Explicit Memory Registration**: Memory regions must be **registered with the RNIC**, which maintains **virtual-to-physical address translation** for secure access. RDMA supports **two transport modes**: * **Reliable Connected (RC)**: Guarantees **in-order, reliable delivery** for critical workloads. * **Unreliable Datagram (UD)**: Optimized for **low-latency applications** where minor packet loss is acceptable. RNICs ## InfiniBand: High-Performance RDMA Networking **InfiniBand** is a widely adopted **RDMA-based networking architecture** designed for **high-performance computing (HPC)** and **data-intensive applications**. It provides: * **Ultra-Low Latency**: Achieves **as low as 600 nanoseconds** end-to-end. * **High Bandwidth**: Supports data rates from **10 Gb/s (SDR) to 100 Gb/s per port** over copper or optical fiber. * **Host Channel Adapters (HCAs)**: Offload **protocol processing and memory translation** to hardware, reducing CPU load. RDMA & InfiniBand ## RDMA & InfiniBand in Modern Computing These technologies are critical for: * **Distributed Machine Learning**: Efficient communication for **large-scale AI training workloads**. * **HPC & Scientific Computing**: Accelerated **data sharing across compute clusters**. * **Cloud Data Centers**: Optimized **storage access (NVMe-over-Fabrics)** and **disaggregated computing**. With hardware acceleration and direct memory access, RDMA and InfiniBand deliver high-speed, low-latency networking suited for distributed blockchain workloads. # Software-Defined Networking (SDN) Source: https://docs.solayer.org/documentation/introduction/system-architecture/software-defined-network Software-Defined Networking (SDN) **decouples the control plane from the data plane**, enabling **centralized network control** through **software-based controllers**. This separation allows for **dynamic programmability**, **automated network policies**, and **greater flexibility** in managing network traffic. ## SDN Architecture Modern SDN follows a **three-tier model**: **Data Plane (Forwarding Plane)** * Consists of **programmable forwarding elements** (e.g., switches, routers) that process packets based on **match-action rules**. * Implements a **pipeline architecture**, allowing **efficient packet processing at line rate**. **Control Plane** * Manages network policies and computes paths dynamically. * Uses **distributed consensus protocols** to maintain **network state consistency** across multiple controllers. **Management Plane** * Provides **high-level orchestration**, **network automation**, and **northbound APIs** for applications. * Abstracts network complexity, simplifying policy deployment. SDN ## Programmable Forwarding Plane Traditional **fixed-function networking** has evolved into **fully programmable packet processing pipelines** using languages like **P4**. This enables: * **Custom protocol implementation** tailored to specific use cases. * **Complex packet transformations** directly within the forwarding plane. * **Multi-stage match-action processing**, allowing **load balancing, traffic engineering, and network virtualization**. Each **pipeline stage** can modify packet headers, apply policy logic, and maintain local state, ensuring **high-performance, adaptive networking**. ## SDN Controllers & APIs SDN controllers provide **centralized control** while maintaining **distributed consistency**. Key components include: * **Northbound APIs**: Expose network abstractions for orchestration and applications. * **Southbound APIs**: Interface with forwarding devices using **OpenFlow, P4Runtime, and gNMI**. By separating **network intelligence from hardware**, SDN enables **faster innovation, scalable deployments, and real-time network optimizations**. SDN makes networking programmable and scalable. Its ability to dynamically adapt traffic flows while maintaining line-rate performance makes it well-suited for high-throughput blockchain infrastructure. # Solana & SVM Source: https://docs.solayer.org/documentation/introduction/system-architecture/solana-svm This document provides a **technical overview** of **Solana**'s architecture and its **Solana Virtual Machine (SVM)**. It is intended as background material for understanding how high-performance, parallelized blockchain systems use **hardware-optimized execution** and **low-latency networking**. ## Solana Solana introduces a novel blockchain architecture that **fundamentally departs** from traditional consensus mechanisms by combining **Proof of History (PoH)** with an **optimistic concurrency model**. These innovations enable **high-throughput, low-latency transaction processing** at a scale beyond most blockchain platforms. ### Proof of History (PoH) * PoH functions as a **verifiable cryptographic clock**, allowing validators to agree on transaction order **without constant coordination**. * Instead of relying solely on timestamps, each validator generates a sequential, tamper-proof hash chain that encodes time between events. * This pre-ordered execution model **reduces synchronization overhead**, allowing for aggressive parallelism in transaction processing. ### Proof of Stake (PoS) Consensus * Solana employs a **delegated Proof of Stake (dPoS) model**, where validators stake SOL tokens to secure the network. * Slashing conditions discourage malicious or inactive validators, enhancing network resilience. ### Turbine: High-Speed Block Propagation * Solana partitions blocks into **shreds** (small data packets) and distributes them using a multicast-inspired relay. * This **bandwidth-efficient mechanism** reduces latency across validators, enabling **rapid finality**. ### Sealevel: Parallel Execution Engine * Unlike most blockchain environments that enforce **sequential execution**, Sealevel enables **massively parallel transaction processing**. * Transactions **declare upfront** which accounts they read/write, allowing the runtime to construct a **dependency graph** that maximizes concurrency. By integrating these innovations, Solana operates as a **single global state machine** capable of processing **tens of thousands of transactions per second (TPS)** while maintaining **low fees and deterministic finality**. ## Solana Virtual Machine (SVM) The **Solana Virtual Machine (SVM)** is **fundamentally distinct** from traditional blockchain execution models, including the **Ethereum Virtual Machine (EVM)**. It is designed from the ground up to **maximize parallel execution**, minimize **state contention**, and enforce **strict serializability guarantees**. ### Shared-Nothing Concurrency Model * Transactions **explicitly declare** their read and write sets before execution. * The SVM builds a **dependency graph**, ensuring that non-overlapping transactions run **in parallel across CPU cores**. * Conflicting transactions are **automatically serialized**, preventing race conditions or double-spending. ### Pessimistic Concurrency Control * The SVM enforces **strict transaction isolation** by **pre-validating state access** before execution. * This contrasts with **EVM's optimistic concurrency model**, where transactions execute speculatively and **roll back if conflicts occur**. * By **avoiding rollbacks altogether**, SVM achieves higher throughput and **lower computational overhead**. ### Multi-Version Concurrency Control (MVCC) * Solana maintains **multiple state versions** in memory, allowing concurrent reads **without blocking writes**. * Write operations adhere to **PoH-dictated ordering**, ensuring **deterministic execution** across validators. ### eBPF Execution Model * Instead of relying on a domain-specific virtual machine like EVM, Solana uses **extended Berkeley Packet Filter (eBPF)** as its execution environment. * The **eBPF JIT compiler** enables **near-native execution speeds**, enhancing transaction performance. ### Account-Based Execution Model * SVM's **flexible account model** allows smart contracts to store arbitrary data. * By analyzing account access patterns, **Solana maximizes concurrency**, avoiding **global state bottlenecks**. These design principles allow **Solana's SVM** to **achieve scalability that traditional blockchain architectures struggle with**, making it an ideal platform for **DeFi, NFTs, gaming, and real-time financial applications**. ## The Case for Hardware Acceleration While Solana's **SVM and Sealevel execution model** have pushed blockchain performance to new limits, the next step in scalability involves **hardware acceleration**. ### Beyond Competing with Blockchains Solana is not merely **competing against other blockchains**—it is competing with **high-frequency trading (HFT) systems, real-time payments, and global financial infrastructure** that demand **ultra-low latency and sub-millisecond settlement**. ### The Need for Specialized Hardware To meet these demands, Solana must embrace **hardware-based optimizations**, including: * **FPGA/ASIC acceleration** for signature verification and consensus validation. * **High-performance networking** to further reduce validator communication latency. * **Zero-copy transaction handling** to minimize memory bottlenecks. ### Future Outlook As **blockchain technology converges with traditional finance**, the focus will shift toward: * **Sub-millisecond finality** * **Global-scale liquidity infrastructure** * **Hardware-optimized execution** By integrating **specialized hardware** with its **highly parallelized execution environment**, Solana is well-positioned to support **high-performance decentralized finance** and **Web3 infrastructure**. # Why Hardware Acceleration? Source: https://docs.solayer.org/documentation/introduction/why-hardware-acceleration ## The Limits of Software Scaling Blockchain scalability has evolved through **sharding, Layer 2 rollups, and parallel execution models**. While these innovations have improved performance, they also introduce **state fragmentation, liquidity inefficiencies, and increased complexity**. Software optimizations like transaction batching and concurrency improvements have reached their limits due to: * **State Fragmentation**: Rollups and sidechains create isolated liquidity pools, increasing transaction costs and reducing efficiency. * **Throughput Bottlenecks**: EVM's single-threaded execution and Solana's Sealevel parallelism face network bandwidth constraints. * **Latency & Cost**: Congestion leads to high fees and delays, even with rollup improvements like Proto-Danksharding. * **System Complexity**: New execution models (e.g., DAGs, Block-STM) improve efficiency but increase synchronization overhead. ## Why Hardware Scaling Is the Future To overcome these constraints, **hardware acceleration** provides a new approach, offloading key blockchain processes to **dedicated hardware accelerators**. * **Signature Verification**: FPGA-based signature verification (e.g., Firedancer) processes transactions at 100Gb/s. * **Parallel Processing**: FPGA clusters enable horizontal scaling, executing transactions across multiple machines. * **Low-Latency Storage**: NVMe-oF allows distributed state storage without compromising speed. * **Network Efficiency**: InfiniBand RDMA enables ultra-fast inter-node communication, supporting 1M+ TPS. ## Solayer Chain: Pushing Blockchain to the Hardware Limit Solayer Chain integrates **hardware acceleration, RDMA, and FPGA-based execution** to move past software-only constraints. By optimizing transaction processing, state storage, and consensus at the hardware level, Solayer achieves high scalability, low latency, and lower costs. Better blockchain performance requires both better software and better hardware. # Mainnet Alpha Node Source: https://docs.solayer.org/documentation/run-a-node/mainnet-alpha Run a Mainnet Alpha Node Works on Ubuntu 22.04, Ubuntu 24.04, and macOS. ## Run ScyllaDB #### Option 1: Bare metal installation (Recommended) [https://docs.scylladb.com/manual/stable/getting-started/install-scylla/](https://docs.scylladb.com/manual/stable/getting-started/install-scylla/) #### Option 2: Docker ```bash theme={null} docker run -d --name scylla -p 9042:9042 scylladb/scylla ``` ## Install Rust ```bash theme={null} curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh source ~/.cargo/env ``` ## Install relevant dependencies (Ubuntu) ```bash theme={null} sudo apt install -y clang build-essential libssl-dev protobuf-compiler pkg-config aria2 ``` ## Install relevant dependencies (macOS) ```bash theme={null} brew install clang protobuf pkg-config aria2 ``` ## Clone and build the Solayer RPC repository ```bash theme={null} git clone https://github.com/solayer-labs/solayer-rpc cd solayer-rpc cargo build --release --features mainnet ``` ## Initialize ScyllaDB tables ```bash theme={null} cqlsh -f cassandra_tables.sql ``` ## Run the Solayer RPC ```bash theme={null} ./target/release/rpc-v2 \ -s mainnet-seed-1.solayer.org \ --cassandra-hosts 127.0.0.1:9042 \ --wait-for-grpc-peer \ --wait-for-grpc-peer-timeout-secs 30 ``` `rpc-v2` now uses **registry-first gRPC bootstrap by default**: * It waits for a usable upstream gRPC peer discovered from the RPC registry. * With `-s mainnet-seed-1.solayer.org`, the default registry source is `http://mainnet-seed-1.solayer.org:6005`. * `--wait-for-grpc-peer-timeout-secs 0` means wait forever. * If timeout is greater than `0`, the node falls back to direct sequencer gRPC bootstrap after timeout. * To disable waiting and keep immediate sequencer bootstrap behavior, pass `--wait-for-grpc-peer false`. ## Verify the Solayer RPC is running ```bash theme={null} curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}' http://localhost:18899 ``` You should see the current slot number. ## Catching up with the network ```bash theme={null} solana catchup --our-localhost 18899 -u https://mainnet-alpha.solayer.org ``` # Architecture Source: https://docs.solayer.org/documentation/solayer-bridge/architecture/index sBridge Architecture Overview ## sBridge Architecture Overview The architecture includes three core layers: source chain (initiating chain), off-chain guardian network (validation layer), and destination chain (execution layer). A user initiates a bridge operation—either asset transfer or cross-chain execution—on chain1 by interacting with the Bridge Program, which generates a deterministic PDA as a cryptographic proof of intent. This transaction is indexed by multiple RPC providers and consumed by a decentralized guardian network. Architecture Each guardian independently fetches transactions from rpc, verifies them and signs a canonical hash (covering chain, sender, recipient, mint, amount, nonce, and source tx ID). Once the quorum threshold is reached, the leader guardian aggregates signatures and relays them to chain2. There, the Bridge Program uses Solana’s ed25519 precompile to verify the multi-sig, enforces replay protection via the bridge proof PDA, and then dispatches the token. For cross-chain call, leader guardian would simply decode and broadcast the transaction on chain2. ### Core Layers: * **On-chain Program Layer**: Handles transaction initiation, asset locking, and bridge proof (PDA) generation. * **Off-chain Guardian Network**: Decentralized validators independently verify transactions, aggregate signatures, and forward proofs. * **Destination Chain Execution**: Verifies proofs, executes transactions, and manages asset unlocking or minting. # Bridge SDK Source: https://docs.solayer.org/documentation/solayer-bridge/bridge-sdk TypeScript SDK for interacting with the Solayer Bridge Program The Bridge SDK provides a full TypeScript interface for interacting with the Solayer Bridge Program. It enables cross-chain asset transfers between Solana and Solayer networks with built-in security features and proof verification. ## Installation ```bash theme={null} npm install @solayer-labs/bridge-sdk ``` ### Bridge Flow Cross-chain transfers follow a secure five-step process: * **Source Chain**: User initiates bridge transaction on source chain (Solana/Solayer) * **Proof Generation**: Bridge proof is created with transaction details * **Guardian Verification**: Guardians verify and sign the bridge proof * **Target Chain**: Operator executes bridge on target chain using verified proof * **Asset Transfer**: Assets are transferred to recipient on target chain ### Key Components * **BridgeHandler**: Manages bridge state and configuration * **BridgeProof**: Contains bridge transaction details and verification data * **GuardianInfo**: Stores guardian public keys and threshold information * **TokenInfo**: Maps tokens between chains ### BridgeClient The main client class for bridge operations. ```typescript theme={null} import { BridgeClient, Chain } from "@solayer-labs/bridge-sdk"; import { Connection, PublicKey } from "@solana/web3.js"; const bridgeClient = new BridgeClient({ connection: new Connection("https://api.devnet.solana.com"), userPublicKey: new PublicKey("your_public_key_here"), chain: Chain.Solana, commitment: "confirmed", }); ``` **Important Note:** The BridgeClient class only provides transaction creation methods. You need to sign and send transactions yourself using `sendAndConfirmTransaction` or similar methods. ### Query Methods #### Bridge Handler Information ```typescript theme={null} const bridgeHandler = await bridgeClient.getBridgeHandler(Chain.Solana); ``` #### Bridge Proof Queries ```typescript theme={null} import * as anchor from "@coral-xyz/anchor"; import { getBridgeHandlerPDA } from "@solayer-labs/bridge-sdk"; // Get source chain bridge proof const [bridgeHandler] = getBridgeHandlerPDA(Chain.Solana); const bridgeProof = await bridgeClient.getSourceChainBridgeProof( bridgeHandler, userPublicKey, new anchor.BN(12345) ); // Get destination chain bridge proof const destProof = await bridgeClient.getDestinationChainBridgeProof( bridgeHandler, "source_transaction_signature" ); // Get bridge proof by account address const proofByAccount = await bridgeClient.getSourceChainBridgeProofByAccount( new PublicKey("bridge_proof_account_address") ); ``` #### Bridge Handler Vault PDA ```typescript theme={null} const [bridgeHandler] = getBridgeHandlerPDA(Chain.Solana); const vaultPDA = bridgeClient.getBridgeHandlerVaultPDA( bridgeHandler, new PublicKey("token_mint_address") ); ``` ### Transaction Builders #### createBridgeAssetSourceChainTransaction Creates bridge transaction without sending it. The method automatically determines the target chain mint address using the `get_target_mint` utility function. ```typescript theme={null} const tx = await bridgeClient.createBridgeAssetSourceChainTransaction( params, accounts ); // Customize transaction if needed const signature = await sendAndConfirmTransaction(connection, tx, [ userKeypair, ]); ``` #### createBridgeAssetSourceChainSolTransaction Creates SOL bridge transaction without sending it. ```typescript theme={null} const tx = await bridgeClient.createBridgeAssetSourceChainSolTransaction( params ); // Customize transaction if needed const signature = await sendAndConfirmTransaction(connection, tx, [ userKeypair, ]); ``` ### Utility Functions #### PDA Helpers ```typescript theme={null} import * as anchor from "@coral-xyz/anchor"; import { getBridgeHandlerPDA, getSourceChainBridgeProofPDA, getDestinationChainBridgeProofPDA, } from "@solayer-labs/bridge-sdk"; // Get bridge handler PDA const [bridgeHandler, bump] = getBridgeHandlerPDA(Chain.Solana); // Get source chain bridge proof PDA const [bridgeProof, bump] = getSourceChainBridgeProofPDA( bridgeHandler, userKeypair.publicKey, new anchor.BN(12345) ); // Get destination chain bridge proof PDA const [destProof, bump] = getDestinationChainBridgeProofPDA( bridgeHandler, "source_transaction_signature" ); ``` #### Token Utilities ```typescript theme={null} import { calculateTargetChainBridgedMintAddress, calculateTokenInfoAddress, is_mint_bridged_token, get_target_mint, Chain, } from "@solayer-labs/bridge-sdk"; import { PublicKey } from "@solana/web3.js"; // Calculate target chain bridged mint address const targetMint = calculateTargetChainBridgedMintAddress( new PublicKey("source_mint_address"), bridgeHandler ); // Calculate token info PDA address const tokenInfoAddress = calculateTokenInfoAddress( new PublicKey("token_mint_address"), bridgeHandler ); // Check if mint is a bridged token const isBridged = await is_mint_bridged_token( connection, bridgeHandler, new PublicKey("token_mint_address") ); // Get target chain mint address const targetMint = await get_target_mint( Chain.Solana, connection, bridgeHandler, new PublicKey("source_mint_address") ); ``` #### Bridge Status Tracking ```typescript theme={null} import { getTargetChainBridgeTxIdFromSourceTxId, getSourceChainBridgeTxIdFromTargetChainBridgeProof, getUserBridgeTx, Chain, } from "@solayer-labs/bridge-sdk"; import { PublicKey } from "@solana/web3.js"; // Check if bridge is completed on target chain const targetTxId = await getTargetChainBridgeTxIdFromSourceTxId( "source_tx_signature", Chain.Solana, solayerConnection ); // Get source transaction from target chain bridge proof const sourceTxId = await getSourceChainBridgeTxIdFromTargetChainBridgeProof( new PublicKey("bridge_proof_key"), solayerConnection ); // Get user's bridge transaction history const userTxs = await getUserBridgeTx( connection, user.publicKey, bridgeHandler ); ``` ### Types and Interfaces #### Core Configuration Types ```typescript theme={null} interface BridgeClientConfig { connection: Connection; userPublicKey: PublicKey; chain: Chain; programId?: PublicKey; commitment?: anchor.web3.Commitment; } enum Chain { Solana = 1, Solayer = 2, } ``` #### Bridge Parameter Types ```typescript theme={null} interface BridgeAssetSourceChainParams { bridgeProofNonce: anchor.BN; amount: anchor.BN; recipient: PublicKey; additionalSolGas: anchor.BN; } interface BridgeAssetSourceChainSolParams { bridgeProofNonce: anchor.BN; amount: anchor.BN; recipient: PublicKey; } interface UserBridgeTx { sourceChainBridgeTx: string[]; targetChainBridgeTx: string[]; } ``` #### Program Account Types ```typescript theme={null} export type BridgeHandler = BridgeProgram["accounts"][0]; export type BridgeProof = BridgeProgram["accounts"][1]; export type BridgeProofSourceChain = BridgeProgram["accounts"][2]; export type TokenInfo = BridgeProgram["types"][0]; ``` ### Usage Examples #### Complete Bridge Workflow ```typescript theme={null} import { BridgeClient, Chain, getBridgeHandlerPDA, getTargetChainBridgeTxIdFromSourceTxId, } from "@solayer-labs/bridge-sdk"; import { Connection, Keypair, PublicKey, sendAndConfirmTransaction, } from "@solana/web3.js"; import * as anchor from "@coral-xyz/anchor"; async function completeBridgeWorkflow() { const connection = new Connection("https://api.devnet.solana.com"); const userKeypair = Keypair.generate(); const bridgeClient = new BridgeClient({ connection, userPublicKey: userKeypair.publicKey, chain: Chain.Solana, commitment: "confirmed", }); // Bridge parameters const params = { bridgeProofNonce: new anchor.BN(Date.now()), amount: new anchor.BN(1000000000), // 1 token recipient: new PublicKey("recipient_address"), additionalSolGas: new anchor.BN(0), }; const accounts = { mint: new PublicKey("token_mint"), signerVault: new PublicKey("your_token_account"), }; try { // Create bridge transaction const transaction = await bridgeClient.createBridgeAssetSourceChainTransaction( params, accounts ); // Sign and send transaction const signature = await sendAndConfirmTransaction(connection, transaction, [ userKeypair, ]); console.log("Bridge initiated:", signature); // Track bridge completion const targetTxId = await getTargetChainBridgeTxIdFromSourceTxId( signature, Chain.Solana, new Connection("https://rpc.devnet.solayer.com") ); if (targetTxId) { console.log("Bridge completed on target chain:", targetTxId); } } catch (error) { console.error("Bridge failed:", error); } } ``` #### SOL Bridge Workflow ```typescript theme={null} async function bridgeSOL() { const userKeypair = Keypair.generate(); const bridgeClient = new BridgeClient({ connection: new Connection("https://api.devnet.solana.com"), userPublicKey: userKeypair.publicKey, chain: Chain.Solana, }); const params = { bridgeProofNonce: new anchor.BN(Date.now()), amount: new anchor.BN(5000000), // 0.005 SOL recipient: new PublicKey("recipient_address"), }; try { const transaction = await bridgeClient.createBridgeAssetSourceChainSolTransaction(params); const signature = await sendAndConfirmTransaction(connection, transaction, [ userKeypair, ]); console.log("SOL bridge initiated:", signature); } catch (error) { console.error("SOL bridge failed:", error); } } ``` #### Working with Bridged Tokens ```typescript theme={null} import { getBridgeHandlerPDA, is_mint_bridged_token, get_target_mint, calculateTokenInfoAddress, Chain, } from "@solayer-labs/bridge-sdk"; import { Connection, PublicKey } from "@solana/web3.js"; async function workWithBridgedTokens() { const connection = new Connection("https://api.devnet.solana.com"); const [bridgeHandler] = getBridgeHandlerPDA(Chain.Solana); const sourceMint = new PublicKey("token_mint_address"); // Check if a mint is a bridged token const isBridged = await is_mint_bridged_token( connection, bridgeHandler, sourceMint ); console.log("Is bridged token:", isBridged); // Get the target chain mint address const targetMint = await get_target_mint( Chain.Solana, connection, bridgeHandler, sourceMint ); console.log("Target mint:", targetMint.toString()); // Get token info PDA address const tokenInfoAddress = calculateTokenInfoAddress(sourceMint, bridgeHandler); console.log("Token info PDA:", tokenInfoAddress.toString()); } ``` ### Error Handling Common bridge errors and their meanings: * **InsufficientAmount**: User doesn't have enough tokens * **BridgePaused**: Bridge is currently paused by admin * **TokenPaused**: Specific token is paused for bridging * **TooMuchAdditionalSolGas**: Additional SOL gas exceeds limit * **TooLittleAdditionalSolGas**: Additional SOL gas below minimum * **InvalidChain**: Invalid chain specified * **InvalidOperator**: Invalid operator for the operation ```typescript theme={null} try { const tx = await bridgeClient.createBridgeAssetSourceChainTransaction( params, accounts ); const signature = await sendAndConfirmTransaction(connection, tx, [ userKeypair, ]); } catch (error) { if (error.message.includes("BridgePaused")) { console.error("Bridge is currently paused"); } else if (error.message.includes("InsufficientAmount")) { console.error("Insufficient token balance"); } else if (error.message.includes("TokenPaused")) { console.error("This token is paused for bridging"); } } ``` ### Best Practices #### Pre-flight Checks ```typescript theme={null} // Check bridge status before initiating const bridgeHandler = await bridgeClient.getBridgeHandler(Chain.Solana); if (bridgeHandler.pause) { throw new Error("Bridge is currently paused"); } ``` #### Transaction Management ```typescript theme={null} // Use unique nonces const bridgeProofNonce = new anchor.BN(Date.now() + Math.random()); // Create and confirm transactions const tx = await bridgeClient.createBridgeAssetSourceChainTransaction( params, accounts ); const signature = await sendAndConfirmTransaction(connection, tx, [ userKeypair, ]); ``` #### Progress Monitoring ```typescript theme={null} import { getTargetChainBridgeTxIdFromSourceTxId, Chain, } from "@solayer-labs/bridge-sdk"; // Poll for bridge completion with timeout async function waitForBridgeCompletion(sourceTxId: string, maxAttempts = 30) { for (let i = 0; i < maxAttempts; i++) { const targetTxId = await getTargetChainBridgeTxIdFromSourceTxId( sourceTxId, Chain.Solana, solayerConnection ); if (targetTxId) return targetTxId; await new Promise((resolve) => setTimeout(resolve, 2000)); } throw new Error("Bridge timeout"); } ``` #### Parameter Validation ```typescript theme={null} import { BridgeAssetSourceChainParams } from "@solayer-labs/bridge-sdk"; import * as anchor from "@coral-xyz/anchor"; // Validate bridge parameters function validateBridgeParams(params: BridgeAssetSourceChainParams) { if (params.amount.lte(new anchor.BN(0))) { throw new Error("Amount must be greater than 0"); } if (params.additionalSolGas.gt(new anchor.BN(10000000))) { // 0.01 SOL throw new Error("Additional SOL gas too high"); } } ``` # Solayer Bridge (sBridge) Source: https://docs.solayer.org/documentation/solayer-bridge/introduction Canonical Cross-Chain Bridge for Solana and Solayer **Solayer Bridge (sBridge)** is a canonical, SVM-native cross-chain bridge purpose-built to connect Solana and Solayer with high throughput, deterministic security, and composable execution. It offers an execution-native bridge architecture, replacing generalized, exploit-prone multichain bridges with a protocol aligned tightly to the Solana Virtual Machine (SVM). ## What is sBridge? sBridge is tailored specifically to SVM environments, differing significantly from generic multichain solutions such as Wormhole, LayerZero, and Hyperlane by offering tighter semantic integration, higher capital efficiency, and protocol-level control. ## Overview sBridge enables: * **Asset transfer and wrapped token minting** between Solana and Solayer * **Cross-chain call execution**, such as swapping on Solayer and depositing LP on Solana in a single transaction * **Sub-3s optimistic finality for low-value txs**, and deterministic finality for high-value txs * **Hardware-backed ED25519 multi-signatures** using guardian quorum * **Double-handling prevention** using Program Derived Addresses (PDAs) * **Permissionless token bridging** - Bridge ANY token without whitelisting * **Bidirectional bridge** between Solayer and Solana with secure and preauthorized cross-chain communication Unlike other bridges, sBridge is designed from the ground up to support **SVM-to-SVM communication**. It embraces SVM-specific architecture such as return-data handling, PDA proofs, and polling-based transaction indexing for reliability and performance. ## Why We Built sBridge We chose to develop sBridge in-house because existing bridging solutions lacked critical features needed for our specific domain, such as enhanced flexibility, strict latency guarantees, and deeper protocol-level control. By integrating on-chain duplicate prevention, poll-based transaction subscription, guardian auto-failover mechanism, and a dynamic-finality model (fast optimistic + slow finalized), we ensure low-latency and highly available bridging without compromising security. Unlike other bridges, we also have a fully database-less implementation for sBridge. By maximizing the PDA of SVM, we manage to not store anything locally, even for indexing bridge transactions purpose. This helps reduce security back possibilities and opens for more development opportunities on top of it. The unique cross-chain call functionality also enables new capabilities in interchain operability, allowing atomic transactions across multiple chains in a single bundled operation. The architecture is also designed with future extensibility in mind, supporting dynamic validator sets, additional message types, and programmable token minting. ## Key Features * **Secure Asset Transfers:** Ensure asset safety across different SVM chains * **Cross-chain Execution:** Support for atomic transactions and multi-chain interactions * **Guardian Network:** Decentralized validation through threshold signature aggregation * **No-database Design:** By maximizing SVM PDA, the system does not have any centralized database involved at any point ## Architecture: 3-Layer Bridge sBridge consists of three layers: 1. **Origin Chain** – User invokes `bridgeAsset` or `crossChainCall`, creating a unique PDA as a proof-of-intent. 2. **Guardian Network (Off-Chain)** – Guardians poll transactions via RPC, validate signatures, and submit a threshold-signed proof. 3. **Destination Chain** – Bridge program verifies multi-sig via Solana's precompile and executes the asset transfer or cross-chain instruction. ```plaintext theme={null} User → [Origin Chain (PDA + Bridge Program)] → [Guardian Network] → [Destination Chain (PDA Check + Execution)] ``` ## On-chain Program ### Asset Bridge * **`bridgeAssetSourceChain`**: Initiated on Solana (or origin chain). Tokens are deducted, a fee is extracted, and a bridge vault locks the asset. A PDA is generated based on `(sender, recipient, mint, amount, nonce, txId)`. * **`bridgeAssetTargetChain`**: Invoked on Solayer (or destination chain). After guardian multi-sig is verified, tokens are released or wrapped tokens minted. ### Cross-Chain Call Users can sign serialized transactions (e.g., Solana LP deposit) on Solayer and dispatch it cross-chain. The leader guardian decodes and simulates the payload, then executes it directly. ```ts theme={null} await bridgeClient.crossChainCall({ serializedTx: serializedCrossChainTransaction, }); ``` This enables **multi-leg transactions** like: * Solayer swap → Solana LP deposit → All in one signed tx ## Off-chain Guardian Network * **Leader–Follower Model**: Guardians gossip signed payloads. A rotating leader aggregates multi-sigs and submits to destination chain. * **Poll-based indexing**: No reliance on fragile WebSocket subscriptions. Guardians poll RPC endpoints for new bridge transactions. * **ED25519 multi-sig**: All signatures are generated using hardware-backed HSMs and verified via Solana's precompile. ## Reliability & Failure Recovery * **Replay protection**: All bridge actions generate unique PDAs. Existing PDAs are checked before any execution. * **Exactly-once semantics**: Guardians track high-water marks and nonces to prevent duplicate processing. * **Leader failover**: If a leader becomes unresponsive, a new one is elected via round-robin. ## Dynamic Finality Model * **Fast-path finality**: \< \$1K txs execute after "confirmed" block state, finalizing in \~3s * **Slow-path finality**: High-value txs wait for irreversible finality on source chain * Misbehavior by guardians (e.g., signing before safe finality) can result in slashing or removal ## Performance (Devnet Metrics) | Metric | sBridge | Avg. Multichain Bridge | | ---------------------------- | ----------- | ---------------------- | | Median Finality (\< \$1K tx) | \~3 sec | \~8 sec | | Avg. Fee | 0.0006 SOL | 0.0014 SOL | | Throughput | \~1000 tx/s | \~400 tx/s | *** This documentation provides a full guide to understanding and implementing the Solayer Bridge effectively. # sBridge Off-chain Guardian Source: https://docs.solayer.org/documentation/solayer-bridge/offchain-guardian/index Off-chain guardian network for cross-chain bridge verification The sBridge off-chain guardian network functions as the verification layer for all cross-chain bridge activities. Guardians independently fetch source chain transactions from different sources, validate and produce cryptographic attestations, and coordinate to reach a threshold multi-sigature that authorizes execution on the destination chain. This layer is designed for decentralization, fault tolerance, and deterministic correctness, ensuring trust-minimized interoperability. ### Leader and Follower Network Model The sBridge guardian network adopts a **Leader–Follower network model** to efficiently coordinate signature aggregation and relaying under partial synchrony. Guardian Network All guardians gossip with each other through a private channel, configured through internal DERP (Designated Encrypted Relay for Packets) server. Each guardian operates independently to fetch, validate, and attest transactions from the source chain. Upon successful validation, guardians generate and locally sign a canonical hash of the transaction payload. This cryptographic attestation represents the guardian's commitment to the transaction's correctness. To simplify multi-signature coordination, a single leader guardian is deterministically selected at the beginning and rotates after processing **N** transactions, based on a round-robin rotation. The leader is responsible for collecting individual guardian signatures until a pre-configured threshold (e.g., t of n) is met. If the leader waits for follower signatures over a certain time threshold, it would reach out to the followers and ask for signatures. Once quorum is reached, the leader constructs the aggregated multi-signature payload and submit to the destination chain. Follower Guardians do not coordinate directly with each other but continuously gossip their signed attestations to the leader and optional fallback peers. This gossip model enables redundancy in the face of leader failure and supports rapid recovery. After successfully aggregating and relaying a batch of transactions, the leader guardian broadcasts a commit acknowledgment to all guardians, instructing them to persist the latest processed transaction signature as their local high-water mark. This ensures consistent fault recovery checkpoints across the network and enables seamless leader rotation, allowing any follower to deterministically resume leadership without reprocessing already-committed transactions. ### Transaction Subscription Each guardian operates against a dedicated RPC endpoint and is responsible for continuously polling new transactions of the bridge program on the source chain. For both Solana and Solayer chain, each guardian periodically invokes the **getSignaturesForAddress** RPC method on the bridge program ID, starting from the most recently processed transaction signature. This position is stored locally in a durable file. Upon retrieval, signatures are fetched in reverse chronological order and then resolved to full transactions using **getTransaction**. This polling mechanism also works well during guardian crash or new guardian catch up cases as long as the local file is stored properly. To ensure exactly-once semantics, guardians maintain a local de-duplication set in memory and persistently store the highest processed transaction signature. This eliminates reprocessing due to retries, even in cases of partial crashes or concurrent recovery. ### Multi-Sig Aggregation After validating a transaction, each guardian generates a deterministic hash over the bridge payload: **BridgeAsset:** H = hash(sender, recipient, mint, amount, nonce, sourceTxId) **CrossChainCall:** H = hash(sender, calldata, nonce, sourceTxId) Each guardian signs this hash using a Hardware Security Module (HSM), which ensures the private key never enters system memory. The designated leader guardian is responsible for collecting signatures until the threshold ( t ) out of ( n ) is reached (e.g., t = 5, n = 7). Once quorum is reached, the leader packages the multi-signature data into a canonical payload and submits it to the destination chain. The multi-signature scheme supports both static validator sets and dynamic reconfiguration, with guardian public keys stored on-chain and verified using Solana’s `ed25519_program`. ### Failure Recovery * **Failure Retry**: Bridge execution failures (e.g., transient networking failures) are handled via a fault-tolerant redrive mechanism. Lead guardian continuously scans the cached transaction sessions and process each session based on it's current status. Each retry operation verifies that the transaction has not already been executed on-chain by checking the existence of its PDA proof. This ensures at-least-once delivery semantics without compromising determinism or duplicity protection from the off-chain module perspective. * **Guardian Leader Failover**: Leader failure (e.g., network partition, crash) is mitigated through a rotating leader election strategy. Guardians periodically exchange heartbeats, and if the current leader becomes unresponsive beyond a timeout window, a new leader is elected deterministically (e.g., round-robin by guardian ID). Any follower should be able to quickly rotate as the new leader as they should have up-to-date fault recovery checkpoint locally stored. During transaction processing, leader leader would broadcast highest processed transaction signature to followers after finishing a batch. Even if the checkpoint transaction is slightly delayed from the actual one, the new leader can still quickly catch up as it would check bridge proof PDA on destination chain for each transaction and quickly identifies already committed ones. # sBridge On-chain Program Source: https://docs.solayer.org/documentation/solayer-bridge/onchain-programs Solayer Bridge on-chain program for asset bridging and cross-chain calls The sBridge on-chain program is deployed on both chains and is responsible for securely executing asset bridging and arbitrary cross-chain call based on validated multi-sig proofs produced by a decentralized guardian quorum. Through bridge proof PDA, the program ensures double-handling prevention, replay protection, and verifiability on-chain. The program also implements an auto-incremental nonce mechanism to increase uniqueness for each user transaction. The nonce can also be used as a bridge handling cutoff point, for example, a bridge transaction with a nonce lower than N could be safely and permanently discarded by the system when the last processed transaction is over 5N, such that the rent paid to related on-chain PDAs could be recycled. ### Asset Bridge The asset bridge module is responsible for handling canonical and wrapped token transfers between Solana and Solayer. It exposes two core entry points: * **bridgeAssetSourceChain:** This instruction is invoked on the origin chain (e.g., Solana). It deducts the bridged token amount from the user, splitting it into a fee (transferred to the handler fee vault) and a locked portion (stored in the bridge vault). A nonce is auto-incremented and a PDA is derived from the tuple **(sender, recipient, mint, amount, nonce, txId)** and stored as a cryptographic proof of the request. * **bridgeAssetTargetChain:** This instruction is executed on the destination chain (e.g., Solayer) after guardians validate the original transaction and submit their aggregated signatures. The program verifies the multi-sig using Solana’s precompiled ed25519\_program, checks the bridge proof PDA for existence on destination chain (to prevent double-processing), and then transfers the bridged asset to the recipient. If the asset is not natively available on the destination chain, a wrapped token is minted under the authority of brdige handler. The bridge program enforces threshold signature validation, configurable guardian sets, and precise accounting to guarantee safety and liveness across the bridge. ### Cross-Chain Call The cross-chain call module enables authenticated, cross-chain execution of pre-authorized instructions on the destination chain. This mechanism is particularly useful for multi-chain transactions with specific order requirements. * **source chain:** On the source chain, the user serializes a transaction for the destination chain and encodes it into base58 format. This payload is then submitted as payload during invocation of the crossChainCall method on thethod on the source chain. * **target chain:** The Off-chain leader guardian then decodes the base58 transaction, simulates it, and then directly dispatches it to the destination chain. After successful execution, the leader guardian invokes the bridge program to create a bridge proof PDA derived from the tuple **(sender, calldata, nonce, sourceTxId)** to mark completion. # Security Measures Source: https://docs.solayer.org/documentation/solayer-bridge/security-measures Security measures and double-handling prevention in sBridge To ensure safe and deterministic cross-chain execution, the sBridge protocol enforces strict double-handling prevention guarantees across both on-chain and off-chain components. These properties are critical for maintaining correctness in the presence of retries, partial failures, and network reordering—common in asynchronous, adversarial environments. ### Double-Handling Prevention * **On-chain Prevention**: Each bridge operation is uniquely identified by a deterministic Program Derived Address (PDA) derived from a tuple of immutable parameters. Before executing any bridge instruction, the target chain's Bridge Program performs a **PDA existence check**. If the PDA already exists, the instruction is aborted, thereby preventing double-execution of the same logical transaction. * **Off-chain De-duplication**: Off-chain, each guardian maintains a persistent log of all observed and signed source transactions, indexed by their sourceTxId. Before processing a new transaction, a guardian checks this log to determine whether it has already produced a signature or witnessed the transaction being finalized. This prevents unnecessary signature generation and ensures consistency across leader rotation or recovery. In addition, each guardian tracks the **highest processed nonce** per bridge direction (Solana → Solayer and Solayer → Solana). Any incoming transaction with a nonce lower than the stored watermark is rejected as stale or previously handled. This mechanism also serves as a compact garbage collection strategy when purging old transaction logs or reclaiming PDA rent. * **Recovery Safety**: During recovery (e.g., after crash or restart), guardians restore their high-water mark from durable storage and resume transaction polling from the last acknowledged signature. Since all critical execution paths are gated by PDA existence (on-chain) and signature logs (off-chain), the system tolerates retries and message duplication without compromising safety or introducing non-deterministic behavior. These mechanisms align with formal principles of **exactly-once semantics** in distributed systems and are inspired by transaction replay resistance models used in production systems like Cosmos IBC and LayerZero Ultra Light Nodes. ### Database-less Design sBridge is intentionally architected to be stateless and database-free for its off-chain components. All critical state—such as bridge transactions, proof-of-execution PDAs, and guardian signature attestations—is verifiably recorded on-chain. This enables guardians to operate without relying on traditional databases or persistent off-chain storage for consensus-critical data. Instead of maintaining local copies of transaction history or signature logs, each guardian deterministically recomputes the required state by polling the source chain and observing PDAs on the destination chain. Bridge proof PDAs act as cryptographic checkpoints that encode uniqueness, replay protection, and confirmation status. This design has multiple advantages: * **No Single Point of Failure**: Without a dependency on local databases, guardians avoid the risk of data corruption, rollback inconsistencies, or split-brain scenarios. * **Simplified Recovery**: A guardian node can crash, be wiped, or be redeployed without special backup protocols. As long as it retains access to the source and destination chain RPC endpoints, it can catch up by scanning on-chain state. * **Deterministic Auditability**: All decisions—bridging eligibility, signature validity, replay protection—can be reconstructed and verified by any observer with access to public chain state. * **Operational Simplicity**: No need for database migrations, schema management, or replication logic simplifies deployment and improves maintainability. This database-less paradigm is core to sBridge’s philosophy of minimizing off-chain trust assumptions, maximizing determinism, and aligning security guarantees with on-chain consensus. It enables a guardian network that is modular, fault-tolerant, and horizontally scalable. ### Bridge Cap Protection To mitigate systemic risk and protect downstream liquidity, sBridge enforces a dynamic bridge cap mechanism on outbound transfers from Solayer to Solana. This cap represents the maximum allowable dollar-denominated value that can be bridged within a given epoch. * **Cap Threshold Enforcement**: During each epoch, bridge transactions from Solayer to Solana are accepted and processed immediately—as long as the total cumulative value bridged remains below the configured cap (denominated in USD). This provides fast-path execution for routine usage without introducing artificial delays. * **Overflow Queueing with Delay**: Once the cap is exhausted within an epoch, all subsequent bridge transactions are deferred and added to a queue. These queued transactions are rate-limited and released in FIFO (first-in, first-out) order with a fixed 6-hour delay, ensuring predictability while deterring burst withdrawal behavior. This staggered release reduces liquidity shocks and gives guardians and protocols time to respond. * **Governance Control**: The bridge cap value is configurable and governed by the Solayer on-chain multisig. This allows trusted actors to raise or lower the cap in response to changes in bridge volume, liquidity conditions, or detected anomalies (e.g., sudden surge in outbound volume indicative of an exploit). * **Directional Scope**: Importantly, the bridge cap currently applies only in the Solayer → Solana direction. This is due to asymmetric risk exposure: Solayer, being the newer chain, carries more economic and security uncertainty. Applying a cap in this direction mitigates scenarios where a compromise on Solayer could lead to unbounded asset issuance on Solana. Bridge cap protection reflects a proactive risk-aware philosophy: it does not block usage but rather modulates it in accordance with security posture and real-time liquidity conditions. # Solayer Chain Source: https://docs.solayer.org/documentation/solayer-chain Hardware-accelerated blockchain for high throughput and low latency ## Architecture Solayer Chain scales a single global state machine by distributing workloads across **microservices and specialized hardware accelerators** while maintaining **atomic state transitions**. This avoids the state fragmentation common in sharded or rollup-based designs. Solayer Chain delivers **1M+ TPS** with low latency and full composability — no fragmented state, no cross-shard coordination overhead. Solayer Chain Architecture ## Performance Targets * **1M+ TPS**: Sustained transaction throughput (currently achieving 340k+ TPS in devnet) * **100Gbps+ Bandwidth**: Network capacity for high-throughput data processing * **Microsecond Latency**: Ultra-low inter-node communication * **Atomic Composability**: No fragmented state * **Solana VM Compatible**: Deploy existing Solana programs with minimal changes ## Hardware-Accelerated Execution Solayer offloads critical blockchain operations to distinct, highly optimized hardware clusters: * **Signature Verification**: Dedicated verification accelerators * **Transaction Filtering**: Pre-execution validation and filtering * **Simulation**: Transaction outcome prediction * **Scheduling**: Intelligent transaction ordering * **Storage**: High-performance distributed storage This division enables **massive parallelization** and eliminates bottlenecks in transaction processing. ## Network & Communication Layer ### InfiniBand RDMA Near-microsecond inter-node communication through: * Remote memory operations without CPU involvement * Bypassing traditional OS network stacks * Zero-copy, high-speed data transfers Learn more: [RDMA & InfiniBand →](/documentation/introduction/system-architecture/rdma-infiniband) ### Software-Defined Networking (SDN) Programmable network control enabling: * Dynamic routing and traffic optimization * Custom protocol deployment * Consistent line-rate performance at scale Learn more: [SDN Architecture →](/documentation/introduction/system-architecture/software-defined-network) ## Execution & Consensus ### Multi-Executor Architecture Sharded execution across multiple nodes with: * Speculative transaction execution * Fine-grained scheduling * Database sharding with RDMA * Concurrent transaction processing Learn more: [Multi-Executor →](/documentation/introduction/system-architecture/multi-executor) ### Hybrid Consensus (PoA + PoS) Combines Proof-of-Authority with Proof-of-Stake: * Megaleader model with decentralized verifiers * Speculative execution before sequencing * Fallback consensus secured by Solana Learn more: [Consensus Scaling →](/documentation/introduction/system-architecture/consensus-scaling) ## Network Access ### Mainnet RPC Endpoint For production applications: ```bash theme={null} https://mainnet-rpc.solayer.org ``` Configure Solana CLI for mainnet: ```bash theme={null} solana config set --url https://mainnet-rpc.solayer.org ``` ### Devnet RPC Endpoint For testing and development: ```bash theme={null} https://devnet-rpc.solayer.org ``` Configure Solana CLI for devnet: ```bash theme={null} solana config set --url https://devnet-rpc.solayer.org ``` The devnet is specifically for **testing purposes only**. As we're in the internal devnet phase, the network may be intermittently unstable and the blockchain state might be reset during performance upgrades. ### Compatible Tooling Solayer Chain works with standard Solana development tools: * Solana CLI * Web3.js * Anchor * Other Solana SDK libraries ## Core Technologies Specialized clusters for signature verification, transaction filtering, simulation, and storage Near-microsecond inter-node communication with zero-copy data transfers Programmable network control with dynamic routing and optimization Parallel execution with sharded database and speculative processing ## Developer Resources Explore RPC endpoints and protocol APIs View transactions and blocks on Solayer Explorer Get devnet SOL for testing Cross-chain asset transfers between Solana and Solayer ## Vertically Integrated Stack Solayer is a vertically integrated financial system. From base-layer infrastructure to real-world payments, every component is built to work together: Top-performing Solana validator powered by custom hardware and MEV optimization Yield-bearing stablecoin backed by RWA T-bills with real-world spending capability ## Support Need help? Reach out to our community: * [Discord Community](https://discord.gg/solayerlabs) * [Telegram](https://t.me/joshua_sum) * [GitHub](https://github.com/solayer-labs) # Delegate LAYER Source: https://docs.solayer.org/documentation/staking/delegate Stake LAYER to a validator, claim rewards, and unstake (devnet) If you're a token holder, this is the page you want. If you're an operator, this is also how you [self-delegate](/documentation/staking/run-a-validator#self-delegate-to-start-earning). ## Prerequisites * A Solana wallet/keypair (the **same** keypair works on L1 and L2 — same address space). * **LAYER in your wallet** — either already on the **L2** (the common case, since LAYER is L2-native), or the **wrapped** form on L1 devnet (mint in the [overview](/documentation/staking/overview#network-endpoints--addresses)), which you bridge back below. * **SOL on L2** for L2 tx fees (native gas on the Solayer chain is SOL). If you have none yet, seed it while bridging via the `additionalSolGas` parameter, or bridge SOL separately. * **SOL on L1 devnet** — only if you're bridging from L1: it pays the bridge tx + L1 fees (`solana airdrop 2 -u devnet`). * Node 18+ and these packages in your project: ```bash theme={null} npm install @solayer-labs/bridge-sdk @coral-xyz/anchor \ @solana/web3.js @solana/spl-token ``` If you **already hold LAYER on the L2**, you don't need the bridge at all — skip straight to [Delegate](#delegate). ## Bridge wrapped LAYER L1 to L2 **Skip this section if you already hold LAYER on the L2** — since LAYER is L2-native, many holders never touch the bridge. Go straight to [Delegate](#delegate). LAYER's home mint lives on the L2; the Solana (L1) form is a **wrapped** representation created by the bridge. For a Solayer-native token the bridge directions are therefore the *reverse* of what you may know from Solana-native tokens: * **L2 → L1**: native LAYER is **locked in the L2 bridge vault**, and wrapped LAYER is **minted on L1** by the bridge handler (which holds the wrapped mint's authority). * **L1 → L2** (this section): your wrapped LAYER is **burned on L1**, and native LAYER is **released from the L2 bridge vault** to your L2 address. You submit one transaction on L1; an off-chain **guardian** set observes it, multi-sig signs, and completes the release on L2. The whole thing is asynchronous — your L2 tokens appear once the guardians complete it (seconds to a couple of minutes). **The L2 side pays out of a vault, not a mint.** An L1 → L2 release only works if the L2 bridge vault holds enough native LAYER — i.e. at least that much was previously bridged L2 → L1, or the team has seeded the vault. If the vault is short, your L1 burn still succeeds but the L2 completion cannot execute (`InsufficientFunds` on the bridge) until liquidity exists. You can check first: the vault is the LAYER ATA of the bridge handler PDA on the L2. **Bridge the wrapped form of LAYER, not just any token.** Once the staking program is live, it only accepts deposits of `Config.stake_mint` — the **native L2 LAYER mint**. For a Solayer-native token this is **not** the PDA-derived `["mint", bridgeHandler, l1Mint]` address (that derivation only applies to tokens whose home chain is the *source* chain, e.g. Solana-native tokens being wrapped onto the L2); what you receive on L2 is the original native mint recorded in the bridge's `TokenInfo` account. After bridging, confirm the mint you received **equals `Config.stake_mint`** (see [Check your position](#check-your-position--the-deployment)). If they differ, you bridged the wrong token and cannot stake it. Only **legacy SPL Token (Token-2020)** mints and native SOL are bridgeable. **Token-2022 is not supported.** ### Submit the bridge on L1 ```ts theme={null} import { BridgeClient, Chain } from "@solayer-labs/bridge-sdk"; import { Connection, Keypair, PublicKey, sendAndConfirmTransaction, } from "@solana/web3.js"; import { getAssociatedTokenAddressSync } from "@solana/spl-token"; import * as anchor from "@coral-xyz/anchor"; const l1 = new Connection("https://api.devnet.solana.com", "confirmed"); // Your wallet (load from file in real usage; same pubkey is your L2 address). const wallet = Keypair.fromSecretKey(/* ... */); // Wrapped LAYER mint on L1 (devnet). This is what gets burned. const L1_WRAPPED_LAYER = new PublicKey( "CJYj22nRQ7uQAV6Rmvn4sy2NduBiFwLNqdqkmH6hWDEF", ); const bridge = new BridgeClient({ connection: l1, userPublicKey: wallet.publicKey, chain: Chain.Solana, // bridging FROM Solana commitment: "confirmed", }); const params = { bridgeProofNonce: new anchor.BN(Date.now()), // any unique nonce amount: new anchor.BN(1_000_000_000), // base units — respect decimals recipient: wallet.publicKey, // who receives on L2 (you) additionalSolGas: new anchor.BN(5_000_000), // optional: seed ~0.005 SOL on L2 }; const accounts = { mint: L1_WRAPPED_LAYER, signerVault: getAssociatedTokenAddressSync(L1_WRAPPED_LAYER, wallet.publicKey), }; const tx = await bridge.createBridgeAssetSourceChainTransaction(params, accounts); const l1Sig = await sendAndConfirmTransaction(l1, tx, [wallet]); console.log("L1 bridge tx:", l1Sig); ``` Because wrapped LAYER is a bridge-created token (not native to L1), this transaction **burns** it from your L1 account — the LAYER you'll receive on L2 comes out of the L2 bridge vault, not a mint. `additionalSolGas` is useful on your first bridge: it gives the recipient L2 SOL to pay for the upcoming `delegate`/`claim` txs. Leave it `0` if you already have L2 SOL. Bridging native SOL instead? Use `bridge.createBridgeAssetSourceChainSolTransaction({ bridgeProofNonce, amount, recipient })`. ### Wait for the L2 release to complete The guardians create a "bridge proof" on L2 when the vault release is done. Poll for it using the L1 signature: ```ts theme={null} import { getTargetChainBridgeTxIdFromSourceTxId } from "@solayer-labs/bridge-sdk"; const l2 = new Connection("https://devnet-rpc.solayer.org", "confirmed"); let l2Sig: string | null = null; while (!l2Sig) { l2Sig = await getTargetChainBridgeTxIdFromSourceTxId(l1Sig, Chain.Solana, l2); if (!l2Sig) await new Promise((r) => setTimeout(r, 3000)); } console.log("Bridged! L2 completion tx:", l2Sig); ``` ### Confirm what you received on L2 What lands on L2 is LAYER's **original native mint** — on devnet `LAYER4xPpTCb3QL8S9u41EAhAX7mhBn8Q6xMTwY2Yzc` — as recorded in the bridge's on-chain `TokenInfo` pairing (`solana_mint` = wrapped, `solayer_mint` = native). It is *not* a PDA-derived wrapped mint. Check your balance and, once the staking program is initialized, verify against the canonical `Config.stake_mint`: ```ts theme={null} import { getAssociatedTokenAddressSync, getAccount } from "@solana/spl-token"; // Native LAYER mint on the L2 (devnet). Once the staking program is // initialized, read the canonical value from Config.stake_mint instead. const L2_LAYER_MINT = new PublicKey( "LAYER4xPpTCb3QL8S9u41EAhAX7mhBn8Q6xMTwY2Yzc", ); const l2Ata = getAssociatedTokenAddressSync(L2_LAYER_MINT, wallet.publicKey); console.log("Balance:", (await getAccount(l2, l2Ata)).amount.toString()); // The mint you received MUST equal Config.stake_mint. If not, you // bridged the wrong token and cannot stake it. ``` The bridge SDK's `get_target_mint` helper derives `["mint", bridgeHandler, sourceMint]`, which is only meaningful for tokens being bridged *away from their home chain* (e.g. a Solana-native token heading to the L2). Don't rely on it for the wrapped-LAYER → native-LAYER direction documented here — confirm the mint against `Config.stake_mint` (or the bridge SDK docs) instead. ## Delegate Everything from here runs against the **L2 RPC**. We use `@coral-xyz/anchor` with the staking program's IDL. Set up the client and PDA helpers once: ```ts theme={null} import * as anchor from "@coral-xyz/anchor"; import { Connection, Keypair, PublicKey, SystemProgram } from "@solana/web3.js"; import { TOKEN_PROGRAM_ID, getAssociatedTokenAddressSync, } from "@solana/spl-token"; import IDL from "./infini_stake.json"; // download: /documentation/staking/infini_stake.json const STAKE_PROGRAM_ID = new PublicKey( "mi7DC6qnESgL6TWdQn7xJBKqWwv2YiZVeoVuhpXhLvz", ); const l2 = new Connection("https://devnet-rpc.solayer.org", "confirmed"); const wallet = new anchor.Wallet(Keypair.fromSecretKey(/* ... */)); const provider = new anchor.AnchorProvider(l2, wallet, { commitment: "confirmed" }); // infini-stake is built with Anchor v2: the program ID comes from the IDL's // `address` field, so the constructor takes (idl, provider). On older Anchor // (0.29) use `new anchor.Program(IDL, STAKE_PROGRAM_ID, provider)` instead. const program = new anchor.Program(IDL as anchor.Idl, provider); const me = wallet.publicKey; // --- PDAs --- const [configPda] = PublicKey.findProgramAddressSync( [Buffer.from("config")], STAKE_PROGRAM_ID); const validatorPda = (identity: PublicKey) => PublicKey.findProgramAddressSync( [Buffer.from("validator"), identity.toBuffer()], STAKE_PROGRAM_ID)[0]; const delegationPda = (owner: PublicKey, identity: PublicKey) => PublicKey.findProgramAddressSync( [Buffer.from("delegation"), owner.toBuffer(), identity.toBuffer()], STAKE_PROGRAM_ID)[0]; // Read config to learn the stake mint + vault (don't hardcode). const config = await program.account.config.fetch(configPda); const stakeMint = config.stakeMint as PublicKey; const stakeVault = config.stakeVault as PublicKey; // = ATA(configPda, stakeMint) const myAta = getAssociatedTokenAddressSync(stakeMint, me); ``` Now delegate. `VALIDATOR_IDENTITY` is the pubkey of the validator you chose; the validator must be **active**. ```ts theme={null} const VALIDATOR_IDENTITY = new PublicKey(""); // TBD const amount = new anchor.BN(1_000_000_000); // base units; must be > 0 await program.methods .delegate(amount) .accounts({ config: configPda, validator: validatorPda(VALIDATOR_IDENTITY), delegation: delegationPda(me, VALIDATOR_IDENTITY), ownerTokenAccount: myAta, stakeVault, stakeMint, owner: me, systemProgram: SystemProgram.programId, tokenProgram: TOKEN_PROGRAM_ID, }) .rpc(); ``` What happens: your `amount` is transferred from your ATA into the program vault, a `StakeDelegation` account is created (first time only), and any already-accrued rewards are settled to your wallet. From this moment your position earns the configured APY **less your validator's commission** (effective `apy * (1 - commission)`). Calling `delegate` again on the same validator tops up the same position. ## Claim, request unstake, complete unstake ### Claim rewards (anytime) Mints your accrued rewards to your ATA. Safe to call whenever; if nothing has accrued it's a no-op. ```ts theme={null} await program.methods .claimRewards() .accounts({ config: configPda, validator: validatorPda(VALIDATOR_IDENTITY), delegation: delegationPda(me, VALIDATOR_IDENTITY), ownerTokenAccount: myAta, stakeMint, owner: me, tokenProgram: TOKEN_PROGRAM_ID, }) .rpc(); ``` ### Request unstake (starts the cooldown) Moves `amount` of your active stake into a cooldown bucket. It **stops earning immediately**; your remaining stake keeps earning. Pending rewards are settled in the same call. Only **one** pending unstake per position at a time — wait for the current one to complete before requesting another. ```ts theme={null} const unstakeAmount = new anchor.BN(500_000_000); // ≤ delegation.amount await program.methods .requestUnstake(unstakeAmount) .accounts({ config: configPda, validator: validatorPda(VALIDATOR_IDENTITY), delegation: delegationPda(me, VALIDATOR_IDENTITY), ownerTokenAccount: myAta, stakeMint, owner: me, tokenProgram: TOKEN_PROGRAM_ID, }) .rpc(); ``` ### Complete unstake (after the cooldown) After `Config.cooldown_seconds` (7 days by default) have passed since the request, withdraw the cooled-down tokens from the vault back to your ATA. ```ts theme={null} await program.methods .completeUnstake() .accounts({ config: configPda, delegation: delegationPda(me, VALIDATOR_IDENTITY), stakeVault, ownerTokenAccount: myAta, owner: me, tokenProgram: TOKEN_PROGRAM_ID, }) .rpc(); ``` Calling before the cooldown elapses fails with `CooldownNotElapsed`; calling with nothing pending fails with `NoPendingUnstake`. ## Check your position & the deployment ```ts theme={null} // Global config — APY, cooldown, the canonical stake mint/vault, totals. const config = await program.account.config.fetch(configPda); console.log("APY (bps):", config.apyBps); console.log("Cooldown (s):", config.cooldownSeconds.toString()); console.log("Stake mint:", config.stakeMint.toBase58()); // ↑ the native L2 LAYER mint — the token you hold/received must equal it console.log("Total active stake:", config.totalActiveStake.toString()); // A validator — is it active, its commission, how much is delegated to it. const v = await program.account.validator.fetch(validatorPda(VALIDATOR_IDENTITY)); console.log("Validator active:", v.active, "total stake:", v.totalStake.toString()); console.log("Commission (bps):", v.commissionBps); // effective APY = apy * (1 - commissionBps/10000) // Your position with this validator. const d = await program.account.stakeDelegation.fetch(delegationPda(me, VALIDATOR_IDENTITY)); console.log("Staked:", d.amount.toString()); console.log("Pending unstake:", d.pendingUnstake.toString()); console.log("Unstake ready at (unix):", d.unstakeReadyTs.toString()); ``` Amounts are in the token's **base units**. Divide by `10 ** decimals` (read `decimals` from the mint via `getMint`) for human-readable values. # LAYER Staking Overview Source: https://docs.solayer.org/documentation/staking/overview How LAYER staking works on the Solayer chain (devnet) **Status: pre-launch.** The staking program (`infini-stake`, ID `mi7DC6qnESgL6TWdQn7xJBKqWwv2YiZVeoVuhpXhLvz`) is **not yet deployed/initialized on devnet**. The node-run and bridge steps are executable today; the `delegate` / `claim` / `unstake` flows light up once the program is deployed and initialized. Values that only exist post-launch (live `Config` values, validator identities, etc.) are marked **TBD** or as ``; token/bridge addresses are **devnet** values. This section covers how to **run a staking node** (operator) and how to **stake LAYER to a validator** (delegator) on the Solayer chain. The Solayer chain is SVM-compatible — `@solana/web3.js`, `@solana/spl-token`, and `@coral-xyz/anchor` work against the L2 RPC exactly as they do on Solana. | If you're a… | Read | | ------------------------------------------ | ------------------------------------------------------------------------- | | Node operator who wants to run a validator | This page, then [Run a Validator](/documentation/staking/run-a-validator) | | Token holder who wants to delegate | This page, then [Delegate LAYER](/documentation/staking/delegate) | | Integrator / debugging | [Reference](/documentation/staking/reference) | ## How staking works * You stake **one SPL token** — **LAYER**, the stake token. It is both the asset you stake and the asset you earn rewards in. There is no separate reward token. * You **delegate** your tokens to a **validator** (an operator the project has registered). You can split across several validators; each `(you, validator)` pair is an independent position. * Rewards accrue **continuously** at the gross APY the admin sets, and are **minted directly to your wallet** when you claim. No epochs, no manual compounding. * Each validator charges a **commission** (0–100%, set in basis points) on its delegators' rewards, so your *effective* APY is `apy * (1 - commission)`. The admin sets a validator's initial rate at registration; the validator can change it any time via `set_commission` (only future rewards are affected) and collects it on-chain via `claim_commission`. * Unstaking has a **cooldown** (7 days by default). You request, wait, then withdraw. The portion in cooldown stops earning immediately. The staking program (`infini-stake`) runs **on the L2**, and it accepts the **L2-native LAYER mint**. LAYER's home chain is the L2 — it is a Solayer-native token, not a Solana token bridged in — so if you already hold LAYER on the L2 you can delegate straight away, no bridging needed. Only holders of the **wrapped** form on Solana (L1) have to [bridge it back](/documentation/staking/delegate#bridge-wrapped-layer-l1-to-l2) first. A "validator" in this program is just a registered pubkey on-chain — an **identity**. The node software (`rpc-v2`) does not sign anything for the staking program; the admin allowlists who counts as a validator out-of-band. Running a node is the *service* that earns you a spot on that allowlist. ### Lifecycle at a glance ``` (L1) wrapped LAYER ──bridge──▶ (L2) hold LAYER ──delegate──▶ earning rewards (skip if you already hold │ LAYER on the L2) claim_rewards ◀── anytime ────────────┤ │ withdrawn ◀── complete_unstake ◀── wait 7d ◀── request_unstake ────┘ ``` ## Network endpoints & addresses | Thing | Value | | ---------------------------------------------------- | ---------------------------------------------------------- | | L1 RPC (Solana devnet) | `https://api.devnet.solana.com` | | L2 RPC (Solayer devnet, public) | `https://devnet-rpc.solayer.org` | | L2 explorer | `https://explorer.solayer.org` | | **Sequencer gRPC** (rpc-v2 upstream) | `http://devnet-seed-1.solayer.org:5005` | | **Sequencer HTTP registry** | `http://devnet-seed-1.solayer.org:6005` | | **Sequencer JSON-RPC** (upstream fallback) | `http://devnet-seed-1.solayer.org:8899` | | Sequencer pubkey (for signature verification) | **TBD** — request from the team | | Bridge program (both chains) | `6kpxYKjqe8z66hnDHbbjhEUxha46cnz2UqrneGECmFBg` | | Bridge handler PDA (same address on both chains) | `55uVZhH3jk95dLdnsJwMAG72pecMwa8MTjVH4ni7osBy` | | Bridge SDK (npm) | `@solayer-labs/bridge-sdk` | | Staking program (`infini-stake`, L2) | `mi7DC6qnESgL6TWdQn7xJBKqWwv2YiZVeoVuhpXhLvz` | | **Stake token: LAYER** — native **L2** mint (devnet) | `LAYER4xPpTCb3QL8S9u41EAhAX7mhBn8Q6xMTwY2Yzc` (9 decimals) | | Wrapped LAYER — **L1** mint (devnet, bridge-derived) | `CJYj22nRQ7uQAV6Rmvn4sy2NduBiFwLNqdqkmH6hWDEF` | The stake token is **LAYER**, and it is **Solayer-L2-native**: the L2 mint above is the token's home, and the L1 mint is only a **wrapped** representation created by the bridge (its mint authority is the bridge handler PDA). The token/bridge addresses are **devnet** values — mainnet may differ, and the canonical source of truth once the program is initialized is `Config.stake_mint` (see [Check your position](/documentation/staking/delegate#check-your-position--the-deployment)). ### Post-launch values (TBD) These only exist after the staking program is deployed and `initialize`d: * **`Config.stake_mint`** — expected to be the **native L2 LAYER mint** above. Whatever you hold or receive on L2 must equal this value, or `delegate` rejects it. (The L1 mint is only the wrapped form — the program does not accept it.) * **Validator identity pubkey(s)** — registered validators you can delegate to. The program **IDL** is already available: [`infini_stake.json`](/documentation/staking/infini_stake.json) (served from these docs, generated from the program source). You'll need it for the TypeScript snippets in the [Delegate LAYER](/documentation/staking/delegate) page. # Staking Reference Source: https://docs.solayer.org/documentation/staking/reference PDA seeds, instruction accounts, error codes, and FAQ ## PDA seeds & instruction account checklist **PDA seeds (all under the staking program):** | Account | Seeds | | --------------------------------- | ------------------------------------------------------------------------------ | | `Config` (singleton) | `["config"]` | | `Validator` | `["validator", validator_identity]` | | `StakeDelegation` (your position) | `["delegation", owner, validator_identity]` | | `stake_vault` | ATA of the `Config` PDA for `stake_mint` (also stored in `Config.stake_vault`) | **Instruction account checklist:** | Instruction | Accounts | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | `delegate(amount)` | config, validator\*, delegation, ownerTokenAccount, stakeVault, stakeMint, owner(signer), systemProgram, tokenProgram | | `claimRewards()` | config, validator, delegation, ownerTokenAccount, stakeMint, owner(signer), tokenProgram | | `requestUnstake(amount)` | config, validator, delegation, ownerTokenAccount, stakeMint, owner(signer), tokenProgram | | `completeUnstake()` | config, delegation, stakeVault, ownerTokenAccount, owner(signer), tokenProgram | \* validator must be **active** for `delegate`. **Validator-operator instructions** — signed by the validator **identity** wallet, not the admin (the `["validator", identity]` seeds bind the signer): | Instruction | Accounts | | --------------------------------- | ---------------------------------------------------------------------------------- | | `setCommission(newCommissionBps)` | config, validator, identity(signer) | | `claimCommission()` | config, validator, identityTokenAccount, stakeMint, identity(signer), tokenProgram | Admin-only instructions (not used directly by operators or delegators): `initialize`, `set_apy`, `propose_admin`, `accept_admin`, `register_validator`, `deactivate_validator`. ## Error codes | Error | Meaning / fix | | --------------------------------------------- | ------------------------------------------------------------------------------------------------- | | `InvalidAmount` | Amount was `0`, or unstake amount exceeded your stake. | | `ValidatorInactive` | The validator was deactivated — you can't add new stake to it. (You can still claim and unstake.) | | `PendingUnstakeExists` | You already have a cooldown in flight on this position. Complete it first. | | `NoPendingUnstake` | `completeUnstake` with nothing pending. | | `CooldownNotElapsed` | `completeUnstake` called before the 7-day cooldown finished. | | `NotAdmin` | Admin-only path called by non-admin (shouldn't hit this as an operator/delegator). | | `InvalidCommission` | `register_validator` / `set_commission` got a rate above 100% (`> 10000` bps). | | `InvalidApy` / `AlreadyInactive` / `Overflow` | Admin-side or near-impossible cases. | ## FAQ * **Do I have to run a node to delegate?** No. Delegators only need LAYER on the L2 and a wallet. Running a node is for operators who want to be registered as a validator. * **Do I earn from other people's delegations?** Yes — as a validator you take a **commission** (0–100%, in bps) out of your delegators' rewards. The admin sets your initial rate at registration; you can change it any time with `set_commission` (future rewards only) and mint what's accrued to your own token account with `claim_commission`. * **Do I earn on stake that's in cooldown?** No. From the moment you `requestUnstake`, that portion stops accruing. Your remaining `amount` keeps earning (if the validator is still active). * **What if my validator gets deactivated?** Your rewards freeze at the deactivation point, but you can still `claimRewards` what accrued and `requestUnstake` / `completeUnstake` normally. To keep earning, unstake and delegate to an active validator. Deactivation is permanent — the operator would have to be re-registered under a fresh identity pubkey. * **Can I delegate to several validators?** Yes — one `StakeDelegation` per validator, all independent. Repeat the [delegate flow](/documentation/staking/delegate#delegate) with each validator's identity. * **Where do rewards land?** Directly in your LAYER ATA, on claim and on every `delegate` / `requestUnstake` (which settle pending first). * **Can I cancel a pending unstake?** No (v1). Wait out the cooldown, withdraw, then re-delegate if you want back in. * **My rpc-v2 node serves a different JSON-RPC port than the public devnet RPC. Do I have to use the public one for staking txs?** No. Once your node is caught up, point your client at `http://:18899` instead of `https://devnet-rpc.solayer.org` — it's the same network. ## See also * Bridge SDK: [`@solayer-labs/bridge-sdk`](https://www.npmjs.com/package/@solayer-labs/bridge-sdk) on npm, and [Solayer Bridge](/documentation/solayer-bridge/introduction) in these docs. * Node software: the [solayer-rpc repository](https://github.com/solayer-labs/solayer-rpc) (`rpc-v2`, `registry-probe`). * Staking program (`infini-stake`): program ID `mi7DC6qnESgL6TWdQn7xJBKqWwv2YiZVeoVuhpXhLvz`; IDL: [`infini_stake.json`](/documentation/staking/infini_stake.json). # Run a Validator Source: https://docs.solayer.org/documentation/staking/run-a-validator Run a devnet staking node and register as a validator This page targets **devnet**. For a mainnet-alpha RPC node (different endpoints and build flags), see [Mainnet Alpha Node](/documentation/run-a-node/mainnet-alpha). Start with the [LAYER Staking Overview](/documentation/staking/overview) if you haven't read it yet. ## What "running a staking node" means here There are **two separate things** that together make you a "validator": 1. **Run an `rpc-v2` node** — a follower RPC that syncs from the project's central sequencer over gRPC and serves Solana-compatible JSON-RPC. This is what you operate as infrastructure. The node binary itself has **no built-in staking logic**. 2. **Hold a "validator identity" pubkey** that the project's admin has registered in the `infini-stake` program. That on-chain registration is what makes the identity eligible to be delegated to. The build/run steps below set up #1. The [registration step](#get-your-identity-registered-as-a-validator) sets up #2. [Self-delegating](#self-delegate-to-start-earning) makes the identity actually earn. **Economics callout.** Your on-chain income has **two** parts: rewards on your **own self-delegation**, plus the **commission** (0–100%, in bps) you take out of *other* delegators' rewards. The admin sets your initial commission at registration; you change it any time via `set_commission` (future rewards only) and withdraw what's accrued via `claim_commission`. Any extra off-chain compensation for running infrastructure is separate. ## Build the node The node software lives in the [solayer-rpc repository](https://github.com/solayer-labs/solayer-rpc); the required toolchain is pinned in its `rust-toolchain.toml`. For devnet, build without the `mainnet` feature: ```bash theme={null} git clone https://github.com/solayer-labs/solayer-rpc cd solayer-rpc rustup show # pulls the pinned Rust toolchain cargo build --release -p rpc-v2 ``` The binary lands at `target/release/rpc-v2`. The sequencer binary (`target/release/sequencer`) is for the project; you don't run it. **System requirements (rough guidance):** * Linux x86\_64 (macOS works for development). * 8 GB RAM or more (16 GB comfortable). * 200 GB+ disk for slots/chaindata growth on devnet; consider a dedicated SSD/NVMe. * Stable public IPv4 if you want other RPC nodes to peer with you (set `--grpc-advertise-addr`). ## Generate your validator identity keypair The "validator identity" is a Solana keypair you control. It's used by the staking program (never by the node binary) for three things: * The admin registers its **public key** via `register_validator(identity, commission_bps)`. * You can **self-delegate** to it from any wallet (using its secret key is convenient but not required — anyone holding the stake token can delegate to this identity). * It is the **only** signer allowed to call `set_commission` (change your commission rate) and `claim_commission` (mint accrued commission to your own token account) — both bound to the keypair by the `["validator", identity]` PDA seeds, and commission pays out to an ATA this identity owns. So the **secret key is required** to manage and collect commission, not just convenient. Generate with the Solana CLI: ```bash theme={null} solana-keygen new \ --no-bip39-passphrase \ -o ~/.config/solana/infinisvm-validator.json solana-keygen pubkey ~/.config/solana/infinisvm-validator.json # → this pubkey is what you'll send to the admin for registration ``` Keep the secret key safe. It is your validator identity for as long as you're in the allowlist. Deactivation is **permanent** — if you lose the key, the admin can register you under a new pubkey, but the old one cannot be reactivated. The node software (`rpc-v2`) does **not** read this keypair. There is no `--identity-keypair` flag on `rpc-v2`. Keep it separate from any node-host credentials. ## Run rpc-v2 against the devnet sequencer Minimal invocation, connecting to the project's devnet sequencer (`devnet-seed-1.solayer.org`). Replace `` and `` with real values; ask the team for the sequencer pubkey. ```bash theme={null} mkdir -p /var/lib/infinisvm/{slots,chaindata,logs} RUST_LOG=info ./target/release/rpc-v2 \ --sequencer-grpc-server-addr http://devnet-seed-1.solayer.org:5005 \ --sequencer-http-server-addr http://devnet-seed-1.solayer.org:6005 \ --sequencer-rpc-server-addr http://devnet-seed-1.solayer.org:8899 \ --rpc-registry-addrs http://devnet-seed-1.solayer.org:6005 \ --sequencer-pubkey \ --grpc-listen-addr 0.0.0.0:15005 \ --grpc-advertise-addr :15005 \ --listen-addr 0.0.0.0:18899 \ --metric-addr 127.0.0.1:3002 \ --local-slots-path /var/lib/infinisvm/slots \ --local-db-path /var/lib/infinisvm/chaindata \ --start-slot latest \ 2>&1 | tee /var/lib/infinisvm/logs/rpc-v2.log ``` **What each flag does (highlights):** * `--sequencer-grpc-server-addr` — primary gRPC upstream for block sync. * `--sequencer-http-server-addr` / `--sequencer-rpc-server-addr` — snapshot bootstrap and JSON-RPC fallback to the sequencer. * `--rpc-registry-addrs` — registry to register yourself with, comma-separated if you want to point at multiple. * `--sequencer-pubkey` — required; rpc-v2 verifies the sequencer's finalization signature with this. A mismatch makes the node refuse to finalize blocks. * `--grpc-listen-addr` — where your node serves gRPC sync to *downstream* subscribers (peers, indexers). * `--grpc-advertise-addr` — the public address you announce to the registry so other nodes can dial you. Set to your public IP/DNS if exposed. * `--listen-addr` — your Solana-compatible JSON-RPC for clients (web3.js, Anchor, etc.). * `--metric-addr` — Prometheus metrics endpoint. * `--start-slot latest` — start tailing from the current tip. Avoid `checkpoint` (would need S3 access to `s3://solayer-devnet`). ### Optional: Cassandra indexer + S3 These are **not required** for a follower that just syncs + serves RPC. They add: * `--cassandra-hosts host1:9042,host2:9042 --cassandra-replication-factor N` — enables indexed historical queries (transaction-by-signature, etc.). Stand up your own ScyllaDB/Cassandra cluster if you need this. * `--s3-path`, `--s3-access-key-id` (env `S3_ACCESS_KEY_ID`), `--s3-secret-key` (env `S3_SECRET_KEY`), `--s3-region` — for snapshot/slot backfill from S3. Project-internal on devnet today; skip unless you've been given creds. ### systemd unit (example) ```ini theme={null} # /etc/systemd/system/rpc-v2.service [Unit] Description=infinisvm rpc-v2 After=network-online.target [Service] User=infinisvm WorkingDirectory=/opt/infinisvm Environment=RUST_LOG=info ExecStart=/opt/infinisvm/target/release/rpc-v2 \ --sequencer-grpc-server-addr http://devnet-seed-1.solayer.org:5005 \ --sequencer-http-server-addr http://devnet-seed-1.solayer.org:6005 \ --sequencer-rpc-server-addr http://devnet-seed-1.solayer.org:8899 \ --rpc-registry-addrs http://devnet-seed-1.solayer.org:6005 \ --sequencer-pubkey \ --grpc-listen-addr 0.0.0.0:15005 \ --grpc-advertise-addr :15005 \ --listen-addr 0.0.0.0:18899 \ --metric-addr 127.0.0.1:3002 \ --local-slots-path /var/lib/infinisvm/slots \ --local-db-path /var/lib/infinisvm/chaindata \ --start-slot latest Restart=always RestartSec=5 LimitNOFILE=200000 [Install] WantedBy=multi-user.target ``` ```bash theme={null} sudo systemctl daemon-reload sudo systemctl enable --now rpc-v2 sudo journalctl -fu rpc-v2 ``` ## Verify the node is syncing **JSON-RPC `getSlot` should advance**: ```bash theme={null} watch -n 1 'curl -s http://127.0.0.1:18899 \ -H content-type:application/json \ -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"getSlot\",\"params\":[]}"' ``` Compare against the public sequencer: ```bash theme={null} curl -s http://devnet-seed-1.solayer.org:8899 \ -H content-type:application/json \ -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}' ``` Your lag should be small (single-digit slots in steady state) once caught up. **Prometheus metrics**: ```bash theme={null} curl -s http://127.0.0.1:3002/metrics | head -50 ``` **Peer/registry status** (uses the `registry-probe` helper binary from the same repo): ```bash theme={null} ./target/release/registry-probe registry --addr http://devnet-seed-1.solayer.org:6005 ./target/release/registry-probe node --grpc http://127.0.0.1:15005 ``` **Common failure modes:** | Symptom | Likely cause | | ----------------------------------------------- | ---------------------------------------------------------------------------------- | | Node exits with "signature verification failed" | Wrong `--sequencer-pubkey`. Re-fetch from the team. | | `failed to connect to gRPC` | Sequencer host/port unreachable. Check egress to `devnet-seed-1.solayer.org:5005`. | | Slot frozen / never advances | Upstream momentarily down, or `--start-slot` is in the wrong mode. Try `latest`. | | Disk fills up | Slots/chaindata grow. Mount a larger volume; rotate logs. | ## Get your identity registered as a validator Validator allowlisting is admin-controlled and off-chain. Once your node is syncing and your identity keypair is ready: 1. **Contact the project team.** Send them: * Your validator identity **pubkey**. * Your node's `--grpc-advertise-addr` so they can verify it's reachable. * Any operator metadata they ask for (contact, name to display, etc.). 2. **Admin runs `register_validator(identity, commission_bps)`.** This creates a `Validator` PDA at seeds `["validator", identity]` with `active = true` and your commission rate set to `commission_bps` (basis points, capped at `MAX_COMMISSION_BPS = 10000` = 100%; otherwise rejected with `InvalidCommission`). You can change the rate later via `set_commission`. 3. **Verify on-chain.** Once registered: ```ts theme={null} import * as anchor from "@coral-xyz/anchor"; import { Connection, PublicKey } from "@solana/web3.js"; import IDL from "./infini_stake.json"; // download: /documentation/staking/infini_stake.json const STAKE_PROGRAM_ID = new PublicKey( "mi7DC6qnESgL6TWdQn7xJBKqWwv2YiZVeoVuhpXhLvz", ); const l2 = new Connection("https://devnet-rpc.solayer.org", "confirmed"); const provider = new anchor.AnchorProvider( l2, new anchor.Wallet(anchor.web3.Keypair.generate()), {}); const program = new anchor.Program(IDL as anchor.Idl, provider); const myIdentity = new PublicKey(""); const [validatorPda] = PublicKey.findProgramAddressSync( [Buffer.from("validator"), myIdentity.toBuffer()], STAKE_PROGRAM_ID, ); const v = await program.account.validator.fetch(validatorPda); console.log("active:", v.active, "total_stake:", v.totalStake.toString()); ``` The node binary doesn't know about — and isn't notified by — this registration. It's purely an on-chain effect. ## Self-delegate to start earning Your on-chain staking income has two parts: rewards on your own self-delegation, plus the commission you take from any other delegators (set by the admin at registration, adjustable via `set_commission`, collected via `claim_commission`). To earn on your own stake, follow [Delegate LAYER](/documentation/staking/delegate) from your validator's perspective: 1. Acquire **LAYER on the L2** (devnet mint in the [overview](/documentation/staking/overview#network-endpoints--addresses)). LAYER is L2-native, so you may already hold it there; if what you hold is the **wrapped** form on Solana (L1), [bridge it back to L2](/documentation/staking/delegate#bridge-wrapped-layer-l1-to-l2) first. 2. **Delegate to your own identity pubkey** — the `validator_identity` you pass to the delegation PDA is your validator's pubkey; the `owner` (signer) can be the same keypair or a different wallet that holds the stake token. After delegation the rewards accumulate continuously and you can `claim` to your wallet whenever you want. Your **commission** on *other* delegators' stake accrues separately — mint it to your own token account any time with `claim_commission` (see the [reference](/documentation/staking/reference)). # Brand Kit Source: https://docs.solayer.org/resources/brand-kit A brand kit is a collection of visual and textual elements that define a brand's identity. It can include logos, colors, fonts, images, tone of voice, and templates. Use below assets to your design. Learn more about Solayer's brand guidelines [here](https://drive.google.com/drive/folders/1M8zgoynHuX7ynXzG4JuQW50l7QA333NJ). ## Solayer Logo's [Download Full Kit here (Green, White, Black variants)](https://drive.google.com/drive/folders/1huL7HM-d8Hh0sNv8s6r1Z5iE9PLlR-1j)
### Full Logo With Background Full Logo - Yello Green Font with Dark Green Full Logo - Green Font with White Full Logo - White Font with Dark ### Full Logo Without Background (Transparancy) Full Logo - Yello Green Font Full Logo - Green Font Full Logo - White Font ### Full Logo - SVG Full Logo - Yello Green Font with Dark Green Full Logo - Green Font with White Full Logo - White Font with Dark
### Logomark With Background Full Logo - Yello Green Font with Dark Green Full Logo - Green Font with White Full Logo - White Font with Dark ### Logomark Without Background (Transparancy) Full Logo - Yello Green Font Full Logo - Green Font Full Logo - White Font ### Logomark - SVG Full Logo - Yello Green Logo with Dark Green Full Logo - Green Logo with White Full Logo - White Logo with Dark
### Wordmark With Background Full Logo - Yello Green Font with Dark Green Full Logo - Green Font with White Full Logo - White Font with Dark ### Wordmark Without Background (Transparancy) Full Logo - Yello Green Font Full Logo - Green Font Full Logo - White Font ### Wordmark - SVG Full Logo - Yello Green Font with Dark Green Full Logo - Green Font with White Full Logo - White Font with Dark
## Typography Typography 1 Typography 1 Typography 1 Typography 1 # Litepapers Source: https://docs.solayer.org/resources/litepapers Technical litepapers covering Solayer Chain, sSOL, sUSD, and the broader ecosystem.
## **Litepapers** ### **1. Solayer Chain Litepaper** 📄 **[Read the Solayer Chain Litepaper](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/solayer_infinisvm_litepaper.pdf)** This litepaper introduces **Solayer Chain**, Solayer’s Hardware Accelerated SVM optimized execution environment designed to enhance **parallel processing, transaction efficiency, and state management**. Key highlights include: * **Hardware Accelerated Structural** * **High-performance Multi executor model**. * **Optimized transaction scheduling** to maximize throughput. * **Consensus Scaling**.
### **2. Solayer Ecosystem Litepaper for sSOL** 📄 **[Read the Solayer Litepaper v0](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/solayer-litepaper-v0.pdf)** The **Solayer Litepaper v0** provides a **broad overview** of Solayer’s protocol innovations, including: * **Economic incentives** for validators and users. * **Integration of modular execution layers**. * **Role of sSOL in ecosystem liquidity**. This document covers Solayer’s protocol design, detailing how sSOL improves DeFi composability while preserving security and decentralization.
### **3. Solayer USD (sUSD) Litepaper** 📄 **[Read the Solayer USD Litepaper v0](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/solayer-USD-litepaper-v0.pdf)** sUSD is Solayer’s yield-bearing stablecoin, backed by tokenized U.S. Treasury Bills. This litepaper covers: * **sUSD’s on-chain economic model**. * **Yield generation through tokenized U.S. Treasury Bills**. * **Integration with DeFi protocols** to maximize efficiency. sUSD brings T-bill yield on-chain, giving users a stable, yield-bearing asset for saving and DeFi use.
# Protocol API Source: https://docs.solayer.org/resources/protocol-api # Protocol API This endpoint retrieves protocol-wide statistics, including the current APY, number of depositors, epoch details, TVL (Total Value Locked), and more. ## Overview **Endpoint** ``` GET https://app.solayer.org/api/info ``` **Description** * This endpoint returns a JSON object that contains various protocol-level data, such as APY, epoch start/end times, the sSOL conversion ratio, token TVL, and more. **Authentication** * Not required ## Response Parameters Below is an example JSON response and the description of each field. ### Field Descriptions: | Field | Type | Description | | ---------------------- | ------ | --------------------------------------------------------------------- | | **apy** | Number | Current annual percentage yield (APY) of the protocol. | | **depositors** | Number | Total number of depositors. | | **epoch** | Number | The current epoch number. | | **epoch\_diff\_time** | String | Remaining (or elapsed) time for the current epoch (e.g., `33h46m8s`). | | **epoch\_end\_time** | Number | Unix timestamp (in milliseconds) when the current epoch ends. | | **epoch\_start\_time** | Number | Unix timestamp (in milliseconds) when the current epoch started. | | **ssol\_holders** | Number | Number of sSOL token holders. | | **ssol\_to\_sol** | Number | Conversion ratio from sSOL to SOL (e.g., `1 sSOL = ssol_to_sol SOL`). | | **ssud\_apy** | Number | APY for the sSUD token. | | **ssud\_holders** | Number | Number of sSUD token holders. | | **token\_tvl\_usd** | Object | Key-value pairs representing each token's TVL in USD. | | **tvl\_sol** | Number | Total TVL of the protocol denominated in SOL. | | **tvl\_usd** | Number | Total TVL of the protocol in USD. | Inside `token_tvl_usd`, each key (for example, `sBBSOL`, `sBNSOL`, `sBSOL`, etc.) corresponds to a specific token's TVL in USD. ## Example Usage ```bash theme={null} curl -X GET "https://app.solayer.org/api/info" ``` **Sample Response**: ```json theme={null} { "apy": 8.99, "depositors": 302924, "epoch": 747, ... } ``` # Audits Source: https://docs.solayer.org/resources/security/audits Security is a core development effort of Solayer's long-hauled commitment to building secure and scalable crypto-economic infrastructure. Here we present our audit reports: 1. [OtterSec](https://github.com/solayer-labs/token-metadata/blob/07981c9059f64b50132a67c9db57219ed194678d/audit.pdf): April, 2024 Audit 2. [OtterSec](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/audits/restaking/OtterSec-audit-report-restaking-program.pdf): July, 2024 Audit 3. [Halborn - endoAVS](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/audits/endoavs/Halborn-audit-report-endoavs-program.pdf): August, 2024 4. [Halborn - pool](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/audits/restaking/Halborn-audit-report-restaking-program.pdf): August, 2024 5. [Halborn - sUSD](https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/audits/stablecoin/Halborn-audit-report-susd-program.pdf): October, 2024 Despite having thorough security reviews, we encourage community members, technical hackers, and researchers to comprehensively review the contracts, and report to [`report@solayer.org`](mailto:report@solayer.org), or via proper channels if any bugs have been identified. Lastly, Solayer will conduct two audits per year on all existing contracts. # Multisigature Committees Source: https://docs.solayer.org/resources/security/multisignature-committees The Solayer contract is inherently upgradable for several reasons. Firstly, stage 1 will be released in multiple phases, necessitating contract upgrades. Secondly, in emergencies, the core team must be able to swiftly implement proactive changes. Lastly, to ensure transparency and a community-first approach, the Solayer core team has decided to decentralize the development process. Hence, contract ownership is migrated to a multisig of known individuals within the Solana community. **Multisig Address**: GcYvLKKEWpxQMqFe9HUcDJYMGvXt7kwf8gfBvjnW4wnm **Program**: sSo1iU21jBrU9VaJ8PJib1MtorefUV4fzC9GURa2KNn The upgradability of the Solayer contract is overseen by trusted community leaders. Initially, we have selected 3 out of the 5 multisig seat holders, with one seat occupied by the Solayer core team. To maintain our commitment to transparency and a community-first approach, we will gather community feedback to appoint 1 more community member to the governing seat. Candidates will be evaluated diligently following a public forum, and more information will be released soon. This multisig controls protocol-code upgrades. To modify our program, the multisig must have a 3 out of 5 quorum signing to approve any upgrade. Solayer core team may conduct a forum to discuss potential increase or decrease of seat holders and quorum threshold. This is to ensure no one can act maliciously and can be immediately stopped by others. **Below are the first 3 community seat holders, out of 5 in total.** Joseph Lallouz (Bison Trail) Michael Repetny (Marinade Finance) Robert Chen (Osec) Solayer Core Team (2 keys) # Solayer Programs Source: https://docs.solayer.org/resources/solayer-programs Each program is an on-chain account that stores executable logic, organized into specific functions referred to as instructions. Solayer has deployed the following programs:
Program Description Program ID
Pool Manager Manages the flow of deposited assets. sSo1iU21jBrU9VaJ8PJib1MtorefUV4fzC9GURa2KNn
sSOL Liquidity layer for Solayer. sSo14endRuUbvQaJS3dq36Q829a3A6BEfoeeRGJywEh
endoAVS Program Endogenous AVS program. endoLNCKTqDn8gSVnN2hDdpgACUPWHZTwoYnnMybpAT
Pool Account Pool account for sUSD FhVcYNEe58SMtxpZGnTu2kpYJrTu2vwCZDGpPLqbd2yG
sUSD Program Program ID for sUSD program s1aysqpEyZyijPybUV89oBGeooXrR22wMNLjnG2SWJA
sUSD Token sUSD token info susdabGDNbhrnCa6ncrYo81u4s9GM8ecK2UwMyZiq4X
## Program Details You can also find the IDL files of our programs here: * [Pool Program IDL](https://github.com/solayer-labs/solayer-cli/blob/main/restaking/utils/restaking_program.json) * [endoAVS Program IDL](https://github.com/solayer-labs/solayer-cli/blob/main/endoavs/utils/endoavs_program.json) * [sUSD Program IDL](https://explorer.solana.com/address/s1aysqpEyZyijPybUV89oBGeooXrR22wMNLjnG2SWJA/anchor-program) # Tokenomics Source: https://docs.solayer.org/resources/tokenomics In 2024, with more than **\$500 million staked**, over **200,000 active users**, and **bluechip AVS partners**, we have become the **leading restaking platform** for enhancing internal Solana applications via **stake-weighted quality of service**. In 2025, we are doubling down on our thesis with **hardware offloading of blockchain into programmable hardware chips** — presenting the **first 1M+ TPS network in the world, Solayer Chain**.
## \$LAYER - Connecting the Solayer Ecosystem **Infrastructure on the bottom. Vertical stack on the top.**\ Our team is building both the infrastructure layer — **Solayer Chain** — and a suite of vertical products on top of it. **sSOL, sUSD, and Solayer Pay** are the first, with more in development. Underpinning all of this is **\$LAYER**, which is both the **native token for Solayer Chain** as well as the **governance token for Solayer’s protocol suites**.
## Token Distribution $LAYER at a glance To ensure **broad decentralization**, **\$LAYER** is being distributed through both the **community sale of our Solayer Pay** and our **genesis airdrop for early adopters**. The **max supply** of $LAYER will be **1,000,000,000 tokens**, distributed across three main categories, with an **initial circulating supply of 220,000,000 $LAYER (22%)\*\*: ### **Community & Ecosystem** \[51.23%] * **34.23%** is for **continued R\&D, developer programs, ecosystem growth**, and other user activities. * **14%** is for **community events/incentives** (including **12% reserved for the Genesis Drop** to reward early adopters and initial claim activities). * **3%** is distributed via the **Solayer Pay community sale**. ### **Core Contributors** \[17.11%] * Reserved for **core contributors and advisors**. ### **Investors** \[16.66%] * Allocation for **investors**. ### **Foundation** \[15%] * Allocated to the **Solayer Foundation** to support **vertical product expansion** and **network development**. $LAYER Distribtuion
## LAYER Vesting Schedule \$LAYER tokens will be emitted over time, following the vesting schedule below: * **Genesis Drop**: Fully **unvested** at launch. * **Solayer Pay Community Sale**: Fully **unvested** at launch. * **Community incentives**: **Linearly vested** for **6 months**. * **Community & Ecosystem**: **Vested every 3 months** over **4 years**. * **Foundation**: **Vested every 3 months** over **4 years**. * **Team & Advisors**: **1-year cliff, 3 years linear vesting**. * **Investors**: **1-year cliff, 2 years linear vesting**. $LAYER Vesting
## Token Design \$LAYER has **utility** across the entire **Solayer ecosystem**.\ At launch, the primary utility is **governance**, with **network-specific utility** becoming available with **Solayer Chain**, and **protocol-level utility** with our incoming **vertical product suites**. ### **Governance \[current]** * **Protocol upgrades**, such as **adding supported assets**. * **Key ecosystem initiatives**, such as **grants**. ### **Future Use Cases \[subject to design change]** * **Participate in Proof of Stake consensus** for **Decentralized Verification** to **earn block rewards**. * **Verifiers securing Solayer get rewarded with \$LAYER**. * **\$LAYER as the gas token** for **transactions on the Solayer network**.
## **\$LAYER Genesis Drop** The second **\$LAYER distribution** is for **existing community members** who’ve been with us since launching in 2024. Solayer is reserving **12% total** for **community members, integration partners, and liquidity providers**, recognizing those who **bootstrapped the ecosystem** and will continue our journey in 2025. ### **Eligibility** * **sSOL and sUSD holders**. * **Users who delegated sSOL to AVS partners**. * **Users who deposited sSOL or sUSD in partnered DeFi protocols**. * **Users who deposited whitelisted LSTs on Solayer**. * **Users who deposited with Solayer through partner and wallet campaigns**. * **LRT protocols**. * **Other claim initiatives**. ### **Vesting** For **early and eligible community members**, the **genesis drop is immediately unlocked** at launch, with additional \$LAYER **claimable over the next 6 months by Epoch**.
## **\$LAYER and Hardware-Accelerated Blockchain** With **over 250,000 unique holders** eligible at launch, \$LAYER is the shared incentive layer across the Solayer ecosystem. Whether used to power Solayer Chain or govern protocol-level products, **\$LAYER aligns incentives** across validators, users, and developers as we build toward a high-performance, hardware-accelerated blockchain. # Physical Card Source: https://docs.solayer.org/solayer-pay/card ## How to Order Your Physical Card Download the Solayer Pay app on iOS or Android. Solayer Pay app download screen Access your Solayer Pay Dashboard: * **Existing users:** Go to your Dashboard and tap **"Create a card"**. * **New users:** First, complete Solayer Pay onboarding in the app (KYC + virtual card activation). Once your account is set up, you can order your physical card from the Dashboard. Enter your shipping address and confirm your details. Solayer Pay Dashboard - Create a card Solayer Pay - Enter shipping address Each Solayer Pay account is limited to **10 cards total**, including cancelled, closed, and inactive cards. Cancelling a card does not free up a slot, so please order thoughtfully — once you reach 10, you can't issue new cards on this account.
## Physical Card Fee The physical card is **FREE** — you only pay shipping. **Note for new users:** A one-time **\$20 account activation fee** applies when you set up your Solayer Pay account (covers your virtual card for the first year).
## Shipping & Delivery **Delivery time:** Depends on the shipping method you select at checkout. **Shipping Address changes:** Once your order is submitted, the shipping address cannot be changed. Please double-check all details before confirming. | Shipping Method | Shipping Cost | Details | | --------------------- | ------------- | --------------------------- | | US Express | \$24.99 | 2–5 business days, tracked | | International Express | \$59.99 | 5–11 business days, tracked | *Shipping time includes card production time.* ## Activating Your Card Once your card arrives: 1. Open the Solayer Pay app. 2. Tap **"Activate Physical Card"** and follow the on-screen prompts. You'll be asked to enter your card details and set your PIN. Solayer Pay - Activate Physical Card screen Solayer Pay - Set PIN screen
## Using Your Physical Card * **In-store purchases:** Use your card like any regular Visa card. * **Contactless payments:** Tap-enabled for faster checkout at supported terminals. * **ATM withdrawals:** Supported in most regions where Visa ATMs are available. Standard ATM and network fees may apply. * Maximum withdrawal amount per transaction: **\$250** (inclusive of any ATM surcharges) * Maximum attempts: **Three** within a rolling 24-hour period * **Online purchases:** Use either your physical or virtual card number. * **Apple Pay & Google Pay:** Add your physical card to your digital wallet directly from the app.
## FAQs **Q: Can I still use my virtual card after activating the physical one?** Yes. Both cards remain active and draw from the same Solayer Pay balance. **Q: What if my card is lost or stolen?** Freeze it immediately in the app, then order a replacement card. **Q: How many cards can I have on one account?** Each account is limited to 10 cards total including cancelled, closed, and inactive cards. Once you hit the limit, you cannot issue new cards — cancelling does not free up a slot. Please order thoughtfully. **Q: Can I add my physical card to Apple Pay or Google Pay?** Yes. **Q: Is my PIN recoverable if I forget it?** You can reset your PIN in the mobile app.
*** ## Need Help? If you have questions about your card or your order, reach the Solayer Pay support team through the app or at [support@solayer.org](mailto:support@solayer.org). # Eligibility Source: https://docs.solayer.org/solayer-pay/eligibility Learn which regions are eligible or restricted for Solayer Card usage based on compliance and regulatory policies. ## Who Can Use the Solayer Card? The Solayer Card is available to users in many regions worldwide. Individuals who are **18 years or older** and have successfully passed the **KYC (Know Your Customer)** process are eligible to apply. However, due to **regulatory restrictions and compliance policies**, certain countries, territories, and U.S. states are **not eligible** for Solayer Card access. This document outlines the list of restricted regions where users are **unable to sign up or utilize** the card. *** ## Restricted U.S. States Residents of the following U.S. states are **not eligible** to sign up for the Solayer Card: | | | | | | ------------ | ------------ | ------- | ---------- | | Arizona | Delaware | Georgia | Idaho | | Louisiana | Maryland | Montana | Nevada | | New Mexico | North Dakota | Ohio | Oregon | | Rhode Island | South Dakota | Vermont | Washington | | Wisconsin | | | |
## Restricted Countries and Territories (Global) Residents or citizens of the following countries and territories are **not eligible** to sign up for the Solayer Card, regardless of their current place of residence: | | | | | | -------------------------------- | ------------------------ | --------------------- | -------------------- | | Afghanistan | Albania | Andorra | Australia | | Austria | Belarus | Belgium | Bosnia-Herzegovina | | Bulgaria | Burkina Faso | Burundi | Cambodia | | Canada | Central African Republic | China | Croatia | | Cuba | Cyprus | Czechia | Darfur | | Democratic Republic of Congo | Denmark | Eritea | Estonia | | Finland | France | Georgia | Germany | | Greece | Guinea | Guinea Bissau | Haiti | | Hungary | Iceland | India | Indonesia | | Iran | Iraq | Ireland | Israel | | Italy | Jamaica | Jordan | Kosovo | | Lao People’s Democratic Republic | Latvia | Lebanon | Liberia | | Libya | Lithuania | Luxembourg | Malaysia | | Mali | Malta | Moldova | Monaco | | Montenegro | Morocco | Mozambique | Myanmar | | Netherlands | New Zealand | Nicaragua | Nigeria | | North Korea | Norway | Palestinian Territory | Poland | | Portugal | Qatar | Romania | Russia | | San Marino | Serbia | Slovakia | Somalia | | South Africa | South Korea | Spain | Sudan | | Sweden | Switzerland | Syria | Thailand | | Turkey | Uganda | Ukraine | United Arab Emirates | | United Kingdom | Vanuatu | Venezuela | Western Sahara | | Yemen | Palau | Nepal | Vietnam |
## Why Are These Regions Restricted? The restrictions are in place due to a combination of international sanctions, regulatory requirements, and compliance measures aimed at ensuring **financial security** and **legal adherence**. * **Sanctions and Embargoes** – Countries subject to economic or trade sanctions that prevent financial services from being offered. * **Regulatory Compliance** – Certain jurisdictions have regulatory environments that do not align with the operational or compliance framework of the Solayer Card. * **Security Considerations** – In some cases, geopolitical instability and financial crime risks contribute to the restrictions.
## Future Availability Solayer continuously reviews **regulatory developments** and **market conditions**. If any changes occur that allow expansion into currently restricted regions, updates will be provided through **official Solayer communication channels**. # FAQ Source: https://docs.solayer.org/solayer-pay/faq Frequently Asked Questions about Solayer Pay, including eligibility, usage, fees, and supported countries. ## Card Application & Issuance **Q1. What is Solayer Pay?** Solayer Pay is a Visa-based card that lets users spend crypto in the real world. It's now open to all eligible users with a \$20/year membership fee. **Q2. Who is eligible for Solayer Pay?** Anyone who meets the KYC requirements and resides in a supported region can apply. Community Sale and Genesis Drop participants were part of the initial rollout. **Q4. What is the application process for the card?** * **Apply** – Visit the Card page of the Solayer app * **Requirements** – * Must be 18+ with KYC verification * Must reside in a supported region * **Membership Fee** – \$20/year * **KYC Verification & Approval** – 3–5 business days * **Virtual Card** – Use immediately upon approval via Apple Pay or Google Pay **Q5. Is a physical card available?**\ Yes. You can order a physical Solayer Pay card directly from the app or on web.
## Card Features & Usage **Q6. Where can I use Solayer Pay?**\ Anywhere Visa is accepted — online, offline, Apple Pay, and Google Pay. **Q7. What is the difference between a virtual card and a physical card?** * **Virtual Card** – Instantly issued for online purchases and mobile wallets * **Physical Card** – Enables ATM withdrawals and in-store use (coming soon) **Q9. How can I add a Solayer virtual card to my mobile wallet?**\ Please refer to the wallet adding tutorial. **Q10. Can I withdraw cash from an ATM?**\ Yes, with the physical card. Local ATM fees may apply.
## Fees & Transactions **Q11. What fees apply to Solayer Pay?** * **Membership Fee** – \$20/year * **Top-Up Fee** – 0.5% per top-up * **Transaction Fees** – * USD Transactions: \$0.15 * International (non-USD): \$0.10 + 1.75% **Q12. Can I use the card for international payments?** Yes, with Visa’s real-time exchange rate. Fees apply: \$0.10 + 1.75%.
## Community Sale Participants **Q13. What are the additional benefits for Community Sale participants?** Community Sale participants were part of the early access rollout. Check the Solayer app for any applicable benefits on your account. **Q14. What happens if I do not apply for the card?**\ Whitelisted users must apply within the designated period. **Q15. Do Community Sale participants need to complete KYC again?**\ Yes, all users must reconfirm their KYC. Additional documentation may be required.
## Privacy, Security & Customer Support **Q16. What should I do if I lose my card?**\ Freeze or unfreeze your card instantly from the Solayer Card Dashboard. **Q17. How is my personal information managed?**\ Information is handled per the card provider’s privacy policy. **Q18. How can I get customer support?**\ Via Solayer’s Discord channel.
## Supported Countries for Card Issuance Solayer Pay is available in most countries except the following: * Restricted U.S. States : Residents of the following U.S. states are **not eligible** to sign up for the Solayer Card: | | | | | | ------------ | ------------ | ------- | ---------- | | Arizona | Delaware | Georgia | Idaho | | Louisiana | Maryland | Montana | Nevada | | New Mexico | North Dakota | Ohio | Oregon | | Rhode Island | South Dakota | Vermont | Washington | | Wisconsin | | | | ## Restricted Countries and Territories (Global) Residents or citizens of the following countries and territories are **not eligible** to sign up for the Solayer Card, regardless of their current place of residence: | | | | | | ---------------------------- | -------------------------------- | ----------- | --------------------- | | Afghanistan | Albania | Andorra | Australia | | Austria | Belarus | Belgium | Bosnia-Herzegovina | | Bulgaria | Burkina Faso | Burundi | Cambodia | | Canada | Central African Republic | China | Croatia | | Cuba | Cyprus | Czechia | Darfur | | Democratic Republic of Congo | Denmark | Egypt | Eritea | | Estonia | Finland | France | Georgia | | Germany | Greece | Guinea | Guinea Bissau | | Haiti | Hungary | Iceland | India | | Indonesia | Iran | Iraq | Ireland | | Israel | Italy | Jamaica | Jordan | | Kosovo | Lao People’s Democratic Republic | Latvia | Lebanon | | Liberia | Libya | Lithuania | Luxembourg | | Malaysia | Mali | Malta | Moldova | | Monaco | Montenegro | Morocco | Mozambique | | Myanmar | Netherlands | New Zealand | Nicaragua | | Nigeria | North Korea | Norway | Palestinian Territory | | Poland | Portugal | Qatar | Romania | | Russia | San Marino | Serbia | Slovakia | | Somalia | South Africa | South Korea | Spain | | Sudan | Sweden | Switzerland | Syria | | Thailand | Turkey | Uganda | Ukraine | | United Arab Emirates | United Kingdom | Vanuatu | Venezuela | | Western Sahara | Yemen | Palau | Nepal | | Vietnam | | | | # Structure Source: https://docs.solayer.org/solayer-pay/fee Fee structure for Solayer Pay — membership, top-up, and transaction fees. ## Membership Fee Solayer Pay uses an annual membership model. | Plan | Fee | | ------ | ----------- | | Annual | \$20 / year | Membership covers card access and maintenance for 12 months. Renew annually to keep your card active. *** ## Card Type Currently, Solayer Pay issues **digital (virtual) cards** only. Physical cards are coming soon. *** ## Card Inactivity Policy * Cards will be **deactivated after 6 months** of inactivity. * To reactivate, request a new card issuance. *** ## Top-Up & Transaction Fees | Fee Type | Amount | | ------------------- | ------------------------------------------- | | Top-Up Fee | 1% per top-up transaction | | USD Transaction Fee | \$0.15 per transaction | | International Fee | \$0.10 + 1.5% per international transaction | # Overview Source: https://docs.solayer.org/solayer-pay/overview Spend USDC in the real world, earn on-chain rewards, and access decentralized finance — all from a Visa-compatible card. The wait is over. Solayer Pay is now live – available to 40,000+ users and fully integrated with Apple Pay, Google Pay, and Visa’s global network. Spend USDC like cash, earn real on-chain rewards, and use crypto for real-world purchases.
## Global, Visa-Compatible, Fully On-Chain Use Solayer Pay at real world merchants, withdraw local currency from ATMs worldwide, and pay with just a tap. * Spend directly from USDC — no pre-conversion * Apple Pay & Google Pay supported * ATM withdrawals for local cash, globally
## Your On-Chain Checking and Savings in One Think of Solayer Pay as your crypto-native financial hub. Deposit USDC to spend instantly or opt into sUSD — a Treasury-backed stablecoin offering 4–5% yield. * Instantly mint/redeem sUSD (no lockups, no minimums) * Non-custodial and fully on-chain * Switch between spending and saving anytime Even \$5 of sUSD earns real yield. It’s like a savings account — but on the blockchain.
## Powered by Solayer Chain: Real-Time On-Chain Processing Solayer Pay is built on Solayer Chain, a hardware-accelerated Solana Virtual Machine (SVM) that delivers high throughput with real on-chain execution. * Hardware-Accelerated: Built with RDMA & InfiniBand for ultra-low latency * On-chain settlement that rivals centralized processors * DeFi-Ready: Supports SVM and EVM chains for cross-chain compatibility (Coming Soon) With Solayer Chain, every Solayer Pay transaction settles on-chain with low latency.
## Rewards: The More You Spend, The More You Earn Season 2 of Solayer’s Points Program is live. Every transaction earns Solayer Card Points, which unlock: * Future \$LAYER token rewards * Partner airdrops and exclusive perks * Access to beta tests, merch, and VIP events Refer friends and earn 10% of their points — indefinitely. The more they spend, the more you earn.
## Membership Solayer Pay is open to all eligible users with a **\$20/year membership fee**. Join partner campaigns (Sonic, OpenEden, Solana ID, and more) for extra perks and rewards.
## Real Utility, Real DeFi * No centralized custodians * All transactions processed on-chain via Solayer Chain * Intuitive dashboard for managing funds, referrals, and rewards Solayer Pay is built on Solayer Chain, delivering real-time payments on decentralized infrastructure.
## How to Get Started 1. Apply at [app.solayer.org/card](https://app.solayer.org/card) 2. Complete KYC — typically 3–5 business days 3. Activate your virtual card and use it immediately via Apple Pay or Google Pay **Membership Fee: \$20 / year**
## Get Started with Solayer Pay Solayer Pay combines on-chain settlement with real-world spending. [Get Started →](https://app.solayer.org/card) # Solayer Card Points & Perks Source: https://docs.solayer.org/solayer-pay/point Earn rewards and enjoy Solana ID-based benefits with Solayer Pay.
## Solayer Pay Benefits Solayer Pay gives you more than just spending power. Get rewarded with every purchase through: * **Solayer Card Points** – earn points for every transaction * **Solana ID-Based Discounts** – get personalized perks based on your onchain reputation * **Nubit Genesis Rewards Program** – special rewards for early users
## Solayer Card Points Earn points instantly every time you spend with your Solayer Pay. ### How It Works Every transaction earns points based on the **amount spent** and a **multiplier** applied **per transaction**: | Transaction Amount (USD) | Multiplier | Points Earned per \$1 | | ------------------------ | ---------- | --------------------- | | Less than \$100 | 1x | 1 | | $100 – $499 | 2x | 2 | | $500 – $2,499 | 3x | 3 | | \$2,500 or more | 5x | 5 | **Examples:** * A \$500 transaction earns **1,500 points** (500 × 3x) * A \$3,000 transaction earns **15,000 points** (3000 × 5x) You can track your transaction history and points on the **Solayer Dashboard**. > *Note: Solayer Card Points will soon be redeemable for partner perks, future airdrops, and other exclusive utilities.*
## Solana ID-Based Benefits We've integrated **Solana ID** to offer **discounts and whitelisting** based on your onchain credit tier. ### Eligibility & Benefits | Solana ID Tier | Benefit Type | Details | | -------------- | ---------------- | ----------------------------------------------------------------------- | | Tier 1 or 2 | Fee Discount | Discounted membership fee — check the Solayer app for current pricing | | Tier 3 or 4 | Partial Discount | Partial membership discount — check the Solayer app for current pricing | Tier eligibility and discount amounts may be updated. Visit the Solayer app for the latest details. ### Who’s Eligible? To view your Solana ID tier and claim your benefits:\ **Visit [Solayer Pay](https://solayer.org/card) and connect your wallet.**
## Nubit Genesis Rewards We’ve partnered with [Nubit](https://x.com/nubit_org) to launch the Genesis Rewards program. Early participants can now claim: * **BTC rewards** * **PolyPass**, which unlocks: * Access to future airdrops * Whitelist spots for Bitcoin Thunderbolt * Additional partner benefits **Claim now at [app.solayer.org/card](https://app.solayer.org/card)** ### Who’s Eligible? You qualify for Genesis Rewards if you meet **either** of the following: * You’ve earned **50 or more Solayer Card Points** * You participated in the **Solayer Community Sale** ### About Nubit [Nubit](https://www.nubit.org/) is building **Bitcoin Thunderbolt**, a Bitcoin Boosting Network for native assets, trading, and verification. # Solayer Portfolio Source: https://docs.solayer.org/solayer-pay/portfolio ## **Overview** The global financial landscape is shifting away from **traditional banking** toward **bankless solutions and de-banking**, reflecting a demand for **transparency, accessibility, and financial inclusion**. Traditional banks impose **high fees, lack transparency, and limit financial access**, leaving millions underserved. **Solayer Portfolio** embraces this movement by using **blockchain technology** to eliminate reliance on centralized institutions. It empowers users with **direct control over their assets** and access to **decentralized financial opportunities**, aligning with the broader vision of **an open, transparent, and equitable financial ecosystem**.
## **What is Solayer Portfolio?** **Solayer Portfolio** is a **self-custodial, decentralized financial solution** designed to help users **earn on their stablecoins** while maintaining **full control** of their assets. Powered by **sUSD**, it simplifies **asset management, yield generation, and financial independence** without intermediaries. ### **Key Benefits** * **Self-Custody** – Full control over your funds with no reliance on banks or third parties. * **Transparency** – Real-time tracking of **interest rates, balances, and earnings**. * **Decentralized Yield** – Direct exposure to **tokenized real-world assets (RWA)** like **U.S. Treasury Bills**.
## **Features of Solayer Portfolio** ### **Unified Asset Management** * **Easily manage all your stablecoin balances** in a single dashboard. * Deposit **sUSD** to grow your wealth without switching between platforms. ### **Direct Access to RWA Yields** * Depositing **sUSD** gives users direct exposure to **tokenized real-world assets**, such as **U.S. Treasury Bills**. * Unlike traditional banks, **your earnings reflect the actual yield generated** by your funds—**no hidden intermediaries**. ### **Full Integration Across DeFi** * Use **Solayer Portfolio** to **allocate funds** across **various DeFi opportunities**. * Customize **your strategy to earn additional yield** while maintaining **full control of your assets**. ### **Real-Time Tracking & Insights** * Monitor your **yield, earnings, and savings goals** through a **full dashboard**. * Stay informed about **how your assets are growing over time**. ### **\[Coming Soon] Solayer Pay** * Access your **Solayer Pay** and spending history. * Spend directly from **Solayer Portfolio** while **accumulating rewards and perks**.
# Security Source: https://docs.solayer.org/solayer-pay/security A closer look at how Solayer designed Solayer Pay to offer real-time spending and enterprise-grade security. Real-time payments. On-chain rewards. Enterprise-grade security. The **Solayer Pay** was designed not just for convenience — but for trust. Behind every card swipe, there's a strong security architecture that separates operational speed from long-term safety. In this post, we’ll walk you through how your funds are protected every step of the way.
## Speed Meets Safety: Hot + Cold Wallet Design Modern finance requires speed. But crypto needs something more — **resilience**. That’s why Solayer uses a **hybrid wallet model**, combining the best of both worlds: * **Hot Wallets** for fast, real-time access * **Cold Wallets** for deep, offline security This separation is core to how Solayer Pay works — and why it’s built for scale.
## Real-Time Access with Hot Wallets Hot wallets are what make your Solayer Pay feel instant. Whenever you: * Swipe your card * Pay a merchant * Bridge assets cross-chain ...you're interacting with a **hot wallet layer** optimized for **speed and convenience**. These wallets are online, but they only store a **small operational balance** — just enough to keep your transactions smooth and fast. This means: * Faster checkout experiences * Isolated risk exposure * Zero compromise on performance
## Cold Storage for Core Asset Protection Behind the scenes, the majority of your assets live in **cold storage** — where security comes first. Cold wallets are: * **Completely offline** * **Protected by multi-signature** access controls * **Stored on hardware-separated systems** In practice, this means: * No internet access * No runtime exploits * No centralized point of failure Even in a worst-case scenario, your core holdings are safe.
## Designed for Risk Segmentation By splitting wallet responsibilities, Solayer limits risk at the architectural level. * **Critical assets** are never exposed to the internet * **Hot wallets** only interact with the active layer * **Cold storage** provides a fallback in extreme cases It’s a layered defense system — not reactive security, but **proactive design**.
## Built-In Layers of Protection Beyond the wallet architecture, Solayer Pay also integrates: * Multi-step signature verification * Real-time transaction monitoring * Circuit breakers that freeze suspicious activity * Regular cold wallet rotation and review These aren’t just features. They’re commitments. Every layer of the system is built with security at its core.
## Your Wallet is a System At the end of the day, your Solayer Pay isn’t just a payment method. It’s part of a broader, crypto-native financial system — one designed for **trustless environments**, **global users**, and **real-world scale**. Your assets aren’t just stored. They’re protected — by default, by design.
Ready to use crypto for real-world spending with real security? Solayer Pay is your gateway. # KYC Guide Source: https://docs.solayer.org/solayer-pay/tutorials/kyc A step-by-step guide to completing the KYC process to unlock and receive your Solayer Pay. # How to Complete KYC to Claim Your Solayer Pay To receive your **Solayer Pay** and unlock its features, you’ll need to complete a simple **KYC (Know Your Customer)** verification process.\ Follow the steps below to get verified and claim your card!
## Step 1: Start the KYC Process 1. Go to the **Solayer Card** page. 2. Click the **“Continue”** button to proceed with KYC. 3. You’ll be redirected to our verification partner, **Sumsub**. ## Step 2: Begin Verification with Sumsub 1. On the Sumsub screen, click **“Continue”** to begin the KYC process for **Solayer Labs**. 2. Make sure you’re using a **secure internet connection**. ## Step 3: Confirm Your Country of Residence 1. Select **“All countries except USA”** if you are **not** a U.S. resident. * ⚠️ If you are a U.S. resident, please select “United States of America”. 2. Click **“Continue”** to proceed. ## Step 4: Choose Your Device for Verification 1. You can complete the process on your current device or switch to your phone. 2. Click **“Continue on this device”** to proceed. ## Step 5: Enter Your Personal Information Fill in the following details: * Country * State * City * Address * Postal code * Occupation * Annual salary Once complete, click **“Continue.”** ## Step 6: Email Verification 1. Enter your **email address** to receive a verification code. 2. Click **“Send verification code.”** 3. Check your inbox and enter the code to verify your email. ## Step 7: Select Your Identity Document 1. Choose your document type from the list (e.g. **Passport**, **Driver’s License**, or **Aadhaar card**). 2. Select the **issuing country**. 3. Click **“Continue.”** ## Step 8: Upload Your Identity Document 1. Upload both the **front and back sides** of your ID. 2. Accepted formats: **JPG, PNG, HEIC, WEBP, PDF** (max 50MB). 3. Click **“Continue.”** ## Step 9: Face Verification 1. Prepare your **camera** for a quick **liveness check**. 2. Make sure your **face is clearly visible** and you’re **not wearing** hats, glasses, or masks. 3. Click **“Continue”** to start face verification. ## Step 10: KYC Complete Once verified, you’ll see the message:\ **“Your profile has been verified.”** Return to the **Solayer card page** to check your status and proceed with claiming your card. ## Step 11: Application Processing Time * After completing KYC, your application will take **3–5 business days** to process. * You will receive an **email notification** once your Solayer dashboard and card are ready.
*** ## Need Help? If you face any issues during the KYC process, reach out to the **[Solayer Discord Community](https://discord.gg/solayerlabs)** for support. # Registration Source: https://docs.solayer.org/solayer-pay/tutorials/register Step-by-step guide to register and activate your Solayer Pay within the app.
# How to Register Your Solayer Pay You can register your **Solayer Pay** directly within the Solayer app for easy access to your virtual card details and seamless integration with payment services. Follow the simple steps below to complete the card registration process in just a few minutes!
## Step 1: Go to the Card Tab Tap the **“Card”** tab located on the navigation bar.\ This will take you to the card registration page. ## Step 2: Tap “Pay & Activate” Tap the **“Pay & Activate”** button.\ A pop-up will appear showing the card activation fee. ## Step 3: Confirm Payment Tap the **“Activate Card”** button to proceed with payment. > 💡 If you participated in Solayer Pay Pre-Sale, the activation fee will be waived. > ⚠️ The activation fee is non-refundable. ## Step 4: Approve the Transaction Confirm the payment transaction using your wallet or preferred payment method. ## Step 5: Continue to KYC After completing the payment, tap **“Continue”** to begin the identity verification (**KYC**) process. ## Step 6: Complete the KYC Process Follow the on-screen instructions to verify your identity.\ Once verification is completed, your card registration will proceed. ## Step 7: Card Application in Process After KYC is approved, your **Solayer Pay** will be issued.\ You may briefly see a processing screen during this stage. ## Step 8: Welcome to Your Solayer Pay Once issued, your card will appear in the app.\ Tap **“Show Details”** to view your card number, expiration date, and CVV.
*** ## After Registering Your Card Once your card is activated and registered, you can: * Add it to **Apple Pay** or **Google Pay** * Use it for **online or in-store payments** * Track your transactions and manage spending directly within the **Solayer app**
*** ## Troubleshooting Card Registration If you encounter any issues during the process: * Ensure your **internet connection** is stable * Check if your **country or region is supported** * Make sure your **identity verification details are accurate** * If the process fails, **restart the app and try again**
*** ## Need Help? Contact Solayer Customer Support If you need assistance, join our **[Discord Community](https://discord.gg/solayerlabs)** for personalized support. # Top Up Source: https://docs.solayer.org/solayer-pay/tutorials/topup Learn how to deposit funds into your Solayer Pay using the Solayer app. # How to Top Up Your Solayer Pay You can easily deposit funds into your **Solayer Pay** to use it for **online** or **in-store purchases**.
## Step 1: Open the Solayer App * Connect your **wallet** to the **Solayer app**. * Go to the **Card** tab. ## Step 2: Tap “Deposit” * Tap the **“Deposit”** button under your card. ## Step 3: Enter Amount * Input the **amount** you want to top up. ## Step 4: Confirm and Approve * Tap **“Deposit”**, then **approve the transaction** via your wallet or chosen payment method. ## Step 5: Check Your Balance * Once the transaction is confirmed, your **updated balance** will appear on the card screen. > 💡 A small fee of **\$0.10** per top-up transaction is charged.
*** That’s it! You’re now ready to use your **Solayer Pay** for daily spending.\ If you encounter any issues, visit our **[Discord Community](https://discord.gg/solayerlabs)** for support. # Card Details Source: https://docs.solayer.org/solayer-pay/tutorials/usage A quick guide to accessing your Solayer Pay information within the Solayer app. # How to View Your Solayer Pay Details Once your **Solayer Pay** is activated, you can easily access your card information through the app for **online payments** and **wallet integration**.
## Step 1: Open the Solayer App * Connect your **wallet** to the **Solayer app**. * Go to the **Card** tab. ## Step 2: Tap “View Details” * Tap **“View Details”** under your card. * Your **card number**, **expiration date**, and **CVV** will be displayed. ## Step 3: Hide Details * To hide the card details, simply tap **“View Details”** again.
Once you’ve viewed your card details, you can easily **add your Solayer Pay to Apple Pay or Google Pay** for daily use. > Need help adding your card to a mobile wallet?\ > Check out: [Apple & Google Pay](/tutorials/add-to-apple-google-pay) # Delegate Tokens Source: https://docs.solayer.org/ssol/mega-validator/delegate-tokens Solayer provides decentralized applications (dApps) with a simple method to create their own AVS LST. These tokens come with Solana’s native SOL yield as their base rewards, along with additional MEV yields. Solayer optimizes the yield by delegating it to the highest yield-bearing validators. \ \ Additionally, Solayer runs its own validator implementation that supports app-level stake-weighted quality of service provisioning. The Solayer AVS Token is a delegated representation of sSOL, the Solayer-managed LST on Solana.\ \ In the future, we envision dApps having direct control over the validators to which the underlying SOL is delegated. They should also be able to configure the required stake-weighted quality of service with a dynamic pricing mechanism depending on the current network workload. ### Getting an AVS Token First, users convert SOL into sSOL and deposited SOL will be delegated to Solayer validators. They then delegate it to an endogenous dApp AVS on Solayer, which converts sSOL to a delegated form. Finally, Solayer AVS mints AVS tokens which can later be used as a stake proof to retrieve staked SOL back and claim rewards. ### General Flow of sSOL Users deposit their SOL into the native SOL pool and receive sSOL tokens in return. Depositors delegate their sSOL into the e-AVS (endogenous Actively Validated Services) pool and receive AVS wrapper SPL tokens. endoAVS directly receives the delegated sSOL into a vault, increasing the probability of block space provisioning and transaction inclusion for the dApp. endoAVS can reward and incentivize more delegates to enhance participation. # Mega Validator & endoAVS Source: https://docs.solayer.org/ssol/mega-validator/transaction-acceleration Solayer's Mega Validator architecture is uniquely designed to support on-chain decentralized applications (dApps), which we refer to as **endogenous Actively Validated Services (endoAVSs)**. Unlike traditional platforms that primarily focus on **exogenous AVSs** (such as oracles and bridges), Solayer enhances the capabilities of **native Solana dApps** by providing: * **Increased probability of securing block space** * **Prioritized transaction inclusion** This approach enables developers to build more **responsive** and **efficient** applications within the Solana ecosystem, leveraging Solayer's **stake-weighted quality of service (swQoS) mechanisms**.
## Mega Validator: Enhancing Solana's Validator Performance ### What is the Mega Validator? Solayer's **Mega Validator** is a specialized validation mechanism designed to **offload hardware signatures**, boosting **transaction throughput** and **reducing latency**. ### How It Works * **Hardware Signature Offloading** * By shifting cryptographic verification tasks away from standard validators, the Mega Validator **frees up processing power** for transaction execution. * **Enhanced Throughput & Lower Latency** * By reducing signature verification overhead, Solayer’s Mega Validator increases **network efficiency**, allowing more transactions to be processed per second. * **Integration with swQoS** * When combined with **Stake-weighted Quality of Service (swQoS)**, Mega Validator **prioritizes transactions dynamically**, ensuring **optimal resource allocation** based on stake.
## What is an AVS? Solayer introduces a novel approach in blockchain infrastructure: a system where **decentralized applications (dApps) dynamically allocate processing power** based on staked tokens. This **stake-weighted** model allows dApps to **influence network operations proportionally to their stake**, resulting in **faster and more reliable transactions**.
## Endogenous AVSs (Actively Validated Services) Solayer introduces **endogenous AVSs**, which are **native Solana dApps** that can: * Secure necessary **block space** * Prioritize transactions based on **delegated tokens** By leveraging Solayer’s **swQoS**, dApps gain **better control over their network performance**, leading to **superior user experiences**. Solayer AVS Diagram
## Technical Implementation: Stake-weighted Quality of Service (swQoS) The foundation of Solayer’s performance improvements lies in **Stake-weighted Quality of Service (swQoS)**, a mechanism that allows dApps to: * **Reserve blockchain space and processing power** * **Enhance network efficiency and reliability** For more details, refer to our [Stake Weighted Quality of Service](assets/mega-validator/transaction-acceleration/swQoS) documentation. By using **Solayer's Mega Validator and swQoS**, developers can build **high-performance Solana dApps** with superior **efficiency, responsiveness, and prioritization**. # Yield Optimization Source: https://docs.solayer.org/ssol/mega-validator/yield-optimization **Megavalidator** allows users to maximize their **staking returns** by using **hardware-accelerated infrastructure** and **MEV-optimized strategies**. Our approach ensures that **sSOL holders** receive the **highest possible yield** through specialized validator optimizations.
## **How Megavalidator Maximizes Returns** We optimize yield by implementing **several key mechanisms**, including: * **0% Commission** – Ensuring all staking rewards are fully distributed to sSOL holders. * **100% MEV Kickback** – Returning all MEV profits to the stake pool. * **Dedicated High-Performance Hardware** – Running validators on **custom-optimized machines** to maximize efficiency. * **Codebase Optimizations** – Enhancing **transaction processing and execution speed**.
## **Partnership with Paladin** To further optimize transaction processing and maximize priority fee revenue, we have partnered with **Paladin**, a **Jito fork**. This partnership allows us to: * **Capture More Transactions with Priority Fees** * Paladin helps our validator receive **higher-value transactions**, ensuring **better yield for sSOL holders**. * **Prevent Harmful MEV Practices** * Paladin detects and **filters out sandwich bundles**, protecting users from **predatory MEV behaviors**. While **bad MEV prevention is not directly related to yield**, it **improves network fairness and security**, contributing to a more **stable staking environment**.
## **Modified Solana Validator Client for Higher Yields** Our validator runs on a **custom-modified client**, which introduces several **yield-enhancing optimizations**: ### **1. Advanced Transaction Scheduler** * The scheduler is responsible for **selecting and ordering transactions** during a validator’s assigned block-building slot. * Our modified scheduler **prioritizes transactions with higher fees**, leading to **greater validator earnings**. **Background:**\ Validators take turns in **building blocks**. During their **assigned slot**, they must **fill the block** under size constraints while determining **the most profitable transaction order**. Our **optimized scheduler** ensures **maximum priority fee collection**. ### **2. Enhanced Broadcast System** * Our validator **broadcasts to a wider network of nodes**, ensuring: * **More votes** → Increased **validator rewards**. * **Faster transaction confirmation** → Improves **Solana network efficiency**. This **improved broadcast mechanism** allows us to **capture more staking rewards**, ultimately benefiting **sSOL holders**.
## **sSOL APY Calculation Methodology** sSOL APY is determined using **a least squares linear regression** on the **sSOL redemption rate over the last 4 epochs**. At each epoch: * The **sSOL-to-SOL ratio** in the **Solayer Stake Pool** is recorded. * The **gradient of the redemption rate change** is calculated to estimate **annualized returns**. This method provides **a transparent and accurate measurement** of **sSOL staking yields**. # Native Staking Source: https://docs.solayer.org/ssol/native-staking Overview of Solayer's validator infrastructure and native SOL staking support. Solayer operates one of the **high-performance Solana validators**, optimized with dedicated hardware and software improvements to maximize staking returns. ### Hardware-Level Optimizations * Located in a **key data center in Ashburn, VA**, near subsea fiber cables. * Equipped with **enterprise-grade hardware** ### Software-Level Optimizations * Optimized validator node code to **maximize leader block rewards**. * These rewards are **shared**, enhancing staking returns.
## Performance * **10+% APY** historical returns to the Solayer sSOL stake pool. * All stakers benefit from: * **0% commission** * **100% MEV kickback**
## Validator Details * **Vote Account:** `SLaYv7tCwetrFGbPCRnqpHswG5qqKino78EYpbGF7xY` * **Identity:** `SLAY6uN1zZpXBTfbuDDCesNmM5D288xrz8uYvfS3n41` * Listed on: * [Stakewiz](https://stakewiz.com) * [Solana Compass](https://solanacompass.com) * [SVT One](https://svt.one) * [Validators.app](https://validators.app) * [Solana Beach](https://solanabeach.io)
## Integration Guide Stake delegation is simple, whether you’re using CLI tools, code-based integration, or UI platforms. ### Method 1: Solana CLI ```bash theme={null} solana delegate-stake \ --stake-authority \ \ SLaYv7tCwetrFGbPCRnqpHswG5qqKino78EYpbGF7xY \ --fee-payer ``` * Replace `` and `` with your credentials * Full guide available via [Anza](https://docs.anza.xyz/cli/examples/delegate-stake) ### Method 2: JavaScript/TypeScript Use `@solana/web3.js` to create and delegate a stake account programmatically. A sample snippet is included in the full developer guide [here](https://docs.solana.com). ### Method 3: Web-Based UIs You can delegate directly from any of the following platforms: * [Solayer → Application main page](https://app.solayer.org) * [Stakewiz → Profile → Delegate](https://stakewiz.com) * [Solana Compass → Profile → Delegate](https://solanacompass.com) * [Solana Beach → Profile → Delegate](https://solanabeach.io)
If you’re an institutional partner interested in staking with Solayer, please [contact us](mailto:team@solayer.xyz) to discuss your setup, fee structure, and staking requirements. # Overview Source: https://docs.solayer.org/ssol/overview **sSOL** is a liquid staking token that represents deposited SOL on Solana. It lets users earn staking rewards while keeping their assets liquid for use in DeFi.
## **Why sSOL?** By converting **Native SOL and LST SOL to sSOL**, users can: * **Earn top-tier SOL APY from Mega Validator**—without locking up your assets. * **Use sSOL in DeFi**, maintaining liquidity while securing the network. * **Enhance dApp scalability** by delegating sSOL, contributing to **network bandwidth and transaction throughput**. * **Accelerate Solana transactions** with Mega Validator.
## **sSOL as a Universal Liquidity Layer** sSOL functions as a **universal liquidity layer** within Solayer, supporting: * **dApps** that require **blockspace and bandwidth allocation**. * **Liquidity Staking Tokens (LSTs)** that use sSOL liquidity for **efficient capital allocation**. Each unit of **sSOL represents a unit of blockspace**, contributing to network throughput for dApps.
## **How to use sSOL** sSOL holders can use their tokens through multiple apps: ### **1. Delegation to endoAVS** * Users can **delegate sSOL to endoAVS** to help secure **network bandwidth**. * This process supports **scalability and dApp efficiency** while allowing users to **retain asset flexibility**. ### **2. Participation in DeFi Strategies** * sSOL holders can **use DeFi protocols** to earn additional **APY**. * Common strategies include: * **Providing liquidity** in **DEX AMM pools** to earn **trading fees**. * **Depositing in liquidity vaults** to optimize yield and automate liquidity management.
sSOL combines staking yield, DeFi integration, and dApp delegation in a single asset. It improves capital efficiency and liquidity for stakers, DeFi participants, and developers building on Solayer. # Staking Source: https://docs.solayer.org/ssol/tutorials/stake A step-by-step guide to staking SOL into sSOL on Solayer and earning rewards through high-performance validators. # How to Stake sSOL on Solayer Solayer offers a high-performance staking experience powered by optimized hardware, MEV rewards, and AVS incentives. This guide walks you through the full process of staking SOL to receive sSOL, a yield-bearing representation of your stake.
## Step 1: Connect Your Wallet Visit [https://app.solayer.org](https://app.solayer.org) and connect your wallet using the button at the top right corner. Solayer supports wallets such as **Solflare**, **Phantom**, and others that are compatible with the Solana network. *** ## Step 2: Enter the Amount of SOL to Stake Ensure the `sSOL` tab is selected. Enter the amount of SOL you wish to stake.\ You will see the current exchange rate below the input field (e.g., `1 sSOL = 1.0684 SOL`).\ Once a valid amount is entered, the **Stake** button will become active. *** ## Step 3: Approve the Transaction Your wallet will prompt a confirmation window.\ Review the transaction details, including: * Amount of SOL to be staked * Expected sSOL to receive * Network fee (e.g., `0.00041 SOL`) Click **Approve** to proceed. *** ## Step 4: Transaction Pending Once approved, a pending status will appear on the Solayer interface as the transaction is processed on the Solana network.\ This typically completes within a few seconds. *** ## Step 5: Staking Complete After confirmation, you will see a **Transaction successful** message.\ Your staked SOL will now appear as **sSOL** in your wallet. You are now earning staking rewards through Solayer's validator infrastructure. *** ## Summary By staking SOL to sSOL on Solayer, you are participating in a secure, performance-optimized staking protocol with competitive APYs.\ To explore more features like unstaking, sUSD minting, or advanced delegation, visit our platform at [app.solayer.org](https://app.solayer.org). For further questions, reach out via the [Solayer Discord Support Channel](https://discord.gg/solayerlabs). # Unstaking Source: https://docs.solayer.org/ssol/tutorials/unstake A step-by-step guide to unstaking sSOL and withdrawing your SOL from Solayer. # How to Unstake sSOL on Solayer Solayer allows users to unstake sSOL and redeem their SOL through a secure and seamless process. This guide walks you through how to initiate unstaking, deactivate your stake, and withdraw your SOL once it becomes available. *** ## Step 1: Go to the Unstake Tab Navigate to [https://app.solayer.org](https://app.solayer.org) and connect your wallet.\ Then click the **Unstake** tab under the sSOL section. *** ## Step 2: Enter the Amount of sSOL to Unstake Enter the amount of `sSOL` you want to unstake.\ You will see the equivalent SOL value based on the current exchange rate. Click **Unstake**. *** ## Step 3: Approve the Transaction in Your Wallet Your wallet will display the transaction details. Review and confirm them, including: * The amount of `sSOL` being burned * The amount of SOL being transferred * The validator account receiving the funds * The network fee Click **Approve** to proceed. *** ## Step 4: Transaction Confirmation After confirming the transaction, you will see a **Transaction successful** message at the top right of the screen. *** ## Step 5: Deactivate Your Stake Next, you need to deactivate your stake. This begins a cooldown period that typically lasts until the next Solana epoch (up to 2 days).\ Click **Deactivate** when prompted. *** ## Step 6: Pending Transactions View You can monitor the progress of your unstaking in the **Pending transactions** section.\ This area displays which stakes are deactivating and which are ready to withdraw. *** ## Step 7: Withdraw After Deactivation Completes Once the cooldown period has passed, the **Withdraw** button will appear next to your entry. Click it to receive your SOL. *** ## Step 8: Withdrawal Confirmation After withdrawing, you'll see a confirmation that your SOL has been successfully returned to your wallet. *** ## Summary Unstaking sSOL from Solayer involves a few steps: initiating unstake, deactivating stake, waiting for the next epoch, and finally withdrawing your SOL.\ This ensures the process remains secure and compliant with the Solana staking protocol. For questions or support, reach out via the [Solayer Discord Support Channel](https://discord.gg/solayerlabs). # Universal Liquidity Layer Source: https://docs.solayer.org/ssol/universal-liquidity-layer Liquidity is the most important factor for the adoption of any asset. Conversion delay and slippage are two key considerations. In an ideal world, there would be no slippage and instant conversion, so all Solana users should hold yield-bearing LSTs instead of SOL. What prevents this from happening is the liquidity of such LSTs. Each LST needs to have a deep pool with low swap fees and a significant amount of trading volume to offset LP's capital costs. Liquidity To address this problem, Solayer introduces Superior Liquidity for AVS Tokens using a pooled liquidity design. Solayer AVS Tokens can be instantly unwrapped (or undelegated) back to the underlying representation, sSOL. Unlike others that use a multi-LST pool, where the liquidity for each LST depends on their LP pools (a less efficient design), Solayer consolidates all liquidity for Solayer AVS Tokens using the sSOL-SOL pair. This strategy results in significantly smaller price impact and significantly improved liquidity. # RFQ Overview Source: https://docs.solayer.org/susd/decentralized-rfq-protocol/overview The sUSD pool is designed to simplify how users earn yields from T-Bills by providing an on-chain, non-custodial request-for-quote (RFQ) system. Instead of juggling multiple platforms and providers, users can access a variety of real-world asset providers through a single interface. This approach not only distributes risk but also maximizes yield opportunities by taking advantage of the strengths of different providers. We will also continue to add new RWA partners with time. Solayer sUSD open RFQ protocol
## **Subscription Process:** sUSD Subscription Process The user locks USDC to initiate a transaction. This action creates a quote that specifies the amount of USDC, the expiry time, and the commission rate for the trade. The qualified liquidity provider fulfills the buy order by transferring the USDC out and sending back a wrapped T-Bill (tokenized representation of a T-Bill) as proof. The decentralized T-Bill RFQ (Request for Quote) protocol forwards it to the sUSD minting program, locking it there in the process. The Solayer sUSD Program mints sUSD based on the value of the wrapped T-Bill, maintaining a 1:1 price peg with USDC. The user can delegate sUSD to secure our exogenous AVSs (exoAVSs) when it goes live.
## **Redemption Process:** sUSD Redemption Process The user sends back sUSD to the Solayer sUSD Program to initiate the withdrawal process. This action signals the start of the withdrawal procedure. The Solayer sUSD Program calculates the corresponding amount of wrapped T-Bill that needs to be redeemed based on the user's withdrawal request. The wrapped T-Bill is then forwarded to the Decentralized T-Bill RFQ Protocol. The Qualified Liquidity Provider receives the wrapped T-Bill and fulfills the withdrawal order. This involves transferring out the wrapped T-Bill and sending the equivalent amount of USDC back to the protocol. After the liquidity provider fulfills the withdrawal order, the decentralized protocol returns the corresponding amount of USDC to the user, completing the withdrawal process. # Process Source: https://docs.solayer.org/susd/decentralized-rfq-protocol/process ## **Subscription Process:** sUSD Subscription Process The user locks USDC to initiate a transaction. This action creates a quote that specifies the amount of USDC, the expiry time, and the commission rate for the trade. The qualified liquidity provider fulfills the buy order by transferring the USDC out and sending back a wrapped T-Bill (tokenized representation of a T-Bill) as proof. The decentralized T-Bill RFQ (Request for Quote) protocol forwards it to the sUSD minting program, locking it there in the process. The Solayer sUSD Program mints sUSD based on the value of the wrapped T-Bill, maintaining a 1:1 price peg with USDC. The user can delegate sUSD to secure our exogenous AVSs (exoAVSs) when it goes live. ## **Redemption Process:** sUSD Redemption Process The user sends back sUSD to the Solayer sUSD Program to initiate the withdrawal process. This action signals the start of the withdrawal procedure. The Solayer sUSD Program calculates the corresponding amount of wrapped T-Bill that needs to be redeemed based on the user's withdrawal request. The wrapped T-Bill is then forwarded to the Decentralized T-Bill RFQ Protocol. The Qualified Liquidity Provider receives the wrapped T-Bill and fulfills the withdrawal order. This involves transferring out the wrapped T-Bill and sending the equivalent amount of USDC back to the protocol. After the liquidity provider fulfills the withdrawal order, the decentralized protocol returns the corresponding amount of USDC to the user, completing the withdrawal process. # RFQ Stakeholders Source: https://docs.solayer.org/susd/decentralized-rfq-protocol/stakeholders ## Users (Stablecoin Depositors) Stablecoin depositors are the primary participants of the protocol.\ They lock USDC to mint **sUSD**, delegate sUSD to **Exogenous AVSs (exoAVSs)** to secure external systems, and redeem their assets when necessary. * **Minting sUSD:** Users deposit USDC and receive sUSD, optionally setting a commission rate (e.g., 1 basis point) when creating an order. * **Commission Allocation:** The specified commission is pooled in the decentralized RFQ system to reward Qualified Liquidity Providers (QLPs) that fulfill orders. *** ## Qualified Liquidity Providers (QLPs, Market Makers) QLPs provide liquidity within the RFQ system by subscribing to **cUSDO**, a tokenized representation of short-dated U.S. Treasury Bills issued on Solana.\ By depositing USDC into the **cUSDO Vault**, QLPs receive cUSDO tokens which they self-custody and later redeem for USDC when processing withdrawals. * **Order Fulfillment Process:** 1. QLPs receive USDC from users through the RFQ protocol. 2. The received USDC is deposited into the cUSDO vault to mint **cUSDO**. 3. QLPs hold cUSDO in self-custody and redeem it for USDC when fulfilling user withdrawals. *** ## Underlying Issuance Structure The cUSDO token is part of a regulated tokenized Treasury framework operated by OpenEden.\ It replaces the previous TBILL token, maintaining equivalent backing and operational logic. | Stakeholder | Description | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Token Issuer** | **OpenEden Digital Ltd**, a Bermuda-licensed digital asset business regulated by the **Bermuda Monetary Authority (BMA)**, issues the cUSDO token fully backed by U.S. Treasury Bills. | | **Investment Manager** | **Adam Eve Capital**, regulated by the **Monetary Authority of Singapore (MAS)**, manages the underlying U.S. Treasury Bill investments in segregated custodial accounts. | | **Fintech Service Provider** | **OpenEden Labs Pte. Ltd.**, responsible for operating the technical vault infrastructure used in the cUSDO issuance process. | *** ## Transition Note As of **2 November 2025**, all TBILL tokens previously held in Solana vaults have been **upgraded to cUSDO**.\ All subsequent RFQ transactions and QLP operations are executed exclusively in **cUSDO**, ensuring uninterrupted functionality and consistent 1:1 USD collateralization. *** # Eligibility & Risks Source: https://docs.solayer.org/susd/protocol-info/eligibility&risks ## Eligibility To be eligible to gain, redeem, or trade sUSD, you must NOT be located, organized, or a resident in any of the following locations: * US * Cuba * Iran * North Korea * South Korea * Syria Citizenship Restrictions: * Citizens of the above-listed countries (except the U.S.) are ineligible, regardless of their place of residence. For example, a Cuban citizen is ineligible even if living outside Cuba, whereas a U.S. citizen living in France would be eligible. ## Risk Using sUSD offers significant benefits, but it’s important to understand the potential risks involved. Assessing these risks helps ensure informed decision-making and a better understanding of how sUSD operates within the broader financial ecosystem. For a comprehensive overview of these risks, please refer to [our partner's risk documentation](https://docs.openeden.com/treasury-bills-vault/risks). # FAQs Source: https://docs.solayer.org/susd/protocol-info/faqs sUSD is the first yield-bearing stablecoin on Solana. It is designed to offer a steady 4-5% yield through T-bill investments ([see associated risks](https://docs.openeden.com/treasury-bills-vault/risks)) while also being used to secure exogenous Actively Validated Services (exoAVSs) on Solayer. sUSD is inherently yield-bearing, generating a 4-5% yield from T-bills. Exogenous AVSs (Actively Validated Services) are modular systems that run in parallel to Solana, such as oracles, bridges, and rollups. Users can delegate sUSD to help secure these systems and provide them with crypto-economic security. To mint sUSD, a user locks USDC into the system, which creates a quote. This quote specifies the USDC amount, expiry time, and commission rate. A qualified liquidity provider then fulfills the buy order by transferring out the USDC and sending back a wrapped T-Bill as proof. Based on the wrapped T-Bill, the Solayer sUSD Program mints sUSD, which remains pegged 1:1 with USD. To withdraw, the user sends sUSD to initiate the process. The protocol calculates and sends the corresponding wrapped T-Bill to the qualified liquidity provider, who then fulfills the withdrawal by transferring the USDC back to the user. sUSD is a yield-bearing stablecoin, offering users a T-bill-backed yield, unlike traditional stablecoins. Additionally, it can be used to secure AVS systems on Solayer, providing a dual utility of earning yield and supporting decentralized infrastructure. sUSD maintains its 1:1 USD peg by using the **Token 2022 interest-bearing extension** design. This ensures that even while it generates yield, it remains pegged to the USD. Anyone holding USDC can participate in the sUSD ecosystem by minting sUSD and earning yield, and using sUSD to secure AVS systems. Additionally, institutional participants can contribute by becoming **qualified liquidity providers**. After the launch of sUSD, we aim to extend its utility across every use case, from supporting the on-chain economy to securing the future of all decentralized systems. This includes expanding the reach and functionality of exogenous AVSs and potentially supporting other decentralized services. # sUSD litepaper & Audits Source: https://docs.solayer.org/susd/protocol-info/litepaper ## Solayer USD: Yield-bearing Real World Assets Backed Synthetic Stablecoin Here you can access the [sUSD litepaper](https://github.com/SolayerDev/solayer_docs/blob/main/susd/sUSD-litepaper.pdf), which provides detailed information about sUSD and its unique features. ## Abstract This paper introduces Solayer USD (sUSD), a dollar-pegged stablecoin backed by a basket of low risk profiled real world assets (RWAs), such as U.S. Treasury Bills, Bond, Gold etc, offering a secure 4-5% annual yield to holders through T-Bill-backed interest accrual initially. Utilizing Solana’s Token2022 extension [\[Sol24\]](https://spl.solana.com/token-2022/extensions), sUSD’s protocol adjusts balance multipliers instead of token amounts, allowing holders to realize yield growth. Additionally, through a decentralized request-for-quote (RFQ) protocol, users’ assets are diversified into various liquidity providers through matching engines, simplifying subscriptions and redemptions. Beyond basic yield through RWAs, sUSD can be delegated to modular AVSs, enabling holders to participate in the security of decentralized systems while earning additional returns. A focus on transparency, on-chain verifiability, and rigorous security measures ensures that sUSD maintains stability, security, and a reliable peg. Through Solayer USD, the Solana ecosystem advances toward a decentralized, on-chain economy that expands stablecoin utility and liquidity. ## Audits Contract security is core to Solayer’s long-haul commitment to building secure and scalable crypto-economic infrastructure. Here is the latest audits for the sUSD program: 1. [Halborn - sUSD](https://raw.githubusercontent.com/solayer-labs/solayer-improvement-proposal/main/audits/stablecoin/Halborn-audit-report-susd-program.pdf): October, 2024 Despite having thorough security reviews, we encourage community members, technical hackers, and researchers to thoroughly review the contracts, and report to `report@solayer.org`, or via proper channels if any bugs have been identified. # Oracle & Price Feeds Source: https://docs.solayer.org/susd/protocol-info/oracle&price_feeds Data sources for sUSD ## API Overview The sUSD Price API provides real-time redemption price data for sUSD, fetched via [Switchboard](https://switchboard.xyz). This oracle-based data feed calculates the sUSD redemption price relative to the TBill exchange rate, ensuring that external platforms can access accurate, up-to-date pricing information. ## Base URL All requests to the sUSD Price API should be made via the [Switchboard Redemption Price Feed](https://ondemand.switchboard.xyz/solana/mainnet/feed/DtoFRRd3ZQX6dDgt1fJaesgtNCr4XAPSqMkMMMXsNnzC): The API is accessed via a **GET** request to the Switchboard feed URL: ``` https://ondemand.switchboard.xyz/solana/mainnet/feed/DtoFRRd3ZQX6dDgt1fJaesgtNCr4XAPSqMkMMMXsNnzC ``` This feed is maintained on Solana’s mainnet. ## Response Upon successful request, the feed will return a JSON response of the latest available sUSD redemption price along with associated metadata: * **price:** The current redemption price of sUSD based on the TBill exchange rate. * **timestamp:** The date and time (in UTC) when the price was last updated. * **source:** The data source, which is “Switchboard.” * **exchange\_rate:** The sUSD/TBill exchange rate used for the redemption price. * **authority:** The authority responsible for the feed on Solana. * **feed\_address:** Address of the feed on Solana’s mainnet. ## Additional Information * **Feed Name:** sUSD Redemption Price * **Feed Address:** DtoFRRd3ZQX6dDgt1fJaesgtNCr4XAPSqMkMMMXsNnzC * **Authority:** 7xAdgHMXqxErMQi5uGPWdCZcDR9E34bLputsbUbA29Rr * **Feed Hash:** 0xb4ebdfe76964ac2c20c3cb6e708c4132d648a4c719054016b30a992a4b546591 * **IPFS CID:** bafkreifu5pp6o2levqwcbq6lnzyiyqjs2zekjryzavabnmyktevewvdfse * **Maximum Variance:** 5% * **Minimum Job Responses:** 1 job(s) * **Minimum Sample Size:** 3 samples * **Maximum Staleness:** 150 slots # Transparency & Security Source: https://docs.solayer.org/susd/protocol-info/transparency&security The technical implementation of sUSD ensures both transparency and security at every stage of the process. A dedicated Solana program facilitates transactions, while each market maker has a Program Derived Account (PDA) that securely holds their TBILL balance, ensuring proper management of transactions and assets. Blockchain transparency is maintained as all transactions and TBILL holdings are recorded on the Solana blockchain, providing an immutable and transparent ledger for participants. This ensures that every movement of assets can be traced, contributing to system integrity. In terms of Asset Security, market maker vaults (PDAs) provide secure, isolated environments for holding assets, reducing the risk of unauthorized access or mismanagement. The decentralized nature of the RFQ system further enhances security and transparency by promoting fair pricing and minimizing the risk of market manipulation, allowing participants to operate within a trustless and equitable environment. # Cross Chain Deposit Source: https://docs.solayer.org/susd/tutorials/cross-chain A step-by-step guide to bridging assets like USDC or USDT from Ethereum to Solana using Solayer’s cross-chain deposit feature powered by Wormhole and Mayan. # How to Deposit to Solayer Using Cross-Chain Transfer Solayer supports secure cross-chain deposits powered by **Wormhole** and **Mayan**, allowing users to bridge USDC or USDT from Ethereum to Solana in a few steps.\ This guide will walk you through the entire process using the Mayan integration built into the Solayer app. *** ## step 1: Go to the Cross-Chain Section Visit [https://app.solayer.org](https://app.solayer.org) and click on the **Cross-chain** button under the sUSD section. *** ## step 2: Open Cross-Chain Deposit Panel This will launch the **Mayan-powered cross-chain interface**. Choose the network you’re sending from (e.g., Ethereum). *** ## step 3: Select Destination Wallet Click **Select Destination Wallet** to proceed to choose your receiving Solana wallet (e.g., Phantom). *** ## step 4: Connect Ethereum Wallet (MetaMask) Choose your Ethereum wallet (e.g., MetaMask), and approve the connection request. *** ## step 5: Select Token and Amount Select the token you want to bridge (e.g., USDT), input the amount, and confirm destination is set to Solana.\ You will see an estimated amount in USDC after the bridge and fee deductions. *** ## step 6: Approve Allowance in Wallet You will be prompted to approve token allowance in MetaMask. Confirm the transaction. *** ## step 7: Click Deposit Once approval is complete, the **Deposit** button will activate. Click it to proceed with the actual cross-chain transfer. *** ## step 8: Confirm Deposit Summary Review the effective input, expected deposit amount, relayer fee, and destination wallet address.\ Then click **Confirm Deposit**. *** ## step 9: MetaMask Transaction Approval MetaMask will ask you to confirm the actual transfer. This includes gas fees and execution details. *** ## step 10: Transaction Submitted Once submitted, you’ll see a confirmation modal.\ You can view the transaction in the **Mayan explorer**. *** ## Summary You’ve successfully completed a cross-chain deposit from Ethereum to Solana using the Solayer app.\ Deposits typically arrive within a few minutes depending on network congestion. You can monitor progress through the Mayan explorer or directly in your Solana wallet. For support or questions, reach out via the [Solayer Discord Support Channel](https://discord.gg/solayerlabs). # Deposit Source: https://docs.solayer.org/susd/tutorials/deposit A step-by-step guide to depositing USDC and minting yield-bearing sUSD on the Solayer platform. # How to Deposit USDC for sUSD on Solayer Solayer allows users to deposit USDC and receive sUSD, a decentralized yield-bearing stablecoin. This guide explains how to deposit USDC, approve the transaction, and track its completion. *** ## Step 1: Select the sUSD Tab and Click Deposit Go to [https://app.solayer.org](https://app.solayer.org), connect your wallet, and select the **sUSD** tab.\ Ensure you are on the **Deposit** sub-tab, not Withdraw. *** ## Step 2: Enter the Amount of USDC to Deposit Enter the amount of `USDC` you want to deposit.\ You will see the exchange rate displayed as `1 sUSD = 1 USDC`. Click **Deposit** to continue. *** ## Step 3: Review and Confirm the Deposit Process A confirmation modal will appear, explaining that the deposit process may take up to **2 business days** (T+1 excluding weekends).\ Click **Confirm Deposit** to proceed. *** ## Step 4: Approve the Wallet Transaction Your wallet will prompt you to approve the transaction.\ You will see the deduction of your USDC and a small network fee in SOL. Confirm the transaction by clicking **Approve**. *** ## Step 5: Deposit is Processing Once confirmed, you will see a **Pending** status at the top right. The transaction is now being processed in the background. *** ## Step 6: Deposit Complete Once the deposit process is complete, a **Transaction successful** message will appear.\ You can now view your newly minted sUSD in your wallet. *** ## Summary Depositing USDC into Solayer lets you mint sUSD, a yield-bearing stablecoin backed by tokenized U.S. Treasury Bills.\ You’ll begin earning returns immediately after deposit, and your assets remain composable across the Solana ecosystem. For additional support, please contact us via the [Solayer Discord Support Channel](https://discord.gg/solayerlabs). # Withdraw Source: https://docs.solayer.org/susd/tutorials/withdraw A step-by-step guide to withdrawing sUSD and receiving USDC to your Solana wallet using the Solayer app. # How to Withdraw sUSD from Solayer Solayer enables users to withdraw their sUSD and redeem it as USDC directly to their wallet.\ This tutorial covers the full withdrawal process, including timing, pending status, and how the protocol handles redemption securely via off-chain partners. *** ## step 1: Go to the sUSD Withdraw Tab Navigate to [https://app.solayer.org](https://app.solayer.org), go to the **sUSD** section, and select the **Withdraw** tab. *** ## step 2: Enter Amount of sUSD to Withdraw Input the amount of sUSD you want to withdraw. You’ll see your wallet balance and estimated USDC equivalent. *** ## step 3: Click Withdraw After entering the amount, click the **Withdraw** button to proceed. *** ## step 4: Confirm Withdraw Transaction A modal will explain the withdrawal timeline: * Up to 2 business days (T+1) to process via Solayer’s partners * You’ll be able to claim USDC once processed Click **Confirm Withdraw** to proceed. *** ## step 5: Approve in Wallet Your connected wallet (e.g., Solflare or Phantom) will request transaction approval.\ This includes sUSD burn and associated network fee. Click **Approve**. *** ## step 6: Withdrawal Pending Once submitted, a **pending** message will appear at the top right.\ You can track the progress in the **Pending transactions** section. *** ## step 7: View Pending Transactions In the pending list, you'll see sUSD with a `Settling` or `Processing` status.\ Once the backend process is complete, it will be available for claim as USDC. *** ## step 8: Withdrawal Complete Once successful, you’ll see a transaction confirmation message like **"Withdraw sUSD – Transaction successful"**. *** ## Summary Withdrawing sUSD from Solayer is a simple process that converts your on-chain stablecoin into USDC through a secure redemption process.\ While the operation may take up to **2 business days (T+1)**, you can always monitor progress in real-time. Need help? Visit the [Solayer Discord Support Channel](https://discord.gg/solayerlabs). # sUSD Features Source: https://docs.solayer.org/susd/yield-bearing-stablecoin/susd-features sUSD is uniquely positioned as a yield-bearing, T-bill-backed stablecoin on Solana, with applications as a payment method, trading asset, collateral asset, and more. 1. The first T-bill yield-bearing stablecoin on Solana 2. The first widely adopted implementation of Token 2022, bringing interest-bearing assets on-chain 3. Our RWA partner has the only tokenized U.S. Treasury product with an “A” rating from Moody’s, placing it in the "investment-grade" quality category by one of the leading global providers of credit ratings, research, and risk analysis. sUSD will also play a crucial role in securing Actively Validated Services (AVSs), because of its stable foundational value together with its reliable and open architecture: ## sUSD Value Propositions 1. **Inherently Yield-Bearing:** sUSD offers a 4-5% yield backed by the T-bill, providing a steady fundamental yield layer for users while they hold or use sUSD. This makes it a more attractive option compared to traditional stablecoins like USDC or USDT. 2. **Securing External Systems:** sUSD can be delegated to secure exogenous AVSs (exoAVSs), which are modular systems running in parallel to Solana. Through this process, sUSD depositors can earn intrinsic T-bill-backed yield while gaining exposure to additional returns by contributing to the security of modular systems such as oracles, bridges, network extensions, rollups etc. 3. **DeFi Integrations:** sUSD will be liquid from day one, thanks to deep integrations with DeFi protocols on Solana. Ultimately, we envision sUSD becoming the on-chain liquidity layer, bridging fiat systems to the on-chain economy. This will also serve to attract more new users to Solana as supporting yield-bearing assets like sUSD can draw in new users who are looking for ways to optimize their capital efficiency and boost their yield without taking on extra risk. This serves a hybrid audience of both DeFi-native users looking for additional yield, as well as conservative investors and users seeking stable, low-risk yield. Finally this would also lower risk for borrowers as sUSD maintains a stable value. This allows DeFi protocols to offer more favorable borrowing conditions and lower interest rates when sUSD is used as collateral, as the risk of liquidation due to price volatility is reduced. *** For key protocol participants: 1. **For Users:** Access to a yield-bearing stablecoin with competitive exchange rates. 2. **For Market Makers:** Opportunity to earn commissions by providing liquidity. 3. **For the Ecosystem:** Enhanced liquidity and price discovery through decentralized competition. # What is sUSD? Source: https://docs.solayer.org/susd/yield-bearing-stablecoin/what-is-susd With the Solana stablecoin market cap standing at \$3.5B+, and over \$2B in stablecoin assets flowing into Solana from other ecosystems in just the past year, we see tremendous growth potential - Building utility around stablecoins holds immense promise. Solana’s stablecoin ecosystem is growing rapidly, attracting new assets and demonstrating strong confidence in its infrastructure. To build on this momentum, we’ve created sUSD — a yield-bearing stablecoin designed to enhance utility within the Solana network.
## About sUSD sUSD is the **first ever yield-bearing stablecoin on Solana** that is pegged to the U.S. dollar and backed by U.S. Treasury Bills (T-bills). This ensures that sUSD maintains a 1:1 peg with the U.S. dollar while simultaneously generating a 4-5% yield through T-bills, one of the safest short-term government debt instruments. By serving as a reference implementation for the **token 2022 interest-bearing extension**, sUSD reinforces the stability of its 1:1 USD peg. The sUSD pool makes yield generation more accessible and efficient for the stablecoin ecosystem. Given the constraint of Solana's account model, we can't mint tokens easily to all holders. So the interest bearing extension works in the way that it changes the "multiplier" of the holding amount with interest accumulation rather than changing the amount. The token amount is then calculated by multiplying the scale with the actual holding amount. This allows the amount of sUSD in a wallet to increase natively, much like the balance in a bank account grows with interest. The interest on sUSD is distributed through automatic balance updates, allowing users to accumulate an annual yield of approximately 4-5% based on T-bill yield simply by holding sUSD.
## sUSD Features sUSD is uniquely positioned as a yield-bearing, T-bill-backed stablecoin on Solana, with applications as a payment method, trading asset, collateral asset, and more. 1. The first T-bill yield-bearing stablecoin on Solana 2. The first widely adopted implementation of Token 2022, bringing interest-bearing assets on-chain 3. Our RWA partner has the only tokenized U.S. Treasury product with an “A” rating from Moody’s, placing it in the "investment-grade" quality category by one of the leading global providers of credit ratings, research, and risk analysis. sUSD will also play a crucial role in securing Actively Validated Services (AVSs), because of its stable foundational value together with its reliable and open architecture:
## sUSD Value Propositions 1. **Inherently Yield-Bearing:** sUSD offers a 4-5% yield backed by the T-bill, providing a steady fundamental yield layer for users while they hold or use sUSD. This makes it a more attractive option compared to traditional stablecoins like USDC or USDT. 2. **Securing External Systems:** sUSD can be delegated to secure exogenous AVSs (exoAVSs), which are modular systems running in parallel to Solana. Through this process, sUSD depositors can earn intrinsic T-bill-backed yield while gaining exposure to additional returns by contributing to the security of modular systems such as oracles, bridges, network extensions, rollups etc. 3. **DeFi Integrations:** sUSD will be liquid from day one, thanks to deep integrations with DeFi protocols on Solana. Ultimately, we envision sUSD becoming the on-chain liquidity layer, bridging fiat systems to the on-chain economy. This will also serve to attract more new users to Solana as supporting yield-bearing assets like sUSD can draw in new users who are looking for ways to optimize their capital efficiency and boost their yield without taking on extra risk. This serves a hybrid audience of both DeFi-native users looking for additional yield, as well as conservative investors and users seeking stable, low-risk yield. Finally this would also lower risk for borrowers as sUSD maintains a stable value. This allows DeFi protocols to offer more favorable borrowing conditions and lower interest rates when sUSD is used as collateral, as the risk of liquidation due to price volatility is reduced.
For key protocol participants: 1. **For Users:** Access to a yield-bearing stablecoin with competitive exchange rates. 2. **For Market Makers:** Opportunity to earn commissions by providing liquidity. 3. **For the Ecosystem:** Enhanced liquidity and price discovery through decentralized competition.
## sUSD Token Info To ensure transparency and verifiability for developers, integrators, and users, here are the key on-chain details of sUSD: | Field | Value | | -------------------- | ------------------------------------------------------------------------------ | | **Token Address** | `susdabGDNbhrnCa6ncrYo81u4s9GM8ecK2UwMyZiq4X` | | **Owner Program** | Token 2022 Program `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | | **Token Name** | Solayer USD (sUSD) | | **Decimals** | 6 | | **Authority** | Solayer (sUSD) Vault Authority `FhVcYNEe58SMtxpZGnTu2kpYJrTu2vwCZDGpPLqbd2yG` | | **First Mint Date** | October 6, 2024, 14:46:33 UTC | | **Interest Bearing** | Yes — powered by Token 2022’s interest-bearing extension |