Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

ShinobiCashEntrypoint

The central orchestrator for cross-chain operations on the pool chain (Arbitrum Sepolia).

Overview

ShinobiCashEntrypoint inherits from:

  • Entrypoint (privacy-pools-core)
  • ShinobiCashCrosschainState (cross-chain configuration)
  • IShinobiCashCrossChainHandler (handler interface)

It coordinates all cross-chain deposits and withdrawals, manages settler addresses, and handles refunds for failed intents.

State Variables

// Settler addresses
address public withdrawalInputSettler;    // For withdrawal intents
address public depositOutputSettler;       // For deposit fills
 
// Per-chain destination configuration
mapping(uint256 => WithdrawalChainConfig) public withdrawalChainConfig;
 
// Precommitment replay prevention
mapping(uint256 => bool) public usedPrecommitments;

WithdrawalChainConfig

Configuration for each supported destination chain:

struct WithdrawalChainConfig {
    bool isConfigured;              // Whether this destination is active
    uint32 fillDeadline;            // Default fill deadline (seconds from now)
    uint32 expiry;                  // Default expiry (seconds from now)
    address withdrawalOutputSettler; // ShinobiWithdrawalOutputSettler on destination
    address withdrawalFillOracle;    // Output oracle on destination chain
    address fillOracle;              // Fill oracle for validating fills (dest → origin)
}

Key Functions

crosschainWithdrawal

Main entry point for cross-chain withdrawals. Validates the ZK proof and creates an OIF intent.

function crosschainWithdrawal(
    IPrivacyPool.Withdrawal calldata _withdrawal,
    CrossChainProofLib.CrossChainWithdrawProof calldata _proof,
    uint256 _scope
) external nonReentrant
Flow:
  1. Validate withdrawalInputSettler is configured
  2. Validate withdrawn amount > 0
  3. Validate processooor is this entrypoint
  4. Fetch pool by scope, validate exists
  5. Decode CrossChainRelayData from withdrawal.data
  6. Validate destination chain is configured
  7. Validate relay fee ≤ max allowed
  8. Execute pool.crosschainWithdraw() (validates ZK proof)
  9. Calculate fees (relay + solver)
  10. Create OIF intent with configured destination settings
  11. Transfer relay fee to feeRecipient
  12. Open intent on ShinobiInputSettler (escrows funds)
  13. Emit CrossChainWithdrawalIntentRelayed event

crosschainDeposit

Handles verified cross-chain deposits. Called by ShinobiDepositOutputSettler after oracle validation.

function crosschainDeposit(
    address _depositor,
    uint256 _amount,
    uint256 _precommitment
) external payable nonReentrant onlyDepositOutputSettler
Flow:
  1. Validate caller is the configured depositOutputSettler
  2. Validate precommitment hasn't been used (replay prevention)
  3. Mark precommitment as used
  4. Insert commitment into the pool's Merkle tree
  5. Emit deposit event

handleRefund

Handles refunds for failed cross-chain withdrawals. Called by ShinobiInputSettler when an intent expires.

function handleRefund(
    uint256 _refundCommitmentHash,
    uint256 _amount,
    uint256 _scope
) external payable onlyWithdrawalInputSettler
Flow:
  1. Validate caller is the configured withdrawalInputSettler
  2. Fetch pool by scope
  3. Call pool.handleRefund() to insert refund commitment
  4. User can later withdraw the refund normally

setWithdrawalChainConfig

Configure a destination chain for cross-chain withdrawals.

function setWithdrawalChainConfig(
    uint256 _chainId,
    address _outputSettler,
    address _outputOracle,
    address _fillOracle,
    uint32 _fillDeadline,
    uint32 _expiry
) external onlyRole(_OWNER_ROLE)

Access Control

FunctionAccess
crosschainWithdrawalPublic (anyone with valid proof)
crosschainDepositonlyDepositOutputSettler
handleRefundonlyWithdrawalInputSettler
setWithdrawalChainConfigonlyRole(_OWNER_ROLE)
setWithdrawalInputSettleronlyRole(_OWNER_ROLE)
setDepositOutputSettleronlyRole(_OWNER_ROLE)

Events

event CrossChainWithdrawalIntentRelayed(
    bytes32 indexed orderId,
    address indexed recipient,
    uint256 destinationChainId,
    uint256 amount,
    uint256 solverFee
);
 
event CrossChainDepositProcessed(
    address indexed depositor,
    uint256 amount,
    uint256 precommitment
);

Security Considerations

  1. Proof validation — ZK proof is validated in the pool before intent creation
  2. Replay prevention — Precommitments are marked as used
  3. Access control — Only authorized settlers can call deposit/refund handlers
  4. Reentrancy protection — All entry points use nonReentrant

Source Code

View on GitHub

Related