In web3, more data == more problems.

Why?

Because blockchains are terrible for data storage, and thus most dApps forgo utilizing any user data. This leads to a degraded user experience where:

1. Authentication wholly relies on private keys, not people’s identities

2. Technical complexity in connecting multiple services requires users to sign numerous messages

3. Authorization is granted based on predefined rules instead of dynamically shared capabilities

4. Permissions cannot be applied across multiple execution environments, i.e. Ethereum, Optimism, Polygon, Fuel, Celestia, etc.

5. Dapps cannot recognize a user with multiple wallets

6. Users aren’t notified when important events are emitted

These complications are hard on both users and developers. Users have a hard time understanding what they’re signing and expressing their intentions to an dApp, and developers struggle with the technical complexities of connecting multiple services.

Decentralized identity and data storage layers have emerged as the leading solution to web3’s data problem, but interoperability between these off-chain resources and on-chain actions remains unsolved. 

We are introducing the Trust Anchor Gateway (TAG) architecture to bridge off-chain data and on-chain access controls, so developers can build seamless user experiences that are private and secure for their users. Designed to be lightweight and flexible, a TAG provides a path forward for using verifiable credentials and other off-chain information to generate just-in-time access controls for smart contracts.

In this article, we’ll explain:
1. What is a just-in-time (JIT) access control
2. Why use a Trust Anchor Gateway
3. How District builds for access controls at scale

What is a JIT Access Control

A JITAccessControl is a method of granting real-time granular access to an application or resource to perform a task. Instead of giving always-on access (standing access) to a resource, JITAccessControls allow developers to limit access to a specific time frame, mitigating the risk of privileged account abuse.

In the web3 context, the JITAccessControl is executed via a signed delegation and invocations using the Delegatable framework. Delegatable uses a combination of new and existing smart contract patterns (meta-transactions, nonce-queues and caveat enforcers) to establish a smart contract implementation of executable transaction conditionals.

Executable transaction conditionals (via caveat enforcers) enable the expression of intentions via rules and conditions for when a transaction can be executed without a prior write to a smart contract’s storage. This is the opposite approach to the one taken by many of today’s smart contract permissions and access control systems like AccessControl.sol in OpenZeppelin, NFT minting whitelists, DAO resources (Moloch, Aragon, etc.) which all require prior interactions with a blockchain before an Account is granted permissions to a resource.

In other words, without a direct write to the blockchain, JITAccessControls enable TrustAnchorGateways to enforce when a transaction should execute: between timestamp ranges, only if a user has an ENS domain, if a user holds a specific Soulbound item, etc...

Why use a Trust Anchor Gateway (TAG)

The TAG architecture is designed to be a horizontally scalable solution for generalized permissions systems in a multi-blockchain world. The design builds upon the long-standing concepts behind Trust Anchors, Web of Trust, Public Key Infrastructure, Self-sovereign Identity, and the more recently ratified W3C Verifiable Credential specification, and applies them to the web3 context.

Like Trust Anchors in a Web of Trust, a TAG acts as an arbiter of truth when migrating data between environments (physical and digital) which cannot easily be done using cryptographically verifiable methods. Simply put, the TAG is a trusted intermediary when it’s impossible to create a link from statement to cryptographically verifiable statement, attesting to the truth (or expressed truth) about a fact of the physical/digital world.

The structure allows a TAG to provide just-in-time on-chain access controls, bridging the gap between off-chain data and resources, like self-sovereign identity or verifiable credentials, and on-chain smart contract actions like lending in a permissioned pool or minting an NFT. 

Instead of relying on smart contract registries to manage permissions, which are inherently unscalable in a multi-chain and multi-execution environment world, users are given access to smart contracts via JITAccessControls which can be codified with dynamic rules and conditions at the time of issuance.

This greatly expands the scope of what’s possible on-chain, including fully permissioned DeFi that marries institutional-grade compliance standards with code-enforced transparency, permissioned liquidity pools that are compliant with KYC/AML standards, and unified user experiences across blockchains and wallets.

Dynamic Permissions & Access Controls

What’s most unique about Trust Anchor Gateways is the ability to define dynamic and complex rules for when and how a transaction should be executed.

Execution rules are encoded inside Delegations (off-chain) and validated at run-time i.e. when the transaction is being executed. The conditional transaction execution rules rely on modular and composable enforcers responsible for “enforcing” a very specific conditional:

