Contracts

📘

Head to the Source

We're in the process of open-sourcing our new V2 contracts and the repository will be linked here when available. All of our contracts have been verified on PolygonScan and the original source code is visible there.

Token Addresses

The token addresses of OPN across each chain are:

OPN Contract Address Ethereum - 0xc28eb2250d1AE32c7E74CFb6d6b86afC9BEb6509

OPN Contract Address Solana - J1YnyKzmxBwFkPftvZexnHTm4Am7JnmWydhxtXdwEmMv

OPN Contract Address Polygon - 0x7844F79FC841E4F92d974C417031c76F8578c2D5

OPN Contract Address Base - 0x9A6d24c02eC35ad970287eE8296D4D6552a31DbE

Ticketing Addresses

Economics

• 0xe93EF19446c4e80207add5fA2CD3E0116e8959F4

Responsible for managing the internal balances and accounting within the protocol. Manages available and reserved fuel balances for each integrator as well as the protocol-wide spent fuel balances. The billing rates for each integrator is held within the integratorRates mapping and each integrator's metadata can be found within integratorData.

Since each integrator can have one or more relayers, Economics.sol also tracks a mapping of relayerAddress to the integrator allowing accounting operations to happen only using the relayer address.

Auth

• 0x821bacd7AAC670Ab7d80bCf74e517620D1a24700

Handles access control and permissions for protected methods used within the protocol such as updating the price oracle, creating integrators, and performing custodial top-ups. Also permissions contracts to each-other so that only certain contracts can talk to protected methods.

EventFactory

• 0xAC1ffEEA39e3db60599BdF6697988Aa5f0eD26F4

EventFactory.sol is responsible for creating new events and assigning them an index in which they can be referenced using. Because each event is its own independent smart contract, the EventFactory is only responsible for creating each event and setting the initial event metadata. Future updates to metadata must be made directly to the event's contract address.

EventImplementation

• 0x79fB70D8e1aDe9608F7F7F7ba62821f8CA9f4E08

Never accessed directly, this is the implementation contract used for each event using the BeaconProxy pattern. Each event is a separate contract but uses the same implementation for consistency, and this is the implementation. Contains all of the lifecycle methods for ticket interaction and the ERC-721 implementation. Implements the OpenZeppelin's IERC721 and IERC721Metadata, but not IERC721Enumerable.

FuelDistributor

• 0xBa241CD4F7C0E2419Fe25FB0a5b50D122C1A0C1b

Defines and distributes the collected spent fuel from the Economics contract. Economics is only responsible for tracking the total amount of protocol-spent-fuel and total-spent-fuel but not for the distribution. Exposes a public collect() function that can be used to distribute the protocol-spent-fuel to the assigned destination addresses, and then the remainder to the remainder addresses.

PriceOracle

• 0xBF705239C90211bff2E4CF513c01209CdA228aF9

Used as an on-chain oracle for the price of OPN in USD to 18 decimal places. This is necessary for valuing direct non-custodial OPN top-ups and is driven using an off-chain worker.

Registry

• 0x27B50CA961480B35005d452E288600f6e4534eC6

Tracks all of the other contract addresses in use by the protocol. This allows each contract to hold only a reference to the deployed Registry.sol contract and then use this to reference any other contract as needed at runtime. If in doubt, check the registry for the currently active addresses for all other contracts listed here.

TopUp

• 0x748df336E5d1c6387E3FAD5dEC86FB9B1d4c3Eda

Entrypoint for topping up an integrator account. Contains one public method for non-custodial top-ups using OPN held within the sender's wallet and one protected method for topping-up the available fuel using USDC via a swap using the Sushi pools. Routes transfers via a path of [baseToken, weth, Economics.fuelToken()].

Relayers

A relayer is responsible for minting the NFTs for an integrator and is linked to an integrator's account in order to track OPN fuel balances and accounting per-relayer-address. These relayer addresses have indepenedent rate configurations depending on the products used. See integrators for more.

A relayer belongs-to an integrator and this means that an integrator can have more than one relayer as necessary should multiple be needed to additional scale, although at present each integrator only has a single active relayer.

You can query for the active relayer addresses using the subgraph:

{
  relayers {
    id
    isEnabled
    integrator {
      name
    }
  }
}