NameCollection [01] refers to a collection of NameNFTs [02] that represent a particular namespace of NeoChannels [03], created for a particular purpose. A “NameCollection [01]” is a specific “Collection” on Sui. Note that the phrase ‘a collection of Channels [03]’ does not refer to any specific structure in Sui. Rather it describes in plain language that NeoChannels [03] are grouped in collections. Each collection forms a namespace. The set of all NeoChannels [03] are the basis of the Global Channel System [90].

A NameNFT [02] is an owned object, fully under the control of a wallet. It has a unique ID [04]. It encapsulates a reference to its corresponding Engine [36] and holds the Channel Metadata [06]. A NameNFT [02] must adhere to: public struct Channel has key, store { id: UID, metadata: ChannelMetadata, channel_engine: address, //...extensible (including static and dynamic) } This structure ensures interoperability across wallets and platforms. Provided this structure is correct the NameNFT [02] or NameCollection [01] can be properly deserialized within channel_protocol [22]. Note that a NameNFT [02] may be deemed obsolete under specific conditions governed by the Channel Engine [36]. This can occur either when the Channel Engine [36] expires due to non-renewal of the Channel [03] or when it is invalidated during a recovery process. This ensures that outdated or compromised NeoChannels [03] are effectively managed by channel_protocol [22], maintaining the integrity of the network [90]. Since each NameNFT [02] carries embedded Metadata [06] that defines its display parameters, all NameNFTs present a consistent look and feel across interfaces and wallets.

NeoChannels [03] are the core building blocks of the Global Channel System [90]. Each NeoChannel [03] has two fundamental structures. One is the NameNFT [02], controlled by the owner's wallet. The other is the Engine [36], held in Sui’s global storage. Within the Engine lies the Treasury [37]. The term NeoChannel [03] encompasses all the structures that make up a Channel [03] and is used descriptively, as in 'Do you own a NeoChannel [03]? All Channel [03] names are unique, don’t miss out on the one you want'.

Each NameNFT [02] has a unique object identifier. This identifier is sometimes referred to as the Channel ID. It is the primary reference for Channel [03] operations. Note that the Channel Engine has its own unique identifier, the Engine ID.

The InitialNFT [05] refers to the first NameNFT [02] minted for a new NameCollection [01]. The InitialNFT [05] has the same structure as any NameNFT [02] except that it represents the entire NameCollection [01] rather than only representing itself. Once validated and minted, the InitialNFT may be referred to as the NameCollection [01] or the CollectionNFT.

Within the NameNFT [02] there is a descriptive data structure referred to as ChannelMetadata [06]. This structure adheres to the Sui NFT display standard [46] and can only be updated by the Channel [03] owner. ChannelMetadata [06] includes the Channel’s name [10], Description [11], image URL [14] and address [16]. The structure is extensible. ChannelMetadata [06] has only "store" ability. It is not designed to exist independently. It is encapsulated by the NameNFT [02]. public struct ChannelMetadata has store { name: String, description: String, url: String, channel_core: address } A subset of ChannelMetadata [06] appears in both the NameNFT [02] and in the corresponding Engine [36]. This is due to how these components interact across module boundaries. The duplicated data allows each NameNFT [02] to function correctly within its own NameCollection [01] while maintaining correspondence with its associated Engine [36] .

$GLOW is the utility token of NeoChannels [03]. It is the currency of payment for following a Channel [03], subscribing to a Channel [03], tipping a Channel [03], and for microtransactions. It is required for accessing certain protected content. It is required for Channel renewal.

The Handle [09] is a truncated form of the ChannelName [10]. In the Handle [09] form of the Name [10], special characters are removed and capital letters are converted to lowercase letters. Within a NameCollection [01] no two names can have the same Handle [09]. The Handle [09] prevents creating certain petty variations of a ChannelName [10] as they will reduce to the same already registered Handle [09] and therefore be refused by channel_protocol [22].

The human-readable name of a NeoChannel [03], recorded in the ChannelMetadata [06].

A text description of a NeoChannel [03] defined by its owner, recorded in the ChannelMetadata [06].

The wallet address that owns a NeoChannel [03], as distinct from the RecoveryAddress [13].

An owner supplied address by which a channel may be recovered under certain conditions where control of the PrimaryWallet [12] has been lost.

A link to an image that represents the NeoChannel [03] visually, recorded in the ChannelMetadata [06].

The address to a Channel Engine [36], recorded in the ChannelMetadata [06].

Resolvers [18] resolve ChannelNames [10] to display Channels [03] and their Content [72]. Initially the Resolvers [18] for Neochannels [03] will be native to the Glow app [20]. In future these resolvers may be widely adopted.

An application layer that interfaces with channel_protocol [22] enabling user interactions with Channels [03], Content [24], and governance mechanisms. One such client is the “Glow” app [20], as distinct from “$GLOW” [08], the utility token of Neochannels [03].

The foundational smart contract that defines the comprehensive structure, rules, functions, and scope for NeoChannels [03], including their creation, management, Content [72] handling, Treasury [37] operations and subscription mechanisms. Channel_protocol [22] is written in the MOVE programming language on the Sui blockchain.

The ContentLinksTable [23] contains the list of ContentObjects [24] owned by or linked to the NeoChannel [03]. ContentLinks [23] are typically Blob IDs [64] for Content stored on Walrus, or URLs to external content. The ContentLinksTable [23] is stored on-chain with both key and store properties, making it globally accessible and modifiable by smart contracts. The ContentLinksTable [23] uses the table module in Sui MOVE. It acts as a key-value map where unique keys (such as IDs or addresses) are mapped to values such as metadata or pointers. Tables were chosen over vectors because they offer dynamic scaling and O(1) lookup efficiency. This means the system can quickly find specific links in large collections without having to search through the entire set. This approach is particularly well-suited for decentralized storage where specific content needs to be accessed frequently. Note that Sui's parallel execution capabilities through systems like Mysticeti allow for concurrent updates, such as when registering or certifying multiple blobs simultaneously.

Structure for storing content information on-chain, including Title [26], Flags [28],Links [29] to Content [72] stored on Walrus [47] and URLs to content stored elsewhere.

The Title [26] is a component of the ContentObject [24] that gives a human readable name, heading or short description to the content.

A Flag [28] is a component of the ContentObject [24] that contains boolean indicators for various content attributes.

Links [29] stored in the ContentObject [24] that point to content on Walrus [47] or elsewhere.

The Relation [30] is a field in the Engine [36] which defines the subscription relationship of one Neochannel [03] to another, specifying the RelationType [32] (e.g., follower, superfan). It can be used to enable conditional access capabilities.

The IAmFollowing Table [31] is a component of a Channel Engine [36] tracking the other Channels [03] that the NeoChannel [03] is following or subscribed to.

The RelationType [32] refers to values that define the specific type of relationship between two or more Channels, such as follower, superfan, special item holder, or special role holder. Contained in the Engine [36].

The ValidityPeriod [33] is the component of a Channel Engine [36] that defines the time frame during which a Channel [03] is valid, establishing when it needs to be renewed.

Sui Global Storage [34] is the decentralized storage of the Sui blockchain where shared objects such as the Channel Engine [36] and AggregatedList [42] are stored and may be accessed by smart contracts.

The MyFollowersTable [35] is the component of a Channel Engine [36] that tracks which Channels [03] are subscribed to it.

The Engine [36] is a shared object that represents the state of a NeoChannel [03] to the outer world. It contains the operational data for a channel including the Treasury Wallet [37], MyFollowers table [35], ContentObjects [24], IAmFollowing table [31] and ValidityPeriod [33]. It is designed to be extensible. The Engine object has “key” ability but not “store” ability. It has its own unique identifier [04]. Without “store” ability the Engine cannot be embedded in other structures. It is designed to operate as an independent, globally accessible object that multiple users can interact with simultaneously, within the limits defined by channel_protocol [22]. public struct ChannelCore has key { id: UID, channel_id: address, creator: address, channel_name: String, handle: String, url: String, channel_description: String, treasury_wallet: Bag, content_links: Table<String, ContentLinks>, channel_type: ChannelType, is_verified: bool }

The Treasury [37] is a specialized wallet that operates within each NeoChannel [03] to hold and transact with Channel-related assets, including $GLOW [08], SUI, WAL, stablecoins and NFTs. The wallet [37] is wrapped, meaning it operates directly on-chain, for increased dynamism. The Treasury [37] uses a Bag data structure [62] through the sui::bag module in Move. Bag offers O(1) access efficiency for real-time operations such as payouts to Walrus nodes [50]. It allows flexible management of multiple asset types without compile-time type constraints. The Treasury [37] may support increasingly varied assets over time, including memecoins, NFT collections and various wrapped tokens such as wrapped BTC. It may be involved in various staking mechanisms. It may participate in or be composable with external protocols such as Defi protocols, insurance protocols and trading bots. Using the Bag data structure [62] enables the Treasury [37] to handle heterogeneous asset types. Bag ensures secure and scalable management of the Treasury’s [37] assets. It is compatible with Sui's ownership model and supports parallel updates. Channel Treasuries [37] may evolve into “smart contract wallets” by being encapsulated within a TreasuryWallet struct with key ability, adding governance features such as multi-sig admin control, upgradability via Sui’s upgrade_cap, and secure deposit/withdrawal functions (e.g., deposit<T> to add coins and update balances). This will transform each Treasury [37] into an autonomous, secure wallet, retaining the asset storage function while adding considerations for type safety, storage, with O(1) performance for adding or retrieving balances.

A ChannelList [38] is a registry within channel_protocol [22]. It tracks ChannelNames [10] that have already been minted in a NameCollection [02]. If any human or agent tries to create a Channel [03] with a duplicate name there is an automatic rollback of the minting process, preventing naming conflicts. A ChannelList [38] is a shared object with its own ID. The mutable nature of a ChannelList [38] is strictly controlled by channel_protocol [22]. public struct ChannelList has key, store{ id: UID, collection_type: String, human_channel_list: Table<String, ID>, agent_channel_list: Table<String, ID>, }

The Aggregator [40] is a module within channel_protocol [22]. It is responsible for managing the verification of name_collection packages [44] and their consequent Channel [03] Collections [05]. Within the Aggregator [40] is the AggregatorObject [42] which maintains an aggregated_list [43] of all name_collection packages [44], preventing duplicates. Acting as a higher-level coordination mechanism, the Aggregator [40] is responsible for tracking the verification status of all minted collections by way of the aggregated_list [43]. At present the verification process is conducted centrally, hence the aggregator_module [40] is defined as a module within channel_protocol [22]. It is possible that this will be transitioned to a verification model that is community governed, at which point the aggregator_module [40] may become its own package.

The AggregatorObject [42] is a shared object with its own ID. It is managed by a module within channel_protocol [22] called the aggregator_package [40]. The AggregatorObject [42] further contains a table called the aggregated_list [43].

The aggregated_list [43] is a table within the AggregatorObject [42]. Within the table [43], NameCollections [01] and their verification status are structured as key-value pairs. The table uses a table<String, bool> structure, where the key represents the collection type name (e.g., 00000000000000000000000000000001::string::String) and the value is a boolean indicating whether the collection has been verified. public struct AggregatedList has key, store{ id: UID, collections: Table<String, bool> }

A name_collection package [44] is what gives rise to a unique NameCollection [01] of unique NameNFTs [02]. Each Collection is a unique namespace and has its own particular rules. When a new name_collection package [44] seeks verification by channel_protocol [22], each NameNFT [02] for the NameNFTCollection [01] must contain both the ChannelMetadata [06] and a reference to a corresponding Channel Engine [36]. This dual structure ensures that NameNFTs [02] from all name_collection packages [44] are compatible with channel_protocol [22], maintaining correct separation between modules. While external entities can define their own name_collection package [44] independently of channel_protocol [22], there must be strict adherence to the correct structure. Crucially, all NameNFTs [22] within a NameCollection [01] must be minted using channel_protocol [22].

Standardization object for NFT display that ensures consistent visualization of NameNFTs [02] across wallets and interfaces.

A scalable decentralized storage system built by Mysten Labs for which the Sui blockchain is the coordination layer. NeoChannels [03] use Walrus [47] to store Content [24] off-chain, linking it to on-chain metadata via blob IDs [64].

The Walrus Client is used for certifying and registering files in the Walrus [47] decentralized storage system. The Walrus Client [48] is an off-chain tool or interface that interacts with Walrus [47] enabling users to upload, retrieve and manage blobs (binary large objects).

The Custom Publisher [49] handles writing data to Walrus [47] and optimises writing performance. It takes care of payments to Walrus [47] on behalf of the user.

The Custom Aggregator [49a] handles reading data from Walrus [47] in a Channel [03] specific manner, optimising for performance and ensuring data integrity.

The storage aspect of Walrus [47]

A high-performance, object-centric blockchain developed by Mysten Labs, serving as a coordination layer for NeoChannels [03] in relation toWalrus [47].

Inside a shared object, the BlackList [52] is a non-comprehensive list of prohibited ChannelNames [10] that cannot be minted due to policy violations or abuse potential.

Inside a shared object, the Blocklist [54] is a non-comprehensive list of reserved ChannelNames [10] for highly established brands and identities that require formal verification before minting.

Inside a shared object, the GoldList [56] is a list of ChannelNames [10] that command higher creation fees due to the premium status of the words in the name.

Inside a shared object, the PremiumList [58] is a list of premium ChannelNames [10] that command higher creation fees due to the premium status of the words in the name. The PremiumList [58] is a lower price tier than the GoldList [56].

The PriceModel [60] defines a base price for ChannelNames [10] and uses multipliers in a multifactorial manner to determine a price for creating a Channel [03] based on the ChannelName [10].

A data structure in the Sui Move language (sui::bag module) is used in the treasury [37] to manage heterogeneous assets including $GLOW [08]. It offers O(1) access efficiency, enabling scalable and flexible asset management.

A unique identifier assigned to Content [72] stored on the Walrus [47]. Blob IDs [64] link on-chain metadata to off-chain data, ensuring secure and retrievable storage.

The Composer is an advanced application for NeoChannels [03] with intuitive tools by which to create, shape, curate and monetize Channel Content [24], by human means, or with the assistance of AI. Content [72] becomes fully programmable and granular. Each data segment is accompanied by Metadata. The Root [72] ownership of all fractions of derived content can be determined. Content [72] owners can mint NFTs for specific segments of their Root content [72] creating a new class of collectible. Segments of content from multiple Roots [72] can be combined in myriad ways and the combinations themselves can be tokenized. All the while content creators and content owners receive subscription payments for use of their content, or a predefined share of derived revenue, enforced through smart contracts. Creators can transfer full ownership of their creations or fractionalize ownership by creating shares, for example splitting ownership of a piece of content into 100 fractional NFTs. This enables collaborative investment in content creation and democratizes its monetization. Integrated with the scalable architecture of Sui, the Composer [66] supports high-throughput transactions for NFT minting and ownership transfers, positioning it as a hub for creative innovation in the area of tokenized content.

A tiered list of common words used in the PriceModel [60]. Higher tiers (more frequently used words) incur higher costs for the creation of ChannelNames [10] that use these words.

Root Content [72] is the first instance of a specific piece of Content [72] that is uploaded to Walrus storage [50] and for which a valid Ownership Claim [80] exists. The Ownership Claim [80] establishes provenance and ownership. It is subject to refutation by community processes. If there is no Ownership Claim [80], or if it is successfully refuted, Root Content [72] is referred to more precisely as Import Content [73] or as Weed Content [74]. This affects its ability to generate revenue and can have negative tokenomic consequences for the Channel [03].

Import Content is that subset of Root Content [72] for which no legitimate Ownership Claim [80] can or does exist. Import Content [73] is not claiming to be original. It is in some way derived from content that originated outside the system and yet is permitted to be in the system. Import Content can be replaced by Root Content [72] if the owner(s) of the Import Content [73] decide to and are able to upload their original content to a Channel [03] that they own.

Weed Content [74] is any Root Content [72] that is an unwelcome duplicate of content from within the Global Channel System [90] or from outside of it. Weed Content [74] may have negative tokenomic consequences for the Channel [03] and its reputation.

A Fragment [75] is Root Content [72] plus additional metadata that defines a range or portion of the Content [72]. It can have the status of Root Fragment [72] , Import Fragment [73] or Weed Fragment [74].

The term “Trigger” [76] is contextual. When Root Content [72] or a Fragment [75] are published to a NeoChannel [03], this Content [72] becomes a potential Trigger [76] for a cascade of other Relevant [78] material to be associated with it. In time based media such as video or audio, the Relevant [78] material may be associated with a precise moment of the timeline of the Trigger [76] Content [72].

A Relevancy [78] is Content [72] that may be associated with other Content [72] that has triggered a person or machine to associate it. For example it may be a response, a reaction, a comment, a note, or similar. The term Relevancy [78] refers to the relationship the piece of Relevant [78] content has to what Triggered it [76]. It is purely contextual. For example in a different context, a Relevancy [78] may be a Trigger [76] for a different set of Relevancies [78]. The set of all Relevancies [78] associated with a given portion of an experience or a given moment of a timeline is referred to in the UX as a “Slice”.

The relationship between Root Content [72] and subsequent Relevancies [78] is recorded on-chain using a data structure called the RelevancyGraph [79]. The RelevancyGraph organizes content into a directed graph (data structure), featuring both the Trigger [76] and the Relevancy [78] as identified by their Blob ID [64]. For each Relevancy [78] the Blob ID [64] of the Trigger content [76] is stored. If the Trigger [76] content is Root Content [72] then only this is stored. However if the Trigger content [76] was itself a Relevancy [78] to upstream content, then the Root Content [72] that began the cascade of Relevancies [78] is also stored.

An Ownership Claim [80] is a metadata attribute appended to Root Content [72] upon upload, establishing its provenance and enabling smart contracts to track and compensate owners for its downstream usage. Other forms of Ownership Claim [80] may be implemented, for example Ownership Claims [80] themselves may be tokenized.

NeoChannels [03] give rise to a new category of network and will have next generation governance. In vibrant_protocol “decorum” defines healthy rules of engagement, determined by the participants. There is a Constitution [84] for NeoChannels as a whole, and a Charter [85] for each NameCollection [01] (or the NameCollection [01] may simply default to the Constitution [84]). Taking actions against the constitution or local Charter [85] has tokenomic consequences. Violations can be reported by anyone in the network. However, each Channel can only make a very small number of reports each month. Reports that turn out to be petty and non-constructive can themselves result in tokenomic consequences for the reporter. There is a permissionless role called Arbiter [86]. Any Channel that is reported against can request for and pay for a review. Arbiters [86] gain a reputation based on the stability of the outcomes they achieve.

The constitution is a smart contract enabled document within vibrant_protocol [82] that enables the community itself to determine guidelines for constructive content. Aspects of the document evolve through feedback loops and community governance. Such evolution is slow and carefully considered.

A smart contract enabled document within vibrant_protocol [82] that further refines or modifies the Constitution [84] for certain NameCollections [01] and their communities.

There is a permissionless role called Arbiter [86]. Any Channel that is reported against for violations of the Constitution can request for and pay for a review. Arbiters [86] gain a reputation based on the stability of the outcomes they achieve.

There is a specialist role in the network called Guardians [88]. One role of Guardians is to work together to protect the constitution from becoming captured by processes that are not aligned with the values of the Network as a whole. The role of Guardian [88] may be honorary and subject to checks and balances.

The bottom up channel system that emerges from channel_protocol [22] and the set of all NeoChannels [03]. It is sometimes referred to as the Network. Note that upon NeoChannels [03] multiple networks may be created and multiple subnetworks may exist. These may be defined by NameCollections [01].

The Global Channel System [90] is one example of a broader concept referred to as a Decentralized Subscriber Network (DSN) [92]. DSNs may be conceived of that work in much the same way as the Global Channel System [90] but with different identity structures and a different purpose.

Integral to NeoChannels [03] is a framework called “Request For Content”. Using an application such as Glow [20], a NeoChannel [03] can request that Root Content [72] be sourced, curated or made. The request [94] becomes a smart contract. When a request is fulfilled, the creator or owner of the content transfers ownership to the requestor, but may maintain an ongoing royalty for revenues generated by that content. Whoever performs the task of curation may be paid in $GLOW, a smart contract executing upon delivery of the requested content.

On the roadmap is the ability to chat from one NeoChannel [03] to another. This ability is integral to the Request For Content framework [94] and may be AI assisted. Through Chat [96], Channel owners can request and negotiate for the content that they want or need, agreeing on pricing, timing and deliverables. Once terms are finalized, the chat history converts into a smart contract. This contract automates reimbursements, either releasing funds to the creator upon successful completion of work, or refunding funds to the buyer if conditions were not met. Creators develop a reputation for successful deliveries, and buyers for good faith negotiations. There are no intermediaries, the system is decentralized, all value goes to the creator of that value, minus protocol fees.

The Composer is an advanced application for NeoChannels [03] with intuitive tools by which to create, shape, curate and monetize Channel Content [24], by human means, or with the assistance of AI. Content [24] becomes fully programmable and granular. Each data segment is accompanied by Metadata [06]. The Root [72] ownership of all fractions of derived content can be determined. Content owners can mint NFTs for specific segments of their Root content [72] creating a new class of collectible. Segments of content from multiple Roots [72] can be combined in myriad ways and the combinations themselves can be tokenized. All the while content creators and content owners receive subscription payments for use of their content, or a predefined share of derived revenue, enforced through smart contracts. Creators can transfer full ownership of their creations or fractionalize ownership by creating shares, for example splitting ownership of a piece of content into 100 fractional NFTs. This enables collaborative investment in content creation and democratizes its monetization. Integrated with the scalable architecture of Sui, the Composer supports high-throughput transactions for NFT minting and ownership transfers, positioning it as a hub for creative innovation in the area of tokenized content.