LogoLogo
  • Guide to Developing on Layer One X
    • Contents
    • L1X vs. Other Chains
    • L1X Technology Overview
      • X-Talk Overview
      • L1X System Architecture
      • XTalk Deep Dive
  • L1X Documentation
    • Setup L1X Development Environment
  • Use Cases
    • Use Case 1: Decentralised Finance (DeFi)
      • Key Components and Protocols
      • Use Case Implementation Examples
      • Future Trends and Innovations
    • Use Case 2: Non-Fungible Tokens (NFTs)
      • Applications in Art, Gaming, and Collectibles
      • Use Case Examples and Case Studies
      • Emerging Trends in NFTs
    • Use Case 3: Identity Management
      • Importance of Self-Sovereign Identity
      • Use Cases in Identity Verification and Authentication
      • Projects and Initiatives in Identity Management
      • Privacy and Security Considerations
    • Use Case 4: Content Monetisation
      • Challenges in Content Monetisation
      • Blockchain Solutions for Micropayments and Royalties
      • Use Case Examples in Publishing, Music, and Media
      • Future Opportunities and Trends
    • Use Case 5: Voting and Governance
      • Advantages of Blockchain in Voting Systems
      • Use Cases in Elections, Polls, and Governance
      • Projects and Platforms for Decentralised Voting
      • Challenges and Considerations
    • Use Case 6: Decentralised Storage
      • Problems with Centralised Storage Solutions
      • Use Cases in Decentralised File Storage
      • Projects and Platforms for Decentralised Storage
      • Scalability and Performance Challenges
    • Use Case 7: Gaming and Virtual Worlds
      • Introduction to Blockchain Gaming
      • Use Cases in Virtual Economies, Assets, and Ownership
      • Notable Projects and Success Stories
      • Trends and Innovations in Blockchain Gaming
    • Use Case 8: Healthcare and Medical Records
      • Importance of Data Integrity and Security in Healthcare
      • Use Cases in Medical Records Management
      • Projects and Initiatives in Health Data Management
      • Regulatory Compliance and Privacy Concerns
    • Use Case 9: Decentralised Autonomous Organisations (DAOs)
      • Understanding DAOs
      • Use Cases in Governance, Funding, and Decision Making
      • Future Developments
    • Use Case 10: Supply Chain Management
      • Overview of Supply Chain Challenges
      • Blockchain Solutions in Supply Chain
      • Use Case Examples in Tracking and Traceability
      • Potential Benefits and Challenges
  • Get Started with L1X SDE
    • L1X Workspace Overview
      • L1X SDE toolkit architecture
    • Development Workspace Environment & Contract Types
      • 1 - Contemporary Contracts
      • 2 - ERC20 Contract Deployment and Cross Contract Call
      • 3 - X-Talk Flow Cross Chain Contract
      • 4 - Balancer-v2
  • Build with Developer Playground
    • Developer Playground Resource
  • Core Concepts
    • Account
    • Address
    • Transaction
    • Smart Contract
    • Contract Lifecycle (VM)
    • Cross-Contract call
      • L1X VM Cross-Contract Calls
      • L1X VM-EVM Cross Contract Calls
    • Cluster
Powered by GitBook
On this page
  1. Core Concepts
  2. Cross-Contract call

L1X VM Cross-Contract Calls

PreviousCross-Contract callNextL1X VM-EVM Cross Contract Calls

Last updated 1 year ago

eBPF runtime allows a smart-contract to call another smart-contract's function. The smart-contract is halted until the called smart-contract finishes execution.

When Smart-Contract A calls Smart-Contract B, the is Smart-Contract B is executed in the following context:

  1. The caller_address() API function will return the Smart-Contract A contract instance address

  2. transfer_from_caller() API function will transfer tokens from Smart-Contract A balance to Smart-Contract B balance

  3. contract_instance_address API function will return Smart-Contract B contract instance address

  4. contract_owner_address API function will return Smart-Contract B contract owner address

  5. If Smart-Contract A has been called in read-only context then Smart-Contract B will be called in the same context. It means Smart-Contract B will not be able to modify its own persistent storage.

Diagram