# Highlight Smart Contracts: A Brief Overview By [Highlight](https://paragraph.com/@highlight) · 2022-07-11 --- In the [Introduction to Highlight Smart Contracts](https://mirror.xyz/highlightxyz.eth/5-9CWoSJ920Cke4RF2qZoGDs0ZDa0bZTAU2f4knuwNk), 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_](https://mirror.xyz/highlightxyz.eth/1DEwFVQAf3KebNClNC391M4m0dIJPA2lZiiwAtaInHo). 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. ![While this diagram is not exhaustive (for example, some contracts are clones so an implementation / proxy pair is missing), it displays all the fundamental concepts](https://storage.googleapis.com/papyrus_images/7bc5c8b4973bc757fe1d5b2bb62ff324181ef34878e305fe432c14b3558f3aa3.png) While this diagram is not exhaustive (for example, some contracts are clones so an implementation / proxy pair is missing), it displays all the fundamental concepts 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_](https://mirror.xyz/highlightxyz.eth/1DEwFVQAf3KebNClNC391M4m0dIJPA2lZiiwAtaInHo) 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_](https://mirror.xyz/highlightxyz.eth/eiaIFwd8hTiMo-A0NO31hGi9NgfiN372Orpp-DFw03A) 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](https://www.0xsplits.xyz/) 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_](https://mirror.xyz/highlightxyz.eth/_GInQwmxPBFmiqKRjK7pnu7-pKhUoqYyluKH_DeiBak) 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_](https://mirror.xyz/highlightxyz.eth/_GInQwmxPBFmiqKRjK7pnu7-pKhUoqYyluKH_DeiBak) post, Highlight communities are securely governed by the creator and whomever they choose. Into the Cosmos 🚀 ------------------ An apt analogy for the Highlight protocol is the solar system. ![](https://storage.googleapis.com/papyrus_images/ed91a384ea55012b6e5717369b8d72d19901ec32f96ce74e595bfcb2e54bf88a.jpg) 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_](https://mirror.xyz/highlightxyz.eth/1DEwFVQAf3KebNClNC391M4m0dIJPA2lZiiwAtaInHo), [_Cost_](https://mirror.xyz/highlightxyz.eth/eiaIFwd8hTiMo-A0NO31hGi9NgfiN372Orpp-DFw03A), [_Provenance_](https://mirror.xyz/highlightxyz.eth/_GInQwmxPBFmiqKRjK7pnu7-pKhUoqYyluKH_DeiBak), and [_Interoperability_](https://mirror.xyz/highlightxyz.eth/_GInQwmxPBFmiqKRjK7pnu7-pKhUoqYyluKH_DeiBak). 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](https://github.com/highlightxyz/hl-contracts). Interested in working on cutting edge smart contract architecture and web3 infrastructure? We’re [hiring](https://highlight.xyz/jobs/). --- *Originally published on [Highlight](https://paragraph.com/@highlight/highlight-smart-contracts-a-brief-overview)*