Introducing Startrail PEG

4 min readMay 26, 2021

Introduction

The global NFT market is exploding however most NFTs and markets don’t yet support fundamental features like flexible royalty payments, rich provenance, historical records and managing contract terms, or metadata that is interoperable, versioned and permanent.

Startrail already provides these services to artists who choose to mint NFTs on the Startrail platform. For a brief introduction to Startrail see “Overview and technical introduction of Startrail and Startbahn Cert.” and the Startrail website.

We want to make it as easy as possible for existing tokens and marketplaces to add on this functionality to both existing and next generation tokens.

So we’re creating “Startrail PEG” to allow marketplaces to easily integrate with Startrail and add these features to their NFTs.

The benefits of integrating with Startrail PEG for parties in the ecosystem will be:

zero to minimal development work required to add these features to any NFT contracts
a common interface soon to be proposed in new EIP standards
consolidation of all NFTs to a single wallet as well as consolidation of royalty payments to a single wallet
shared KYC — we will open up sharing of KYC’d user details to markets that integrate. if a user is already KYC’d on our system, the market will not need to KYC the user again
royalty fee can be configured for artists as well as primary marketplace providers
free of charge at least for 1 year, no lock in

Startrail PEG

The idea of Startrail PEG is to link a second pegged NFT to the original NFT. The pegged NFT (Startrail Registry Record or SRR) provides extended history and provenance, versioned metadata, royalties and terms and conditions abilities providing a way to extend the original token contract(s) without requiring changes or upgrades.

This is particularly useful for existing contracts that either can’t be upgraded or would require a lot of development work to create new versions. The first version of the Startrail PEG is targeted at these token contracts. Later versions will provide direct integrations, eg. contract to contract interfaces to add these features and/or adoption of our new standards directly.

Startrail PEG will be available on all EVM compatible chains initially however other chains will be supported in the future.

How does it work

To make integration as quick and easy as possible we provide:

an Oracle that automatically sets up the peg with Startrail and propagates transfer events from the market token to the SRR token
the SRR that provides the extended features and functions
an SDK and transaction relay server to make it easy to interface with the SRR token
a subgraph on TheGraph that indexes the data from the SRR and provides a GraphQL interface for querying
a user friendly Startrail DApp that allows a user to directly call the Startrail PEG token. This is useful when the original market token’s UI does not or has not yet integrated with the Startrail PEG API

The following diagram summarizes interactions and integration with Startrail PEG:

Functions available to the owner of the new SRR token are as follows (NOTE: full API will be published with SDK docs soon in a follow up post):

The SRR token data is available in the subgraph as:

The oracle process will be open sourced and verifiable.

Payments / Royalties Infrastructure

We will be introducing a royalty and payments distribution system. This will allow markets to easily extend payment options provided to users. It will also allow minters and artists to set their royalty terms before first sale.

The first version supports EIP-2981 for markets to retrieve the royalty amount. The royalty receiver can be a Startrail smart contract that knows the distribution rules defined by the minter. For example if split royalties are defined the contract will calculate and send portions to each receiver.

If the original token is on a different chain to the SRR (Polygon) then a Startrail handling contract on the original token chain will be the royalties destination. A bridge and Oracle will keep this contract in sync. Initially we intend for these handling contracts to be deployed to Ethereum mainnet, Binance Smart Chain and support other EVM-based chains later. We aim to support non-EVM chains too.

We intend to extend this interface to support more complicated royalty amount calculations as well as payouts in tokens on other chains as well as fiat payouts.