Like the Internet, the blockchain was developed to create an anti-fragile system resilient to centralized issuance and control. Take down or corrupt any node in the system, and messages or transactions can still be trusted to execute as intended.

The convergence of these technologies has given us web3, where data is stored in the fabric of the internet itself and information is owned and managed by users rather than applications.

This paradigm shift creates new challenges for users who are increasingly responsible for managing the flow of information online, but lack the tools to govern how their data is shared. In other words, even though web3 allows people to own their information, it’s hard for them to understand who can see it or if it’s even safe.

Web3 Identity & Data Ownership

As web3 scales beyond self-contained ecosystems to interoperate with other chains, data, and resources, identity plays an increasingly important role in ensuring a consistent and secure experience.

In web2, interoperability was primarily enabled by federated identity, in which information stored across separate identity management systems are linked together. Under this model, authentication, authorization, and personal data are managed centrally by organizations and services rather than the individual to whom it belongs.

Web3 flips this dynamic in favor of self-sovereign identity (SSI) that gives individuals full ownership and control of their digital identities and how their personal information is shared and used.

This identity includes on-chain information like what tokens or NFTs you own, as well as off-chain data like verifiable credentials and other private information. Collectively, the data builds a digital identity that can be used to access restricted resources or prove a claim across environments.

Because users are in full control of how and what data is being shared, SSI creates a decentralized and definitive mechanism for establishing trust between users and applications while preserving individual privacy.

However, while SSI has the potential to upend the internet’s approach to identity and access management, it also has the potential to make things much more complex for users and developers alike.

Everything Needs Permission

Authorization and permission management is the single most important factor in web3 security that’s rarely talked about. Every contract, dApp, and transaction requires authorization from an account before it can interact with its users’ funds or data store. 

Take Uniswap as an example. Just to provide liquidity, users need to sign two permissions before depositing their tokens into a pool. Worse still, Uniswap and many other dApps request an unlimited allowance from the user such that the smart contract doesn’t need further permissions to perform actions with the user’s tokens. 

This is a conscious tradeoff that developers make, sacrificing security for usability. In doing so, web3 developers expose their users to unnecessary risk. Software is notoriously soft, and there’s no such thing as perfectly written code. Bugs and exploits can happen even in established projects and by requesting unlimited allowances, dApps not only expose deposited balances to theft, but also the tokens held “safely” within users’ wallets.

At a high level, everything in crypto is about authorization and permission management. Smart contracts and decentralized applications are programs that define arbitrary rules for ownership, transactions, and execution conditions. In many cases these functions are fully permissionless (i.e., anyone is free to interact with the code), but still require authorization to administer their tasks.

More advanced use cases require fine-grained access controls to function at scale. For example, how might a tokenless DAO conduct governance or provide access to on-chain resources exclusively to its members? How can a lending pool limit access to only KYC’d individuals or institutions? How do fans give creators permission to charge them a monthly subscription on-chain? 

These are complex conditions that require a mix of on and off-chain data to function properly. Moreover, the potential value capture and compliance necessities make these high-stakes commitments that developers and communities can’t afford to get wrong. 

To-date, the only solution for implementing this manner of access controls has been via whitelists. But whitelists lack the dynamism to function at scale. Anyone who’s managed a whitelist before knows that they are a frustratingly analog process that is prone to error. Nevertheless, we see them being used for NFT drops, organization management, and permissioned pools despite their significant drawbacks. 

We’re building District to solve the permissions layer of web3. There doesn’t need to be a tradeoff between functionality, security, and usability. The best security measures allow for seamless protection while enhancing user experience. In creating the next generation identity and access management protocol, we strive to improve web3 security and experiences without compromising on privacy. 

Welcome to District

District is the easiest way to improve the security and usability of web3 applications. We are laying the foundation for universal authorization based on user-controlled data and are excited to introduce fine-grained access controls to web3. 

Because web3 inverts the data ownership paradigm of the internet, we had to rethink identity and access management from the ground up. Cryptographic signatures make user authentication trivial, but few mechanisms exist to govern authorization.

Traditionally, authorization was done using access controls lists (ACLs) in which a list of rules specifying which users or systems are granted access to objects determines authorization. However this model is incompatible with smart contracts as it doesn’t support dynamically changing permissions well and is hard to control programmatically, resulting in both security and scalability issues.

Instead, District’s access control model is based on object capabilities (ocaps). In the ocaps model, authorization is managed by creating, sharing, signing, and invoking “capabilities” instead of relying on a list of rules. If you have a valid capability, you have the authorization to use it.

These capabilities can be chained together, allowing for the delegation of authority and “caveats” can be attached to restrict the scope of its use, for example enabling revocation, limiting access to between specified block numbers, or a range of other conditions. 

The structural properties of District’s access control model allow for fine-grained authorizations to be made, while adhering to the principle of least authority. This allows users to grant applications just enough authorization to execute seamlessly, while maintaining a high level of security. 

Going back to our Uniswap example, a user could delegate the Uniswap smart contracts a token allowance of up to 10 ETH per month until blockNumber 24,000,000, enabling Uniswap to maintain the same user experience of the unlimited allowance method, while minimizing the attack surface in the case of an exploit.

District unlocks these fine-grained authorizations through accessible building blocks that make it simple for developers and their applications to request and manage permissions. With our secure APIs and SDKs, developers can build more secure dApps with better user experiences quickly.

What’s Coming Next

For the past several months, we’ve been working on delegatable, an open source framework pioneered by the team at Metamask. Delegatable is a set of tools enabling delegation on Ethereum and is designed to address a number of challenges with EVM transactions ahead of native account abstraction support.

While delegation currently acts as the core of District’s access control model, the framework supports other high order functions like transaction bundling, meta-transactions, and subscriptions that we are bringing to market soon.

Our team is already working on several exciting partnerships to integrate District, and we can’t wait to show you how we’re helping apps improve their functionality, security, and usability.

Our mission is to make every transaction safe, secure, and human. If you’re building an application on Ethereum, let’s talk.

- DISTRICT TEAM