# Why Functor Network?

Web3’s path to programmable, cross‑chain finance is blocked by one root cause: **signer fragmentation**.

**Smart‑account wallets** improve UX, yet each new chain gives the same user a different signer with different permissions. Those signers are **not composable** across chains, which breaks key management, creates inconsistent approvals, and blocks interoperable automation.

Functor Network is building a **keystore layer**, a **minimal zk-rollup** of signers that any **ERC‑7579 validator module** can query. By eliminating fragmented signer state while preserving **self‑custody**, Functor provides the **uniform authorization layer** smart accounts need to operate seamlessly across the ecosystem.

* **One signer** set usable on any new chain at wallet creation
* A single, **Ethereum‑anchored root** for **global key revocation, recovery**, and **programmable** **permissions**
* **Cross‑chain operations** that execute under the **same authorization rules** with **no extra approvals**

***

### Problem 1: Signer Fragmentation Crisis <a href="#problem-1-signer-fragmentation-crisis" id="problem-1-signer-fragmentation-crisis"></a>

Smart accounts are on the rise, but every chain and every account instance adds another **isolated signer set**.

* **Permissions drift** across L2s and apps, which leads to inconsistent security posture
* **Global revocation and recovery** are hard or impossible to enforce across environments
* **Operational overhead** multiplies with each new chain, degrading UX and increasing risk

Without a **dedicated signing layer**, Ethereum cannot safely scale to multichain usage or support **autonomous systems** with **consistent policy**.

***

### Problem 2: Interoperable User Experience Gap <a href="#problem-2-interoperable-user-experience-gap" id="problem-2-interoperable-user-experience-gap"></a>

What users want is simple. **One identity. One set of permissions.** Predictable approvals and recovery that work the same everywhere. Today they get the opposite.

* Each L2 and each deployment creates a **separate signer** with different permissions
* **Approvals and access controls do not travel** with the user
* **Recovery and revocation differ** by chain, which leads to **blind signing** and uncertainty

Functor Network closes this gap with a **keystore layer** that smart accounts can query directly.

* **Minimal zk rollup of signers** that **ERC‑7579** validator modules can use for authorization
* **Wallet creation** with a **single signer set** that is instantly usable on any new chain
* **Security anchored to Ethereum** for **global revocation**, **recovery**, and **programmable permissions**
* **Multichain automation** where actions follow the **same rules across chains**, with **no extra approvals**

This establishes the **interoperable UX layer** that makes smart accounts truly portable and safe.

***

### Problem 3: Cross-Chain Automation Barriers <a href="#problem-3-cross-chain-automation-barriers" id="problem-3-cross-chain-automation-barriers"></a>

Automation fails without **consistent authorization**. Strategies and agents need to act across chains under one policy. Today that is not possible.

* Agents cannot safely hold **private keys**, yet they need **signing capability**
* Execution rules and approvals differ per chain, which blocks coordinated strategies
* **Fragmented capital** persists. **$200B+ in DeFi** cannot move programmatically under one set of permissions

**Uniform authorization** is the prerequisite. With a **keystore layer anchored to Ethereum**, the **same policy everywhere** can govern activity. Cross‑chain operations can execute programmatically, under **consistent rules**, without manual coordination or new approvals at every step.

***

### Why now?

* **L2 proliferation** and **smart‑account adoption** are accelerating, which magnifies signer fragmentation
* **ERC‑7579** validator modules and **Pectra** move smart accounts toward first‑class status, creating the interface and momentum for a shared signing layer
* The rise of **AI‑driven** and **institutional** workflows creates immediate demand for secure, programmable, **self‑custodial authorization** that spans chains
* Industry efforts such as **Trillion Dollar Security** underscore UX in **key management** as a core blocker, reinforcing the need for foundational keystore infrastructure

***

### Potential Ecosystem Benefit

A **one‑signer network** for infinite chains removes the **key‑management bottleneck** and upgrades UX and security at the same time.

* **Chain‑agnostic wallet creation and recovery**
* **Consistent approvals** and **permission management** across L2s
* **Reduced blind signing** and clearer transaction intent
* **Composable authorization** that enables safe, **cross‑chain automation**

***

See [how](/functor-network-docs/overview/how-is-functor-enabling-the-onchain-autonomous-world.md) Functor is solving all of these.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://functor.gitbook.io/functor-network-docs/overview/why-functor-network.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
