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
  3. Smart contract

Deploying your smart contract

PreviousSmart contractNextModifying smart contract properties

Last updated 12 months ago

Loop will deploy a smart contract on your behalf on each network that you would like to collect payments on. In the future, there will be a self-serve option through the Company dashboard.

Below is the information we need to deploy your smart contract. You can provide this information to Loop via your dedicated Telegram channel. If you do not yet have a Telegram channel and would like to use Loop, please contact support.

Initial contract properties

To get started, you’ll need to specify the following properties for us to set up your subscription contract:

Attributes
Description

Inbound Treasury

The address of the wallet you want to receive transfers to An inbound treasury address is required to enable auto-invoicing; otherwise, it is optional. We recommend using a multi-sig or custodial wallet (i.e. wallet at an exchange) for your inbound treasury if you plan on holding significant funds there.

Signer

The address of the wallet signing the transfer order / payment requests. Note: in most cases, the best option is for Loop to be the delegated signer, because this enables auto-invoicing and other invoice management features. By default, Loop will be the delegated signer when setting up your contracts. If you would like to be the signer, please let us know prior to setup.

Accepted Tokens

Optional. By default, the contract will accept these . If you enable Stripe / Chargebee integration, all tokens in the contract will automatically be applied to any product pulled into the system. However, you can modify the list of accepted for a given subscription by editing the subscription on the dashboard or .

Companies can modify this list by providing the token addresses and chainlink aggregator addresses for the token that you want to use for transfers. Transfers will only be able to be processed using this list of tokens.

Accepted tokens can optionally be configured per network.

Companies can further restrict which tokens are accepted at the item level. For example, a company could specify for the "Developer plan" that only USDC and WETH are accepted but for the "Enterprise plan" only WBTC is accepted. Thus, if the company wants a given token accepted for a specific plan, that token needs to be specified in the contract.

Signer Wallet

In our default setup, Loop acts as the delegated signer. This enables enables auto-invoicing and other invoice management features; however, for those that want to use the Loop protocol completely trustlessly, we allow for end-users to be the Signer address. This address is used to sign all individual transfer orders sent to Loop. This assures that only the owner of this wallet can submit transfer orders on your behalf or modify any of the transfer order parameters that are submit. See Securing with Signatures for more detail.

Since this wallet needs to sign every transfer order, it is recommended that this not be a multi-sig wallet. The most efficient way to sign these orders is programmatically, so using a multi-sig would be prohibitively slow and cumbersome.

An example of how to programmatically sign and send transfer requests can be found here.

supported tokens
API call