In the Introduction to Highlight Smart Contracts, we introduced the four major problems we have solved with our smart contract architecture - cost, extensibility, provenance, and interoperability. We’re going to cover each of these in separate posts, starting with Extensibility.

However, before we explore each of these on the ground floor, let’s survey the entire Highlight protocol from a bird’s eye view. The protocol first went public on Polygon mainnet in November 2021, and has evolved into the system seen below.

Each colour represents a different collective of actions or data-storage functions occurring in the protocol.

Here are high-level rundowns of each core component:

Community

The Community smart contract is where community NFTs live. It’s made up of three portions:

1. The brain: an administrative interface that manages permissions and meta actions

2. The body: a modified template ERC1155

3. The rest: everything else a community needs to function, such as managing TokenManagers

While communities may support discrete ERC721s in the future, we chose the ERC1155 standard since it’s a superset of functionality provided by both ERC721 and ERC20, meaning it can support use-cases for both standards at once.

TokenManagers

Each token on the community is managed by a TokenManager, which are additional smart contracts that govern token configuration. They enable almost any conceivable token mechanism, and also let creators upgrade stale mechanisms for old tokens.

TokenManagers are the stars of each community. They enable creative use-cases, and are a large reason why each community can be considered as its own protocol (more on this in a future Extensibility post). Highlight is not a community protocol per-se, but rather a community-protocol-building protocol. How’s that for a tongue-twister!?

CommunityReadManagers

CommunityReadManagers manage community-wide parameters and functions that define core community configuration. They are swappable.

CentralPaymentsManager

The CentralPaymentsManager manages on-chain crypto purchases of community NFTs. They’ve been designed so that the UX of purchasing an NFT on Highlight is incredibly fast and user friendly (more on this in a future Cost post).

The CentralPaymentsManager serves as an execution layer that lets sellers update prices as frequently as they desire off-chain, while enabling buyers to atomically purchase an NFT completely gas-free in one step. One of our innovations here is that buyers don’t have to approve the CentralPaymentsManager to move their ERC20 currencies such as wETH or USDC. This increases security compared to most other dApps that offer unrestrained and indiscriminate approval. It also decreases purchase latency.

Royalties

The Royalties receiver and Royalties manager smart contracts are forks of 0xSplits contracts that were modified to suit the Highlight protocol. When community NFTs are purchased on external marketplaces, royalties are sent to the royalty receiver contracts via community-level metadata or ERC-2981. These are allocated and distributed to a configurable set of royalty recipients later, such as the community creator, community members, and Highlight.

PermissionsRegistry

The PermissionsRegistry enables O(1) management of system-wide configurations, such as permissioned platform EOAs and whitelisted currencies.

APIProxy

The APIProxy is a multi-call gateway API that wraps multiple on-chain function calls into one to improve the performance and UX of the platform.

CommunityFactory

The CommunityFactory enables new community setup in multiple different configurations. The factory employs some pretty interesting tricks we built to solve problems concerning immediate interoperability with the wider ecosystem (more on this in a future Interoperability post).

GlobalTokenManagers

GlobalTokenManagers are a separate type of TokenManager that can be used to save gas, if the tokens they manage employ simpler mechanisms.

Administrative Security

Finally, it’s important to note that Highlight employs 6 separate smart contract wallets to protect various administrative vectors across the system. Any remotely powerful system permission is protected via a multi-sig wallet, although communities are largely unaffected if any of these are somehow exploited. As we will explore in a future Provenance post, Highlight communities are securely governed by the creator and whomever they choose.

An apt analogy for the Highlight protocol is the solar system.

The Sun represents system smart contracts such as the Beacon, PermissionsRegistry, Royalties manager, CentralPaymentsManager, and more.

The planets are the communities themselves, built by each creator.

The moons are “orbiter” contracts such as the TokenManagers and the CommunityReadManager, that shape planet behaviour.

As of June 2022, most communities look like Mars, but as communities mature and creators terraform their planets by building more complex governance and infrastructure, we expect many Jupiter-like communities. Creators can create new moons, modify/swap existing ones, merge with other planets, and much more. Communities can even leave the solar system entirely.

While the Sun is useful for giving birth to the planets, creators are not beholden to Highlight. Creators are free and able to accelerate their planets out of orbit, losing our platform support to wander the cosmos independently.

Now that we’ve briefly traversed the protocol, we’re going to dive deep on each of Extensibility, Cost, Provenance, and Interoperability. In these pieces, we’ll also explore how our protocol design enables higher-level themes:

1. Gradual decentralization

2. How to build, enhance, engage, and govern your own communities on-chain

3. Creative gamification

Explore the protocol directly here. Interested in working on cutting edge smart contract architecture and web3 infrastructure? We’re hiring.

