porto

repository·main·Indexed 20 days ago

https://github.com/ithacaxyz/porto

Next-generation account infrastructure for Ethereum providing smart contract-based accounts and developer tools. The ecosystem includes UI components, identity services, a theme export CLI, and a dedicated proxy (id.porto.sh) for routing WebAuthn Relying Party requests. It features a UI library supporting both Source Mode with Panda CSS and Bundled Mode, as well as a Playground for testing account upgrades and local infrastructure via Anvil.

Tokens
160.7K
Snippets
543
Records
654
Agent score
69%

What's inside porto

  1. Overview of the `id.porto.sh` Proxy

    main
    The id.porto.sh Proxy is a dedicated proxy project designed to route incoming requests from the WebAuthn Relying Party (RP) domain id.porto.sh to their respective backend applications. It acts as a single entry point for multiple sub-projects or services under the same domain.
  2. Overview of Porto onchain infrastructure contracts

    main

    Porto's onchain infrastructure is composed of four primary contract types that manage accounts, orchestration, simulation, and settlement:

    1. Porto Account: A keychain for holding user funds. It enforces permissions via Keys, manages nonces to prevent replay attacks, and enables secure executions.
    2. Orchestrator: A privileged contract that facilitates trustless interactions between the relay and the account.
    3. Simulator: A peripheral utility used by offchain services to obtain accurate gas estimates for intents via a single RPC call.
    4. Settlement System: Enables cross-chain transaction finality using native merkle signature verification. It supports multi-chain intents with features like fund transfers, merkle signature verification, and funder interface integration.
  3. Overview of the Porto Relay

    main

    The Porto Relay is a JSON-RPC 2.0 service that facilitates communication between the Porto SDK and various blockchains. It is responsible for building, simulating, and sending intents to smart contracts on behalf of a user.

    Execution fees are paid using supported fee tokens on the target network. You can discover which tokens are accepted for a specific chain by calling the wallet_getCapabilities method.

  4. What is the Porto Account abstraction?

    main

    The Porto Account is a lightweight wrapper around the standard Viem Account. Its primary purpose is to add support for Porto Keys, enabling seamless interaction with the Porto Relay.

    When to use it:

    • Wallet Developers: Use this abstraction if you are building a wallet that interacts directly with the Porto Relay.
    • Application Developers: If you are using Porto via Wagmi or the EIP-1193 Provider (porto.provider), you generally do not need to use the Account wrapper directly.
  5. Overview of Porto Storage Backends

    main

    Porto provides a storage layer compatible with both browser and non-browser environments. You can choose from several backends depending on your persistence requirements and environment:

    • Storage.idb: Uses IndexedDB. This is the default for browser environments.
    • Storage.cookie: Uses browser Cookies.
    • Storage.localStorage: Uses browser localStorage.
    • Storage.memory: Uses a JavaScript Map. This is the default for non-browser environments.
  6. What is the Simulator and how does it work?

    main

    The Simulator is a utility for offchain services and Relays to obtain accurate gas estimates for intents. It acts as an advanced multicall that builds upon the simulateExecute function of an Orchestrator contract.

    Key capabilities include:

    • Searching for optimal combinedGas values.
    • Generating custom execution traces.
    • Providing clear error messages for transaction reverts.

    Simulators are decoupled from Orchestrators; any simulator can be used with any Orchestrator instance, and they require no special onchain privileges.

  7. Overview of Porto EIP-5792 Capabilities

    main

    Porto supports EIP-5792 Capabilities, which allow for extension features on specific JSON-RPC requests (like wallet_connect and wallet_sendCalls) or the enablement of additional JSON-RPC methods.

    Supported capabilities include:

    • feeToken: Indicates if custom fee tokens are supported.
    • merchant: Indicates if merchant functionality is supported.
    • permissions: Indicates if permissions can be requested by the app.
    • requiredFunds: Indicates if required funds (sourcing funds from supported chains) are supported.
    • signInWithEthereum: Adds support for ERC-4361 Sign in with Ethereum.
  8. Understand PreCalls and their usage

    main

    PreCalls are special calls executed prior to the pre-verification of the bundle signature and before any payment is made. They are used to manage account permissions and delegations.

    Allowed PreCall types:

    • Delegation.authorize: Authorizing a key
    • Delegation.revoke: Revoking a key
    • Delegation.setCanExecute: Setting call permissions
    • Delegation.setSpendLimit: Setting spend limits
    • Delegation.removeSpendLimit: Removing spend limits
    • Delegation.upgradeProxyDelegation: Upgrading delegation

    Requirements for PreCalls:

    • They must be signed with a key already attached to the account.
    • When building a precall, you can set precall: true in the capabilities object, which allows you to omit the from and key fields in the request.
  9. Manage keys with Porto `Key`

    main

    The Porto Key abstraction provides key management for Porto Accounts. It supports multiple key types, including:

    • WebAuthn (passkeys)
    • WebCrypto-P256
    • P256
    • Secp256k1

    Note for Developers:

    • Wallet Developers: Use this abstraction if you are interacting with the Porto Relay directly.
    • Application Developers: If you use Porto via Wagmi or the EIP-1193 Provider (porto.provider), you likely do not need to use the Key abstraction directly.
  10. How Guest Mode works via account: null

    main

    Guest mode is triggered by passing account: null within a transaction call (such as those from viem or wagmi). When Porto detects a null account, it intercepts the request and manages the account connection flow (prompting the user to connect or create an account) only when the transaction is actually ready to be sent.

    import { erc20Abi, parseUnits, type Address } from 'viem'
    import { writeContract } from 'viem/actions'
    import { useClient } from 'wagmi'
    
    export function Send() {
      const client = useClient()
    
      async function handleSend() {
        // Setting account to null triggers Porto's interception logic
        await writeContract(client!, {
          abi: erc20Abi,
          account: null, 
          address: tokenAddress,
          functionName: 'transfer',
          args: [recipient, parseUnits('10', 18)],
        })
      }
    
      return (
        <button onClick={handleSend}>
          Send
        </button>
      )
    }
  11. Understand Porto's cross-chain interoperability architecture

    main

    Porto's interoperability layer enables trustless multi-chain operations through three core components:

    1. Settlement System: Facilitates cross-chain transaction finality using merkle signature verification and messaging protocols. It supports different mechanisms like SimpleSettler (signature-based for trusted environments) and LayerZeroSettler (using LayerZero v2 for decentralized settlement).
    2. Escrow: Provides secure token holding with support for native and ERC20 tokens. It features configurable refund amounts, deadlines, and atomic settlement verification.
    3. Cross-Chain Execution: Integrated into the Porto Account, this includes Multichain Nonces (using the 0xc1d0 prefix to enable signature replay across chains), Merkle signature verification, and secure cross-chain fund transfers.