• Before/After/Between Timestamps

• Before/After/Between Block Numbers

• ERC20 Token Spending Allowance

• Account has ownership of 5 unique NFTs

• Governance proposal outcomes (Pass/Fail)

• And much more!

Trust Anchor Gateways have flexibility when it comes to defining conditional transaction execution rules. This is because enforcers can easily be composed together i.e. dynamic access controls without redeploying smart contracts or re-architecting the underlying protocols permissioning system, when it’s time to introduce new execution conditionals.

The conditional transaction execution pattern unlocks a new product development space for sybil resistant smart contracts. Specifically smart contracts that require just-in-time access controls and fine-tuned permissions systems using dynamic off-chain authentication systems.

Delegations enable privacy preserving features like using new/unfunded wallets to perform on-chain actions, but have been verified off-chain using decentralized identifiers and verifiable credentials.

TrustAnchorGateways can also be privacy preserving by default. Decoupling a “root” account which has been issued Verifiable Credentials and “leaf” accounts which are given the JITAccessControl to take actions unlocked by the root accounts VCs. 

Instead of a single account (which is simply bad operational security) granted permissions across many different services, and leaving an easily traceable digital footprint, a TrustAnchorGateway is able sign JITAccessControls for “leaf” accounts also owned by the “root” account, but which have no direct correlation on-chain. Allowing a User to access a cryptographically secured resource, without revealing to the world who they are or why they have these permissions/credentials.

Delegatable’s caveat enforcer pattern will change how we handle everything from DAO resource management to institutions integrating KYC into their decentralized finance flows.

Modularity and composability are incredibly powerful. Creating space for experimentation and growth.

TrustAnchorGateway Networks.

A Trust Anchor Gateway can act alone or it can be part of a network. 

Why join a TAG network?

Security.

If a smart contract relies on a single off-chain TrustAnchorGateway and that TAG is compromised (or starts to act maliciously) the smart contract inheriting it’s security from the gateway is also compromised.

But, if a smart contract inherits security from a network of TrustAnchorGateways, and the TAGs also operate independently, the ability for a bad actor to compromise the smart contract’s access control system is greatly diminished, because it becomes exponentially more difficult to compromise multiple (professionally operated) TrustAnchorGateways.

How District Builds for Access Controls at Scale

A Trust Anchor Gateway is designed to sit between a Decentralized Identity Gateway, like Disco, and public blockchains execution environments like Ethereum and Optimism.

With access to a private key (EVM Account) the Trust Anchor Gateway is able to sign valid Ethereum transactions. 

The transactions, using the Delegatable framework, are encoded with conditional transaction execution rules using counterfactual statements. Or put more simply, the TAG can issue JITAccessControls with bounded rules, like the transaction must be submitted between two timestamps or before/after a specific block number without ever requiring a direct write to smart contract storage before the transaction is submitted.

Conclusion

The underlying capabilities (inherited from Delegatable framework) of TrustAnchorGateways emulates properties found in planned Ethereum upgrades like EIP-4337: Account Abstraction.

When native account abstraction support arrives, the TrustAnchorGateway patterns and networks will be directly applicable and the enforcer pattern underpinning Delegatable will supercharge native Account Abstraction. 

How? 

Individual accounts can instantly gain access to advanced social recovery and dead-man switch infrastructure via established TrustAnchorGateway networks. We see a future world where TrustAnchorGateways help onboard 1,000,000’s of Users into Web3, because we make it easy, safe and scalable for the everyday user to experience the power of decentralized technologies, without sacrificing security and sovereignty.

Why is this important? 

TrustAnchorGateways are designed to grow in complexity overtime.

Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

In the future TrustAnchorGateways can include threshold cryptography, multi-party compute, zero-knowledge proofs, plus other combinations of yet to be discovered cryptographic ceremonies for constructing decentralized and distributed access control systems… once the hard work of finding product market fit is complete.

Right now Districts Labs is focused on bringing verifiable credentials into blockchain execution environments without sacrificing privacy. Taking into account the constraints/standards we have today, while also preparing to meet the demands of tomorrow. 

District Labs is preparing for this future (millions of Web3 users) by creating the infrastructure, networks and protocols for a safe, secure and scalable User experience in a decentralized world.

Ready to join us?

Learn more at www.DistrictLabs.com

Authors,

Kames Geraghty, CTO at District Labs

Justin Bassey, CEO of District Labs