In the Introduction to Highlight Smart Contracts, we introduced the four major problems we have solved with our smart contract architecture - cost, extensibility, provenance, and interoperability. We’re going to cover each of these in separate posts, starting with Extensibility.

However, before we explore each of these on the ground floor, let’s survey the entire Highlight protocol from a bird’s eye view. The protocol first went public on Polygon mainnet in November 2021, and has evolved into the system seen below.

Each colour represents a different collective of actions or data-storage functions occurring in the protocol.

Here are high-level rundowns of each core component:

Community

The Community smart contract is where community NFTs live. It’s made up of three portions:

1. The brain: an administrative interface that manages permissions and meta actions

2. The body: a modified template ERC1155

3. The rest: everything else a community needs to function, such as managing TokenManagers

While communities may support discrete ERC721s in the future, we chose the ERC1155 standard since it’s a superset of functionality provided by both ERC721 and ERC20, meaning it can support use-cases for both standards at once.

TokenManagers

Each token on the community is managed by a TokenManager, which are additional smart contracts that govern token configuration. They enable almost any conceivable token mechanism, and also let creators upgrade stale mechanisms for old tokens.

TokenManagers are the stars of each community. They enable creative use-cases, and are a large reason why each community can be considered as its own protocol (more on this in a future Extensibility post). Highlight is not a community protocol per-se, but rather a community-protocol-building protocol. How’s that for a tongue-twister!?

CommunityReadManagers

CommunityReadManagers manage community-wide parameters and functions that define core community configuration. They are swappable.

CentralPaymentsManager

The CentralPaymentsManager manages on-chain crypto purchases of community NFTs. They’ve been designed so that the UX of purchasing an NFT on Highlight is incredibly fast and user friendly (more on this in a future Cost post).

The CentralPaymentsManager serves as an execution layer that lets sellers update prices as frequently as they desire off-chain, while enabling buyers to atomically purchase an NFT completely gas-free in one step. One of our innovations here is that buyers don’t have to approve the CentralPaymentsManager to move their ERC20 currencies such as wETH or USDC. This increases security compared to most other dApps that offer unrestrained and indiscriminate approval. It also decreases purchase latency.

Royalties

The Royalties receiver and Royalties manager smart contracts are forks of 0xSplits contracts that were modified to suit the Highlight protocol. When community NFTs are purchased on external marketplaces, royalties are sent to the royalty receiver contracts via community-level metadata or ERC-2981. These are allocated and distributed to a configurable set of royalty recipients later, such as the community creator, community members, and Highlight.

PermissionsRegistry

The PermissionsRegistry enables O(1) management of system-wide configurations, such as permissioned platform EOAs and whitelisted currencies.

APIProxy

The APIProxy is a multi-call gateway API that wraps multiple on-chain function calls into one to improve the performance and UX of the platform.

CommunityFactory

The CommunityFactory enables new community setup in multiple different configurations. The factory employs some pretty interesting tricks we built to solve problems concerning immediate interoperability with the wider ecosystem (more on this in a future Interoperability post).

GlobalTokenManagers

GlobalTokenManagers are a separate type of TokenManager that can be used to save gas, if the tokens they manage employ simpler mechanisms.

Administrative Security

Finally, it’s important to note that Highlight employs 6 separate smart contract wallets to protect various administrative vectors across the system. Any remotely powerful system permission is protected via a multi-sig wallet, although communities are largely unaffected if any of these are somehow exploited. As we will explore in a future Provenance post, Highlight communities are securely governed by the creator and whomever they choose.

An apt analogy for the Highlight protocol is the solar system.

The Sun represents system smart contracts such as the Beacon, PermissionsRegistry, Royalties manager, CentralPaymentsManager, and more.

The planets are the communities themselves, built by each creator.

The moons are “orbiter” contracts such as the TokenManagers and the CommunityReadManager, that shape planet behaviour.

As of June 2022, most communities look like Mars, but as communities mature and creators terraform their planets by building more complex governance and infrastructure, we expect many Jupiter-like communities. Creators can create new moons, modify/swap existing ones, merge with other planets, and much more. Communities can even leave the solar system entirely.

While the Sun is useful for giving birth to the planets, creators are not beholden to Highlight. Creators are free and able to accelerate their planets out of orbit, losing our platform support to wander the cosmos independently.

Now that we’ve briefly traversed the protocol, we’re going to dive deep on each of Extensibility, Cost, Provenance, and Interoperability. In these pieces, we’ll also explore how our protocol design enables higher-level themes:

1. Gradual decentralization

2. How to build, enhance, engage, and govern your own communities on-chain

3. Creative gamification

Explore the protocol directly here. Interested in working on cutting edge smart contract architecture and web3 infrastructure? We’re hiring.