old_Loopcrypto.xyz
  • Introduction
  • Supported networks and tokens
  • Loop + Frames
  • Learn
    • How Loop works
    • Core components
      • Collecting authorization
        • Enabling payment on multiple networks
        • Accepting ETH and MATIC
      • Sending payment requests
      • Checking a customer's balance & allowance
      • Receipts and reminders
      • Customer portal
    • Loop + your financial stack
      • Linking on-chain transactions with invoices in your ERP system
      • Connecting with accounting software
      • Crypto off-ramp
    • Case studies
  • Dashboard functionality
    • Subscriptions
      • Free trials, discounts and more
      • Auto-invoicing
      • Auto-cancelations
    • One-time payments
    • Scheduling outbound payments
      • Internal notes
    • Editing an upcoming payment
    • Payments for platforms
  • Integrations
    • Stripe + Loop
      • Getting setup
      • Stripe Connect setup
      • Subscriptions
        • Free trials
        • Upgrading a customer or editing a subscription's products
      • Invoicing
      • One-time payments
      • Coupon codes
      • Stripe Connect - Subscriptions
      • FAQs about Stripe integration
    • Chargebee + Loop
      • Getting setup
      • Subscriptions
      • One-time payments
      • Coupon codes
    • Quickbooks + Loop
      • Invoicing
    • Xero + Loop
      • Invoicing
    • Ghost.org + Loop
    • Zapier + Loop
    • Manually add integrations
  • Technical Docs
    • APIs
      • Entity
        • Adding child entities
        • Adding user to child entity
        • Get child entities
      • Items
        • Adding items
          • Item types
          • Categories
        • Retrieving an item
        • Updating an item
        • Deactivating an item
      • Agreements
      • Transfer requests
        • Signing transfer requests
        • Loop CLI
        • Canceling transfer requests
        • Transfer request status
        • Handling unfulfilled transfer requests
        • Validations
      • Webhooks
        • Checking webhook signatures
        • Demo App
        • Slack, Airtable, Discord, Telegram
    • Archeticture
      • Smart contract
        • Deploying your smart contract
          • Modifying smart contract properties
      • Collecting authorization
        • Checkout page
          • Additional functionality
          • Add "pay with crypto" button
        • Checkout widget
          • NPM package readme
        • Checkout parameter examples
      • Providing on-chain payment based access
        • Subscription gated communities
    • Loop SDK
      • Verify Webhook
      • Transfers
      • Error Handling
      • Generating API keys
    • Sample guide: Collect a subscription or one-time payment
    • Integrating the Loop Protocol into your dApp
      • Payroll applications
      • Loan platforms (credit cards, BNPL)
    • Security
      • API Authentication
      • Securing with signatures
      • API Trust assumptions
      • Audits
  • FAQs
  • Company Dashboard
  • Loop Portal
Powered by GitBook
On this page
  1. Technical Docs
  2. Archeticture

Smart contract

Each company has its own proxy contract. The Loop factory is the one responsible for deploying these proxies.

The implementation of this makes use of the Beacon Proxy. For every contract, a new beacon is deployed in the factory with the implementation contract (template) address as a parameter. Then when a new proxy for a type is needed, the factory deploys the proxy and tells it to look at the configured beacon for its implementation contract. The factory keeps track of all proxies it has deployed and will be the “source of truth” when searching for Loop contracts.

The implementation address that is stored in the beacon can be “upgraded” to point to another address in the case of an upgrade to fix a bug or add functionality. All deployed proxies will automatically use this new address, so there is no need to upgrade individual contracts.

It is important that the address of the proxy that gets deployed is never changed. The allowances on the token are given to a specific contract, and if the contract changes its address, the allowance will need to be redone. Using the beacon proxy pattern allows us to upgrade the implementation contracts without changing the original proxy's address and therefore preserving the allowance that has already been set against that proxy.

PreviousArchetictureNextDeploying your smart contract

Last updated 12 months ago