#Simple Summary
A standard for a contract to indicate which SEPs it claims to implement.
#Dependencies
#Motivation
Contract standards are defined in SEPs, such as SEP-41. These SEPs can contain interface definitions that contracts implement. When a contract implements an interface defined in a SEP it currently has no way to indicate that it intends to satisfy the requirements of a SEP, so that off-chain systems and other developers can discover that intent.
#Abstract
This SEP defines a way for contracts to indicate which SEPs they implement using a meta entry (SEP-46), and for others to discover it.
#Specification
A contract that implements an interface, and wishes to claim that it implements
the interface, should include the SEP's identifier, its number, in the value of
a sep meta entry.
#Meta Entry Key
The meta entry key must be sep.
#Meta Entry Value
The meta entry value must be a comma-separated list of SEP identifiers. The
identifiers in the list may be in any order. The identifiers should be included
with any leading zeros removed. e.g. 41,40.
#Multiple Meta Entries
The sep meta entry may appear multiple times in a contract's meta. If more
than one entry exists with the key sep the values should be assumed to be
have been joined together with a comma as separator.
#Example Usage
The following example illustrates how to include contract meta for a contract that implements SEP-0041 and SEP-0040.
Contract meta can be inserted in Rust contract code using the Soroban Rust SDK
(soroban-sdk) by using the contractmeta!() macro.
soroban_sdk::contractmeta!(key="sep", val="41,40");
#Design Rationale
#Storage in Contract Meta
The SEP list is chosen to be stored in contract meta because contract meta is accessible to off-chain systems without executing the contract, meaning that off-chain systems like block explorers or developer tooling can ascertain the intended uses of a contract without needing to have a contract execution system available.
#Meta Key Name
The meta key name sep doesn't collide with any existing meta keys stored on
pubnet in contract code. This was verified by inspecting every installed
contract on 2025-02-14.
#Single Meta Key
A single meta key with a comma-separated list of SEPs was chosen to:
- Reduce the number of meta entries required by grouping values together.
- Make the code a developer must write to record a SEP concise and without unnecessary repetition.
- Make it easy to discover all supported SEPs by looking at the value of a single key.
#Multiple Occurrences
The meta entry may occur multiple times in the contract meta to make the meta easier to write from within Rust proc-macros. It cannot be assumed that the developer could specify the list all in one place. The meta entries may be written by different code modules within a Rust crate. This may happen because implementations for some interfaces may come from dependencies or extensions. The Rust compiler does not allow proc-macros to coordinate and build the meta entry into a single entry. When multiple areas of code specify the meta key and value, the Rust compiler will append each meta entry to the resulting list of meta entries into the contract meta resulting in a stream of meta entries.
#No Support for Multiple Interfaces in a SEP
It is possible for a SEP to define multiple interfaces, but distinguishing those interfaces from each other for a contract implementing them is not supported by this proposal. No SEP today defines multiple interfaces. Reviewing other blockchain ecosystems suggests this is not a common occurrence in other ecosystems either. A future SEP that requires multiple interfaces can introduce it's own meta key to delineate.
#No Support for On-Chain Access
This proposal stores the SEP in the contract meta, which is not available to contracts to inspect. This is targeted to solve the problem of off-chain systems evaluating whether contracts intend to implement a SEP, and not on-chain contracts evaluating the same. If this data was required to be accessible on-chain, that could be the topic of a CAP that created new access to this data, or the topic of another SEP that exposed that information through functions.
#Security Concerns
Contracts may claim to implement SEPs that they do not actually implement. Applications using the meta should do so with care and define ways to verify claims before taking any action based on them. Specification for how to perform any such verification is out-of-scope of this proposal as what is required could be different depending on the contract. No SEP claim ever replaces the need for contract audits and other security measures. This proposal when implemented is informative only.
#Changelog
v0.1.0: Initial draft.