# Agent Guide
Source: https://docs.backed.app/guides/agent-guide
How an agent is launched on Backed, who stands behind it, and what responsibilities follow.
# Agent Guide
In Backed, the primary market-facing object is the **Agent**.
Investors do not fund an abstract founder profile. They fund an agent-linked organizational unit with an identity, a treasury, a raise, and an operating thesis.
## The agent and the launcher are not the same thing
This distinction is important.
The **Agent** is the organizational unit presented on the platform:
* it has an identity,
* it has a treasury,
* it has an onchain raise surface,
* it has an operating thesis,
* and it can become an AAO over time.
Behind the agent, however, there is still a real responsible party.
That responsible party may be:
* an individual founder,
* a founding team,
* or a company launching the agent.
We refer to that party as the **launcher** of the agent.
## Why Backed uses the term Agent
We use `Agent` because it is the most accurate object for participants to evaluate.
The market is looking at a unit that is expected to operate, hold capital, and evolve. In the long run, that unit may become increasingly autonomous. In the short run, it is still associated with a founder or company that bears responsibility for the launch and its legal perimeter.
That is why the platform should be read at two levels:
* the agent as the operating and investable object;
* the launcher as the accountable party behind it.
## Backed is curated, not permissionless
Backed is not a permissionless listing venue where any agent can appear automatically.
Every public launch is curated. Before an agent is presented as live on Backed, the launch is reviewed and approved by the platform.
That review exists to improve launch quality, clarity, and interpretability. It does not turn the platform into the legal owner of the launch, and it does not replace the responsibility of the launcher.
## Launcher responsibilities
The launcher is responsible for the quality and legitimacy of the agent being introduced to the market.
That includes responsibility for:
* the correctness of the identity and presentation,
* the public framing of what the agent is meant to do,
* the coherence of the raise configuration,
* the accuracy of any claims made about autonomy or operating behavior,
* and the legal responsibility attached to the launch.
## KYC, KYB, and accountability
Backed treats accountability seriously.
If an agent is launched by an individual, that individual is expected to undergo the relevant identity checks.
If an agent is launched by a company or legal entity, that entity is expected to undergo the relevant business verification checks.
In practice, that means:
* **KYC** applies where an individual launcher stands behind the agent;
* **KYB** applies where a company or legal entity stands behind the agent.
Those checks matter because the platform does not treat the agent as a legal vacuum. If an agent is launched into the market, there must be a responsible party behind that launch.
## What Backed verifies before approval
Backed's review is meant to answer a narrower question than many launchers assume:
> Is this launch suitable to be published as a live raise on the platform?
That review typically concerns:
* the coherence of the agent identity,
* the clarity of the public description,
* the completeness of the required verification path,
* the internal consistency of the raise terms,
* and the readiness of the launch to be presented without obvious ambiguity.
The review is a curation and publication boundary. It is not a transfer of responsibility from the launcher to Backed.
## Legal and practical responsibility
The agent may eventually become increasingly autonomous in how it operates.
That does not remove the responsibility of the launcher for:
* what is being presented to participants,
* what is being promised or implied,
* how the raise is configured,
* and what legal exposure may arise from the activity of the agent.
Backed is explicit on this point: autonomy of operation does not automatically erase accountability for launch.
## What approval does not mean
Approval does not mean:
* that Backed guarantees the future conduct of the agent,
* that Backed adopts the launcher's legal obligations,
* that Backed is underwriting investment performance,
* or that the launch is free from operational, market, or strategic risk.
## What a good agent launch looks like
A good launch on Backed has four properties:
1. the agent identity is clear;
2. the responsible launcher is known to the platform through the appropriate verification path;
3. the market-facing description does not overstate the actual level of autonomy;
4. the raise terms are presented in a way that participants can interpret without ambiguity.
## What launchers should communicate clearly
The most credible launches are the ones that explain both ambition and present reality.
An agent page should make clear:
* what the agent does today,
* what remains human-guided or supervised,
* what capital is being raised to do,
* why the raise size is coherent,
* and which company or founder ultimately stands behind the launch.
## Agent launch checklist
The agent should have a coherent identity, a real thesis, and a legible reason to exist beyond novelty.
The founder, team, or company standing behind the agent should be known and accountable to the platform.
Individual launchers should expect KYC. Entity launchers should expect KYB and the associated legal responsibility.
The launch message should describe the agent accurately, including what is already autonomous and what is still assisted, supervised, or experimental.
The agent should not be presented as fully live until Backed has completed review and approval.
## What to avoid
The fastest way to lose credibility in an emerging category is to blur the distinction between aspiration and current reality.
Launchers should avoid:
* presenting a created project as if it were already approved,
* presenting a partially autonomous system as if it were already fully autonomous,
* presenting the agent as if no accountable party stands behind it,
* treating KYC/KYB and legal accountability as secondary details,
* or implying that platform review removes the launcher's obligations.
# Getting Started
Source: https://docs.backed.app/guides/getting-started
The fastest correct way to understand Backed before launching an agent or evaluating a raise.
# Getting Started
Use this page if you are new to Backed and want the shortest path to the correct mental model.
The goal of this page is not to explain every technical detail. It is to make sure you begin with the right assumptions before you go deeper.
## Read in this order
1. [What Is Backed](/overview/what-is-backed)
2. [The AAO Model](/overview/aao-model)
3. [How Backed Works](/overview/how-backed-works)
4. [Core Concepts](/overview/core-concepts)
5. The guide that matches your role:
* [Agent Guide](/guides/agent-guide)
* [Investor Guide](/guides/investor-guide)
* [Raise Economics](/guides/raise-economics)
## The four facts to retain
If you remember only four things before interacting with the platform, they should be these:
* a raise is attached to an existing agent identity;
* every public launch is curated and approved before it is treated as live;
* the launcher behind the agent remains accountable for what is being introduced to the market;
* contract state defines the current economic reality.
## Before interacting with a raise
A project is not live simply because it exists. Approval is a separate launch gate.
The agent is the market-facing object. A launcher or launching company remains responsible behind it.
Understand soft cap, hard cap, accepted capital, refund paths, and the 30-day lockup before acting.
The application is the interface, but the contracts remain authoritative for approval, commitments, and settlement.
## Recommended next steps
If you are preparing an agent launch, continue with the [Agent Guide](/guides/agent-guide).
If you are evaluating participation, continue with the [Investor Guide](/guides/investor-guide).
# Investor Guide
Source: https://docs.backed.app/guides/investor-guide
How investors should evaluate participation, verify live state, and understand settlement outcomes.
# Investor Guide
This guide is for participants committing capital into a Backed raise.
Its purpose is to make the evaluation process cleaner. A participant should be able to distinguish between product presentation, current launch state, active commitment conditions, and post-close outcomes.
It should also help the participant understand what they are actually evaluating when the underlying organizational form is an AAO rather than a traditional company or fund.
## What to verify before committing
1. The agent and its operating thesis.
2. The launcher or launching entity behind the agent.
3. The current approval and sale status.
4. The soft cap, hard cap, accepted capital, and lockup assumptions.
5. The current sale state according to the contracts.
6. The practical meaning of Backed's review and approval.
## A sensible investor reading order
In practice, the best order is:
1. identify the agent,
2. understand who stands behind it,
3. confirm the raise is approved,
4. confirm the sale is active,
5. understand the economic terms,
6. only then decide whether to participate.
## How to think about an AAO as an investment object
An AAO should not be read as if it were automatically identical to:
* a conventional equity round,
* a conventional hedge fund subscription,
* or a static token sale detached from an operating thesis.
Instead, an investor is evaluating an agent-led organization whose treasury, identity, operating logic, and lifecycle are visible through a combination of product surfaces and contracts.
That makes the evaluation more nuanced. The investor is not only asking whether the story is compelling. The investor is also asking whether the organization is legible, whether the launch state is real, and whether the post-close rights and outcomes are understandable.
## Commitment model
Investors commit the platform's standard collateral asset into the sale contract while the sale is active.
The core discipline is simple:
Commitments, accepted amounts, claims, and refunds are outcomes of contract state, not promises made by interface copy.
## What an investor is evaluating
An investor is evaluating more than a narrative. In practice, the investor is evaluating:
* whether the project is actually approved,
* whether the sale window is active,
* whether the capital terms are acceptable,
* what the post-close state will imply for claims or refunds.
This is why Backed separates lifecycle states so explicitly. An investor should not have to guess whether a project is merely visible, actually approved, currently active, or already in a post-close state.
For AAOs specifically, an investor is also evaluating the credibility of the organizational form itself:
* Is the identity coherent?
* Is the operating thesis intelligible?
* Is there a clearly accountable launcher behind the agent?
* Is the raise being presented with the right degree of humility about what is already autonomous and what is not?
## What Backed approval should mean to an investor
Backed's approval should be interpreted as a curation signal, not as a blanket guarantee.
It means the raise has passed the platform's review and has been judged suitable for publication as a live launch.
It does not mean:
* that Backed guarantees the future conduct of the agent,
* that Backed is assuming the launcher's legal obligations,
* that economic performance is endorsed,
* or that the raise is free from market, execution, or organizational risk.
## After the sale closes
Depending on sale state, investors may see:
* a finalized sale with claim paths,
* a failed sale with refund paths,
* later redemption behavior through the vault ownership surface after the 30-day lockup window.
The important point is that these are not cosmetic differences. They affect what the participant can do next and what the committed capital now represents.
That is especially important in an emerging category. If the nature of the organization is new, then the clarity of the post-close path matters even more.
## Where to monitor the platform
For readers who want external reference surfaces in addition to the application itself:
* [DefiLlama](https://defillama.com/protocol/backed-aao) provides protocol-level visibility.
* [Dune](https://dune.com/lucatropea/backed) provides analytics and onchain dashboards.
## Practical investor discipline
Verify the relevant sale state directly from the chain rather than inferring from labels, cached values, or screenshots.
Check whether the project is actually approved and whether the live contract state supports the presentation.
Verify whether the sale is finalized, failed, or waiting on the relevant post-close workflow.
# Raise Economics
Source: https://docs.backed.app/guides/raise-economics
Soft cap, hard cap, lockup, and the financial rules participants should understand before committing.
# Raise Economics
This page explains the core economic terms of a Backed raise.
These terms should be understood before a participant commits capital and before an agent launcher presents the raise publicly.
## Commitment asset
Backed currently uses **USDM** as the standard commitment asset.
Participants approve USDM and commit it to the sale contract while the raise is active.
## Soft cap
The **soft cap** is the minimum funding threshold required for the raise to succeed.
In the protocol and interface surfaces, this is represented through the minimum raise value for the relevant collateral.
Practically, the soft cap answers one question:
> What is the minimum amount of capital that must be committed for this raise to be treated as successful?
If the raise is finalized without meeting the soft cap:
* the raise fails,
* no successful vault funding outcome occurs,
* and each participant can reclaim their full commitment.
## Hard cap
The **hard cap** is the maximum amount of capital that the raise is designed to accept.
It exists to define the upper bound of the raise rather than leaving the funding outcome open-ended.
Practically, the hard cap answers a different question:
> What is the maximum amount of capital this raise should accept?
## Accepted capital
Accepted capital is the amount that the raise ultimately recognizes as part of the successful funding outcome.
This concept matters because the amount participants commit and the amount the raise finally accepts are not always identical in every outcome.
## Soft cap and hard cap together
The two values serve different purposes:
* the soft cap establishes the minimum viable raise size;
* the hard cap establishes the maximum intended raise size.
That means a raise can have:
* both a soft cap and a hard cap,
* only a hard cap,
* or collateral-specific bounds defined through the protocol configuration.
In the standard participant reading model:
* the soft cap matters for success or failure,
* the hard cap matters for sizing and upper-bound interpretation.
## If the raise closes below soft cap
If the raise is finalized below the soft cap:
* the raise is treated as unsuccessful,
* accepted capital does not resolve into a successful funding outcome,
* and participants should expect a full refund path rather than a claim path.
## What happens above the hard cap
Where commitments exceed the accepted amount defined by the raise outcome, the excess should not be treated as permanently captured capital.
In practice, participants should understand that:
* accepted capital and total committed capital are not always identical,
* overflow conditions can result in refund amounts rather than additional accepted exposure,
* and the relevant source of truth remains the final contract state.
## Lockup period
The current Backed AAO raise model uses a **30-day lockup period**.
This lockup matters because the raise is not designed as instant in-and-out liquidity during the active operating window.
The lockup exists to align the raise with the underlying AAO model:
* capital is raised for a real operating or strategic purpose,
* the agent needs a stable period in which to act,
* and participants should not interpret the raise as on-demand liquidity during that period.
## How to think about the 30-day lockup
The lockup is best understood as a discipline around capital stability rather than a cosmetic timing parameter.
In practical terms, participants should assume that:
* the raise is built for a committed capital window,
* the vault ownership surface is not equivalent to unrestricted immediate redemption,
* and post-close liquidity is shaped by lockup and settlement conditions rather than by simple UI availability.
## Why these terms matter
In a conventional product, funding terms can sometimes be reduced to a simple progress bar.
That is not enough here.
In Backed, soft cap, hard cap, and lockup are part of how an AAO becomes credible as a capital structure. They define:
* the minimum threshold for success,
* the upper bound for participation,
* and the time horizon within which capital is expected to remain committed to the operating thesis.
## How to read the economics professionally
The economics of a Backed raise are meant to communicate seriousness, not novelty.
A credible raise should let an investor answer these questions quickly:
* What is the minimum capital required for this launch to make sense?
* What is the maximum size this raise is designed to absorb?
* What happens if the market commits less than the minimum?
* What happens if the market commits more than the intended maximum?
* How long is capital expected to remain locked after success?
## What investors should verify
Before committing, an investor should verify:
* the commitment asset,
* the active sale window,
* the soft cap,
* the hard cap,
* the current amount committed,
* and the lockup assumptions attached to the raise.
## What launchers should communicate clearly
Before promoting a raise, the launcher behind the agent should be able to explain:
* why the soft cap is set where it is,
* why the hard cap is set where it is,
* why the lockup is necessary,
* how accepted capital should be understood if the raise is oversubscribed,
* and what post-close outcomes participants should expect if the raise succeeds or fails.
# Raise Lifecycle
Source: https://docs.backed.app/guides/raise-lifecycle
End-to-end lifecycle of a raise, from identity prerequisite through post-close outcomes.
# Raise Lifecycle
Every Backed raise moves through a predictable sequence.
## Lifecycle stages
| Stage | Description |
| --------------------- | ------------------------------------------------------------------------------ |
| Identity | An ERC8004 agent identity already exists |
| Preparation | The launcher's economic, legal, and messaging assumptions are prepared |
| Creation | The factory creates the project and related addresses |
| Review | Backed verifies the launch for publication |
| Approval | The project is approved and can be treated as live |
| Commitment | Participants commit capital during the sale window |
| Resolution | The sale finalizes successfully or fails below the minimum threshold |
| Lockup and post-close | Claims, refunds, lockup, and later redemptions are governed according to state |
## Stage-by-stage interpretation
### Identity
Before anything else, the relevant agent identity already exists. This is the upstream prerequisite that makes project creation meaningful.
### Preparation
At this stage, the economic terms, public description, and launch accountability are defined. If the launch is still unstable or unclear, it is not yet ready for creation.
### Creation
Creation establishes the project onchain. It gives the raise a concrete record and related addresses, but it does not yet imply that the raise should be treated as live by the market.
### Review
Before a launch is presented publicly, Backed reviews it for publication. This is the curation boundary of the platform.
The point of this stage is not to claim responsibility for the agent. The point is to avoid presenting an unclear or unverified launch as though it were already fit for the market.
### Approval
Approval changes the meaning of the project. The raise is no longer merely created; it is now approved for launch and may be presented as live.
### Commitment
This is the stage at which the raise becomes economically active for participants. The live sale window becomes central, along with the soft cap, hard cap, and accepted capital rules.
### Resolution, lockup, and post-close
After the sale window, the relevant questions shift. The focus is no longer "can capital be committed?" but "what does the resolved state imply for claims, refunds, lockup, and later ownership behavior?"
If the raise resolves below the soft cap, participants should expect refund paths.
If it resolves successfully, the raise enters its post-close state, including the current 30-day lockup model.
## The distinction that matters most
Backed separates:
* project existence,
* project review,
* project launch,
* project funding,
* project settlement.
That separation is intentional. It lowers ambiguity and makes responsibility explicit.
## Operating rule
Do not use "launch" as a catch-all term. In Backed, creation, review, and approval are different events with different implications for the launcher, the investor, and the platform.
# Introduction
Source: https://docs.backed.app/index
Canonical documentation for Backed as infrastructure for Autonomous Agent Organizations.
# Backed Documentation
Backed is a curated capital formation platform for **Autonomous Agent Organizations** on MegaETH.
It is designed to explain the platform the way a serious participant should read it: what an AAO is, what an agent launch means, how investors should interpret a raise, and where the real trust boundaries sit.
The public documentation is intentionally organized around the platform, not around internal tooling or repository structure.
Begin here if you want the shortest path to the correct AAO model, participant structure, and raise assumptions.
Every launch on Backed is curated. Backed is not a permissionless listing venue. Approval means a launch has been reviewed and verified for publication on the platform, not that Backed underwrites the agent or assumes responsibility for its future conduct.
## Executive summary
Backed exists to make an emerging organizational form legible enough to raise capital responsibly.
At the center of the platform is the **AAO**, or **Autonomous Agent Organization**. An AAO is not simply a chatbot with a wallet, and it is not cleanly described by legacy categories alone. It sits somewhere between a company and a fund: it can hold capital, pursue a strategy, maintain a persistent identity, and evolve toward greater autonomy over time.
Backed gives that organizational form a disciplined launch surface. Each raise is tied to an agent identity, reviewed before going live, structured with explicit economic terms, and settled according to contract-defined outcomes.
The platform is designed to make an early-stage category feel legible, serious, and investable without pretending it is already finished.
The result is a platform where an agent can be presented to the market in a cleaner, more professional, and more interpretable way than a generic token page or an informal offchain process would allow.
## The central idea
Backed is built on the belief that many future companies will look more like networks of autonomous agents than like static legal shells with software attached.
That future is not complete today. The current generation of agent-led organizations still depends on human launchers, explicit review, legal accountability, and carefully defined economic rules.
For that reason, Backed should be understood as both:
* a real platform for launching and funding agent-led organizations today, and
* a disciplined research process into how credible AAOs should be formed, presented, funded, and governed.
## At a glance
| Topic | Current model |
| --------------------- | ---------------------------------------- |
| Organizational thesis | Autonomous Agent Organizations |
| Launch model | Curated and reviewed by Backed |
| Listing model | Not permissionless |
| Standard collateral | USDM |
| Core network | MegaETH |
| Identity dependency | ERC8004 Identity Registry |
| Approval model | Explicit platform approval before launch |
| Lockup model | 30-day lockup |
| Source of truth | Deployed contracts |
## What this documentation is for
This documentation is intended to answer five practical questions without ambiguity:
1. What exactly is Backed and how should an AAO be understood?
2. What is the difference between the agent, the launcher behind it, and the investor evaluating it?
3. How do soft cap, hard cap, accepted capital, refunds, and lockup actually work?
4. What does Backed verify before a launch becomes visible on the platform?
5. Where do platform review and platform responsibility stop?
## Read by audience
How an agent is launched, who stands behind it, and what accountability remains with the launcher.
How to evaluate a raise, commit capital, and interpret post-close outcomes.
Contract architecture, deployments, runtime surfaces, and integration guidance.
What approval means, what is reviewed, and where Backed does not assume liability.
## Read by topic
What Backed is, why it exists, and what kind of platform it is intended to become.
What an Autonomous Agent Organization is and why the category matters.
Why Backed is both infrastructure and an experiment in future organizational form.
How the agent, launcher, investor, Backed, and contracts each carry distinct responsibilities.
The full sequence from identity and review through settlement, refund paths, and lockup.
Soft cap, hard cap, lockup, accepted capital, and refund logic.
Contract layers, runtime responsibilities, and the boundaries that shape protocol behavior.
Chain IDs, RPC endpoints, and active contract addresses for technical readers.
Security assumptions, launch review boundaries, and the practical limits users should understand.
## What makes Backed distinct
The market-facing object is the agent, not a generic fundraiser profile. The launcher remains accountable behind it.
Launches are reviewed and approved before they are presented as live. Backed is intentionally not permissionless.
Each raise has explicit minimum and maximum funding logic, a standard collateral asset, and a 30-day lockup model.
Approval, commitments, finalization, claims, refunds, and ownership outcomes resolve through deployed contracts.
## Independent reference surfaces
Public protocol overview and ecosystem-level visibility for Backed.
Analytics and onchain dashboards for monitoring platform activity.
## Recommended reading order
If you are new to the platform, start with **What Is Backed**, **The AAO Model**, and **How Backed Works**.
If you are preparing a launch, continue with **Agent Guide**, **Raise Lifecycle**, and **Raise Economics**.
If you are evaluating participation, read **Investor Guide**, **Raise Economics**, and **Curation and Disclaimers** before committing capital.
If you are integrating programmatically or validating contract behavior, use the **Technical** section as the canonical reference.
## Reading principle
Backed separates platform narrative, participant guidance, economic rules, technical reference, and trust disclosures on purpose.
That separation matters because the category is early, the launch process is curated, the economics are specific, and contract state ultimately decides the financial outcome.
# The AAO Model
Source: https://docs.backed.app/overview/aao-model
What an Autonomous Agent Organization is and how Backed thinks about the category.
# The AAO Model
Backed is built around a category we call the **Autonomous Agent Organization**, or **AAO**.
We use that term carefully. It is not a decorative label for any software agent with a wallet. It refers to an emerging organizational form: an agent-led unit with identity, treasury, operating logic, capital, and a path toward increasing autonomy over time.
## Why we use the term
Legacy categories become imprecise very quickly in this space.
Some of the organizations launched through Backed behave in ways that resemble hedge funds:
* they raise capital,
* they manage treasury resources,
* they pursue a thesis or strategy,
* and they can be evaluated through operational and economic outcomes.
At the same time, they also resemble companies:
* they have a persistent identity,
* they can have a mission and public narrative,
* they can coordinate over time,
* and they may eventually collaborate with other organizational actors rather than existing as one-off financial wrappers.
For that reason, we think the most accurate description is not “fund” or “company” alone. It is a new organizational form that currently sits somewhere between those categories.
## What makes an AAO different
An AAO is not defined by a single feature. It is defined by a combination of properties:
* a stable identity,
* a capital base,
* an operating thesis,
* an execution surface,
* observable state,
* and a credible route from assisted operation toward greater autonomy.
The important point is that autonomy is not binary. An AAO does not need to be fully autonomous from day one to be a meaningful category. It can begin as a partially autonomous organization with explicit human controls and platform review, then evolve over time.
## Backed’s position today
Backed should not be read as claiming that fully autonomous companies already exist in mature form.
We do not think the market is there yet, and we do not think credibility comes from pretending otherwise.
Today, the platform launches agent-linked organizations that still rely on important human and platform-side responsibilities:
* launchers define the project and its public framing,
* Backed reviews launches and controls publication,
* contracts define capital and settlement state,
* interfaces make the system legible to participants.
That is not a weakness in the model. It is an honest description of where the category is today.
## Why this matters
If AAOs are going to become a serious category, they cannot begin as vague ideas wrapped in hype. They need:
* legible identity,
* credible capital formation,
* explicit launch controls,
* observable settlement logic,
* and language precise enough for sophisticated participants to understand what they are actually engaging with.
Backed exists to build those foundations.
## The long-term direction
Our long-term thesis is that future companies will increasingly look like networks of autonomous agents that collaborate with one another, exchange services, coordinate capital, and operate across shared rails.
We are not fully there yet.
Backed is therefore both:
* a functioning platform for launching and operating AAO-linked raises today, and
* an experiment in the organizational architecture of the future.
That dual character is central to how the platform should be understood.
# Core Concepts
Source: https://docs.backed.app/overview/core-concepts
Definitions and concepts used throughout the Backed platform and documentation.
# Core Concepts
This page defines the terms that appear repeatedly throughout the documentation. These are not marketing labels. They are the concepts that determine how the platform should be interpreted.
Several of these concepts matter more in Backed than they would in a conventional application because the platform is describing an emerging organizational form rather than a familiar legacy wrapper.
## Autonomous Agent Organization (AAO)
An **Autonomous Agent Organization** is the category Backed is exploring.
In our usage, an AAO is an agent-led organizational unit with persistent identity, treasury, capital, operating logic, and a path toward greater autonomy.
An AAO can resemble a hedge fund because it allocates capital and can pursue a strategy.
It can resemble a company because it has identity, continuity, mission, and the potential to coordinate with other organizational actors over time.
We do not use the term to suggest that the category is already fully mature. We use it because existing labels are insufficient for what is being built.
## Agent identity
Every raise in Backed is attached to an existing agent identity from the ERC8004 Identity Registry. Identity is therefore a prerequisite, not a downstream artifact of project creation.
## Launcher
The **launcher** is the individual, team, or company responsible for bringing the agent to market through Backed.
The agent is the market-facing object. The launcher is the accountable party behind it. Where required, the launcher is also the subject of KYC or KYB and remains responsible for the way the agent is described and introduced to the market.
## Project
A project is the factory-level record created for a raise. It contains the metadata and references to the sale, treasury, executor, and collateral configuration that define the raise surface.
A project is therefore the main unit a reader tracks across the lifecycle. It is the object that exists before launch, can later become approved, and ultimately anchors the sale and ownership surfaces.
## Approval
Approval is the distinct platform action that determines whether a project should be treated as launched. Creation alone is not enough.
This is one of the most important concepts in the system. Without it, a reader will collapse project existence and public launch into the same event and will misread the state of the platform.
## Curated launch
A **curated launch** is a launch that has been reviewed and verified by Backed before it is made visible as a live raise.
This is not equivalent to a guarantee. It means the platform has applied its launch controls and publication standards. It does not mean the platform assumes the launcher's obligations or the future performance of the agent.
## Sale state
The sale contract defines the live status of commitments, accepted capital, finalization, claims, and refunds.
When evaluating economic outcomes, sale state matters more than interface phrasing. It determines what capital has been committed, whether the sale has resolved, and what paths are available to participants.
## Soft cap and hard cap
The **soft cap** is the minimum level of accepted capital required for the raise to succeed. If the raise resolves below that threshold, participants receive refunds.
The **hard cap** is the maximum amount of capital the raise is intended to accept. Together, these values define the funding corridor of the raise.
## Lockup
Backed currently uses a **30-day lockup** model for AAO raises.
The lockup matters because it frames the raise as committed capital for an operating thesis rather than as instant in-and-out liquidity.
## Share token
Post-raise ownership resolves through the vault share token rather than through offchain records or interface labels.
This matters because Backed is not merely documenting an event. It is documenting a transition from fundraising into a post-close ownership surface.
## Source of truth
The source of truth for lifecycle state is the deployed contract system.
That does not mean the application is unimportant. It means it should be interpreted as a surface over the underlying state rather than as the owner of it.
Platform copy can help you interpret a raise, but it does not replace contract-defined approval, settlement, refund, and ownership state.
# How Backed Works
Source: https://docs.backed.app/overview/how-backed-works
The platform model from identity prerequisite through launch, commitment, and settlement.
# How Backed Works
Backed is easiest to understand as a structured launch and settlement model for agent-led organizations.
| Layer | Role |
| --------------- | ------------------------------------------------------------------ |
| Identity | Resolves the agent referenced by the raise |
| Project layer | Creates the raise record, stores configuration, and gates approval |
| Sale | Manages commitments, finalization, claims, and refunds |
| Vault ownership | Represents the post-close ownership surface |
| Application | Presents the raise to participants in a readable form |
## The AAO context
The point of this model is not only to launch a raise cleanly. It is to make an AAO legible as an organizational and financial object.
That means a reader should be able to understand:
* what identity the organization is tied to,
* when the organization has merely been instantiated,
* when it has actually been approved for launch,
* when it is actively accepting capital,
* and how its post-close economic state should be interpreted.
## Two ways to read the platform
There are two useful ways to understand Backed.
The first is structural: identity, factory, sale, treasury controls, and interfaces each play a distinct role.
The second is chronological: a raise moves from identity prerequisite to submission, review, approval, commitment, resolution, and post-close ownership outcomes.
Most confusion comes from mixing these two views. A reader sees a project in the interface and assumes it is already fully launched, when what they may be seeing is only one stage in a broader lifecycle.
## Core flow
A valid agent identity must already exist in the ERC8004 Identity Registry before the raise can be opened.
The launcher defines the public materials, economics, and structure of the raise around that agent identity.
The project is instantiated onchain and receives the addresses needed for the raise lifecycle.
The launch is reviewed, verified, and approved before it should be treated as live or marketed as open.
Investors commit capital during the active sale window under the published economic terms.
Finalization, refundability, claims, lockup, and later redemption behavior are determined by sale and vault state.
## Why this matters for AAOs
AAOs are still an emerging category. Because of that, the interpretive burden is higher than it would be for a familiar financial product.
Readers need more than a transaction flow. They need a framework for understanding what the organization is at each stage. Backed’s lifecycle model exists for exactly that reason.
## What changes at each stage
When a raise moves from one stage to another, the meaning of the project changes.
* Before creation, there is no project-level raise state.
* After creation, a project exists but may still be non-live from a market perspective.
* After approval, the project can be treated as launched.
* During commitment, the sale surface is active and economically relevant.
* After resolution, participants should reason about claims, refunds, lockup, and ownership according to the contract-defined outcome.
At a broader level, the system is moving the AAO from concept to instantiated object, from instantiated object to approved launch, and from approved launch to economically active organization.
## Why the model is structured this way
Backed does not treat identity creation as an implicit side effect of opening a raise. Identity is upstream and explicit.
A project can exist onchain before it is approved. Approval exists to preserve a deliberate launch boundary.
A reviewed launch is easier to interpret than an unfiltered listing, but review does not convert an emerging organization into a risk-free one.
Interfaces can expose state and facilitate action, but they do not define lifecycle truth. The contracts do.
## Practical implication
Anyone evaluating a raise should separate four different questions:
* Does the project exist?
* Has it been approved?
* Is the sale currently active?
* What does the current sale state imply for capital, claims, refunds, or lockup?
If those questions are answered in the wrong order, interpretation errors follow quickly. A project that exists may be treated as if it were already launched. A raise that is visible may be mistaken for one that is actively open. A close event may be mistaken for finalized settlement. The purpose of Backed’s structure is to reduce those ambiguities.
# Platform Thesis
Source: https://docs.backed.app/overview/platform-thesis
Why Backed should be understood as both infrastructure and research.
# Platform Thesis
Backed is not only a product. It is also a thesis about where organizational design is heading.
## The thesis in brief
We believe future companies will increasingly be composed of autonomous agents that hold capital, execute specialized roles, and collaborate with one another across shared rails.
That future is not complete today. But it is already visible enough that the infrastructure for it can be designed now.
## Why capital formation matters first
Capital formation is one of the best places to begin because it forces the hard questions into the open.
The moment an organization raises capital, the following questions become unavoidable:
* What exactly is the organizational unit being funded?
* When does it become live?
* Who has authority at each stage?
* What is merely visible and what is actually approved?
* What defines the financial outcome?
* What should a participant be able to verify directly?
If those questions cannot be answered clearly at the fundraising layer, they will become even harder to answer later when the organization becomes more autonomous and more complex.
## Why Backed is structured the way it is
Backed separates identity, creation, approval, participation, and settlement because those boundaries are foundational to credible AAOs.
If those boundaries were collapsed for convenience, the system might feel simpler on the surface, but it would teach exactly the wrong habits:
* that visibility is equivalent to launch,
* that narrative is equivalent to state,
* that privileged control can remain implicit,
* and that an emerging category can be trusted without being operationally legible.
We reject that model.
## Product and research at the same time
Backed is already a usable platform.
At the same time, it is also part of a research process. The category itself is still emerging, and the platform is one place where its standards can be made concrete.
That means two things have to be true simultaneously:
* the product must be precise enough for real users to rely on; and
* the documentation must be honest enough to state that the organizational form is still evolving.
## What success would actually look like
Success would not simply mean that more agents raise money.
It would mean that AAOs become:
* easier to interpret,
* more operationally credible,
* more legible to sophisticated investors,
* more capable of coordinating with one another,
* and more plausible as long-lived organizational actors rather than novelty wrappers.
Backed exists to help create that outcome.
# Participants and Accountability
Source: https://docs.backed.app/overview/roles-and-responsibilities
The responsibilities of the agent, the launcher behind it, the investor, Backed, and the contract layer itself.
# Participants and Accountability
Backed is intentionally explicit about who is responsible for what.
The platform works best when accountability changes hands cleanly from one stage to the next. Investors should not have to infer hidden launch state. Launchers should not hide behind vague language about autonomy. Backed should not be mistaken for the legal owner of the launcher's obligations.
## Agents
The agent is the primary market-facing object on Backed.
It is the unit that:
* has identity,
* raises capital,
* presents an operating thesis,
* and may evolve toward a more autonomous organizational form over time.
The agent is therefore the object investors evaluate and the object the platform presents.
## Launchers
Behind every agent there is a responsible launcher.
That launcher may be:
* an individual founder,
* a founding team,
* or a company.
The launcher is responsible for the legitimacy, framing, and launch quality of the agent. Where relevant, the launcher is also the party expected to undergo KYC or KYB and to bear legal responsibility for what is introduced to the market.
In practical terms, the launcher is responsible for:
* the identity and public framing of the agent,
* the truthfulness of the claims made about the agent,
* the coherence of the raise configuration,
* the relevant KYC or KYB path,
* and the legal accountability attached to the launch.
## Investors
Investors commit capital into the sale contract and should evaluate the raise using contract-backed facts rather than interface assumptions alone.
They should:
* understand what the agent claims to do,
* identify the launcher or launching entity behind it,
* verify that the raise is approved and live,
* understand soft cap, hard cap, accepted capital, refund logic, and the 30-day lockup before committing.
Investors are not expected to operate the system, but they are expected to distinguish between visibility, approval, activity, economics, and settlement.
## Backed
Backed is the platform, the curator, and the approval boundary.
Backed is responsible for:
* reviewing launches before they are presented as live,
* verifying that the platform's publication and approval standards have been met,
* maintaining the application and contract surfaces that expose raise state,
* and keeping the distinction between creation, approval, participation, and settlement clear.
Backed is **not** responsible for:
* the truth of every future outcome claimed or implied by the launcher,
* the strategic success of the agent,
* the legal obligations that remain with the launcher or launching entity,
* or the market performance of a raise after it has been approved.
## Contracts
The contract layer is the authoritative lifecycle surface. It determines:
* whether a project is approved,
* whether a sale is active, finalized, or failed,
* whether claims or refunds are available,
* which addresses and balances define current state.
This role is not metaphorical. It is the reason why the system can expose a clean product surface without turning product messaging into the authority on economic state.
## Boundary table
| Decision | Primary owner |
| ------------------------------------- | --------------------------------------- |
| Identity creation | Launcher or identity workflow owner |
| Public framing of the agent | Launcher |
| KYC or KYB completion | Launcher or launching entity |
| Project creation | Launcher or delegated platform workflow |
| Approval | Backed |
| Capital commitment | Investor |
| Platform publication of a live raise | Backed |
| Dispute resolution over current state | Deployed contracts |
# What Is Backed
Source: https://docs.backed.app/overview/what-is-backed
A professional and investor-friendly explanation of what Backed is and what it is building toward.
# What Is Backed
Backed is capital formation infrastructure for **Autonomous Agent Organizations** on MegaETH.
It provides a structured way to:
* link a raise to an existing agent identity,
* review and approve the project before it is launched publicly,
* accept capital commitments under explicit economic terms,
* settle the raise according to contract-defined outcomes,
* manage claims, refunds, lockup, and post-close ownership flows.
## The product in practical terms
Backed sits between a generic listing venue and a purely manual onchain process.
It does not reduce the raise to a campaign page, and it does not force serious participants to reason from raw contract interactions alone. Instead, it gives the raise a cleaner product surface while preserving explicit approval boundaries and contract-defined settlement underneath.
That is the core proposition of the platform: an AAO raise should be understandable to the market, curated before it goes live, and auditable from onchain state.
## What Backed is really trying to launch
Backed is not only launching isolated projects. It is helping define a category of organizations we refer to as AAOs.
An AAO is an agent-led organizational unit with identity, treasury, capital, operating logic, and a path toward increasing autonomy over time. In today’s environment, that unit does not fit neatly into traditional categories.
It is partly fund-like because it manages capital and can pursue a strategy.
It is partly company-like because it has a persistent identity, a mission, and the potential to operate as a continuing organizational actor.
Backed is built for that in-between state.
## In plain terms
Backed is designed to help a market participant answer three questions clearly:
1. What exactly is being launched?
2. When is it actually live?
3. Which source defines the financial outcome?
The platform answers those questions by separating identity, review, approval, participation, and settlement into distinct stages.
## Why Backed exists
Most fundraising interfaces collapse critical distinctions:
* the organizational object being funded is poorly defined,
* project creation is confused with public launch,
* listing visibility is confused with platform endorsement,
* interface output is treated as if it were the source of truth.
Backed takes the opposite approach. It makes responsibilities explicit and keeps lifecycle truth onchain.
For agents and their launchers, that means launch discipline.
For investors, that means clearer interpretation of what is live, what is funded, and what settlement should mean.
For launchers behind the agent, that also means accountability. The platform does not treat the agent as a legal void. The party launching the agent remains responsible for how it is presented, described, and introduced to the market.
For the platform itself, it means being explicit that we are still early in the evolution of the category. Backed is a product, but it is also part of an ongoing exploration of how agent-led organizations should be funded and operated.
## What Backed is optimized for
A project is not treated as live simply because it exists. Each launch is reviewed and approved before it appears as a live raise.
Agent identity, launch review, participation, settlement, and post-close ownership are modeled as separate responsibilities.
The market-facing object is the agent, while the launcher behind it remains accountable for the quality and legality of the launch.
The interface is a surface. The contracts define approval state, commitments, settlement, claims, and refunds.
## Who Backed is for
Backed is relevant to three groups of readers:
* agents and their launchers, who need to prepare and launch a raise in a controlled way;
* investors who need to evaluate commitment and settlement risk;
* integrators who need a reliable technical model for reading and acting on protocol state.
## What Backed is becoming
Our long-term view is that future companies will increasingly look like networks of autonomous agents that collaborate with one another rather than isolated pieces of software or static onchain wrappers.
We are not claiming that the category is complete today.
Instead, Backed should be read as an early but concrete step toward that future: a place where agent-linked organizations can begin to look investable, interpretable, and operationally credible.
## What Backed is not
Backed is not a generic campaign page builder, and it is not an open listing venue where any project appears automatically. It is a curated onchain raise platform with explicit approval gates and explicit settlement logic.
## What approval does and does not mean
Approval means that a launch has passed the platform's review and verification process and is eligible to be presented as live on Backed.
Approval does not mean:
* that Backed guarantees the future conduct of the agent,
* that Backed assumes the legal obligations of the launcher,
* that Backed is underwriting the economic performance of the raise,
* or that operational or market risk has been eliminated.
## One-sentence summary
Backed turns an approved agent identity into an investable, curated, contract-defined raise with deterministic settlement paths.
# FAQ
Source: https://docs.backed.app/support/faq
Short answers to the questions most likely to arise while using or operating Backed.
# FAQ
## What is an AAO?
An AAO, or Autonomous Agent Organization, is the category Backed is exploring. It is an agent-led organizational unit with identity, treasury, capital, operating logic, and a path toward greater autonomy over time.
## What is the source of truth for a raise?
The deployed contracts are the source of truth for approval state, commitments, settlement, claims, and refunds.
## Why is approval separate from creation?
Because Backed uses approval as an explicit launch gate. A project can exist before it should be treated as live.
## Are launches permissionless?
No. Backed is curated. Launches are reviewed and verified before they are approved and presented as live on the platform.
## What does Backed verify?
Backed verifies that a launch is suitable to be published as a live raise on the platform. That includes launch clarity, verification readiness, and the consistency of the raise presentation and structure.
## Does Backed assume responsibility for an approved launch?
No. Approval is a curation and publication decision, not a transfer of legal or economic responsibility from the launcher to the platform.
## Which asset is used for commitments?
USDM in the current deployment model.
## What is the current lockup model?
The current Backed AAO raise model uses a 30-day lockup period.
## How do soft cap and hard cap work?
The soft cap is the minimum amount required for the raise to succeed. If the raise is finalized below the soft cap, it fails and participants can reclaim their full commitment.
The hard cap is the maximum intended amount of accepted capital. It defines the upper bound of the raise.
## Is Backed claiming that AAOs are already fully autonomous companies?
No. Backed should be understood as both a functioning product and an ongoing experiment in how agent-led organizations can be formed, funded, and operated credibly.
## Who is responsible for an agent?
The launcher behind the agent remains responsible for the way the agent is introduced to the market. That launcher may be an individual founder, a team, or a company, and may be subject to KYC or KYB depending on the case.
## What should I verify before committing capital?
The agent, the launcher behind it, approval state, timing, soft cap, hard cap, lockup, and live sale status.
## What should I do if the interface and the chain disagree?
Trust the chain and verify the relevant project and sale state directly.
## Where can I monitor Backed externally?
Backed is also visible through [DefiLlama](https://defillama.com/protocol/backed-aao) and [Dune](https://dune.com/lucatropea/backed).
# Architecture
Source: https://docs.backed.app/technical/architecture
High-level contract-centric architecture of Backed across identity, issuance, sale, and control layers.
# Architecture
Backed is a contract-centric system with multiple interface layers around it.
This page explains the system from the perspective of control and interpretation rather than from the perspective of repository layout. That is the only way to keep the architecture useful to integrators and sophisticated participants at the same time.
## Primary components
| Component | Responsibility |
| ---------------------------- | ---------------------------------------------------- |
| ERC8004 Identity Registry | Resolves agent identity before raise creation |
| AgentRaiseFactory | Creates projects and gates approval |
| Sale | Handles commitments, settlement, claims, and refunds |
| AgentVaultToken | Represents post-settlement ownership |
| ContractAllowlist | Constrains treasury execution targets |
| SafeModuleSetup | Supports Safe-based treasury control |
| Application and integrations | Provide interaction surfaces over the same stack |
## How the pieces relate
The identity layer establishes who the raise belongs to.
The factory establishes that a project exists and stores the project-level configuration and approval status.
The sale layer establishes whether capital can be committed and what settlement state follows after the window closes.
The treasury-control layer constrains how sensitive execution paths can be used.
The interface layer makes those underlying states legible and actionable, but it does not define them.
## Architectural boundaries
### Identity boundary
Identity is external to the factory. Backed assumes identity already exists.
### Launch boundary
Creation and approval are separate events.
### Treasury boundary
Treasury actions are intentionally constrained instead of being assumed safe by default.
### Environment boundary
Testnet and mainnet are separate operational surfaces with different manifests and addresses.
## Architectural reading rule
When reviewing the platform, read from the inside out:
1. contracts define state,
2. manifests define targeting,
3. interfaces define convenience,
4. internal execution workflows define write discipline.
That order is also a useful discipline when debugging. Most confusion in systems like this comes from reading those layers in reverse.
# Contracts and Roles
Source: https://docs.backed.app/technical/contracts-and-roles
Contract-specific responsibilities and role boundaries in the Backed raise stack.
# Contracts and Roles
Backed is built around a compact contract surface in which each component has a distinct responsibility.
The goal of this design is not complexity for its own sake. It is to preserve clean boundaries between project creation, approval, participation, settlement, and treasury control.
## AgentRaiseFactory
The primary protocol control contract for:
* project creation,
* project discovery,
* project metadata,
* project approval state,
* global configuration.
## Sale
The per-project contract responsible for:
* commitment acceptance,
* accepted amounts,
* lockup configuration,
* finalization,
* claims,
* refunds,
* collateral accounting.
## AgentVaultToken
The vault share token representing post-settlement ownership.
## ContractAllowlist
The execution boundary that restricts what treasury-controlled execution can target.
## SafeModuleSetup
Deployment-side setup used when treasury control is wired through Safe modules.
## Why the split matters
Keeping these responsibilities distinct makes the system easier to reason about:
* project existence and approval are not conflated with sale activity,
* sale logic is not conflated with treasury execution controls,
* post-close ownership is not conflated with pre-close commitments.
## External dependencies
| External contract | Why it matters |
| ------------------------- | ----------------------------------------------------- |
| ERC8004 Identity Registry | Required prerequisite for agent-linked raise creation |
| USDM | Current commitment asset in the deployed model |
If the interface and the contracts disagree, the contracts win.
# Deployments
Source: https://docs.backed.app/technical/deployments
Environment-specific deployment facts, contract addresses, and operating cautions for Backed on MegaETH.
# Deployments
Backed currently operates with explicit manifests for MegaETH testnet and mainnet.
This page is intentionally factual. Its purpose is to reduce ambiguity around which contracts and environments a reader should be reasoning about.
## Environment matrix
| Environment | Chain ID | RPC | Version |
| --------------- | -------- | --------------------------------- | --------------------- |
| MegaETH Testnet | `6343` | `https://carrot.megaeth.com/rpc` | `official-2026-04-24` |
| MegaETH Mainnet | `4326` | `https://mainnet.megaeth.com/rpc` | `official-2026-04-24` |
The difference between these environments is not cosmetic. Each environment has its own addresses, state history, and operational consequences.
## Testnet addresses
| Contract | Address |
| -------------------------- | -------------------------------------------- |
| `SafeModuleSetup` | `0x7b6EbB0ede8ac0224a176663e6c07Dece0a37010` |
| `ContractAllowlist` | `0x54459A9431bD98c754180DEB32B067Cf31bDfF33` |
| `AgentRaiseFactory` | `0x577be362178d20A3370722807d0294fA5D8A5a2A` |
| `USDM` | `0x9f5A17BD53310D012544966b8e3cF7863fc8F05f` |
| `ERC8004_IdentityRegistry` | `0x8004A818BFB912233c491871b3d84c89A494BD9e` |
## Mainnet addresses
| Contract | Address |
| -------------------------- | -------------------------------------------- |
| `SafeModuleSetup` | `0x54459A9431bD98c754180DEB32B067Cf31bDfF33` |
| `ContractAllowlist` | `0x577be362178d20A3370722807d0294fA5D8A5a2A` |
| `AgentRaiseFactory` | `0x45179eE92887e5770E42CD239644bc7b662673af` |
| `USDM` | `0xFAfDdbb3FC7688494971a79cc65DCa3EF82079E7` |
| `ERC8004_IdentityRegistry` | `0x8004A169FB4a3325136EB29fA0ceB6D2e539a432` |
## Deployment rule
Every privileged action should begin by re-confirming environment, RPC, signer, and target contract addresses.
## Practical use
This page should be treated as a reference layer, not as a substitute for checking the live manifest used by the active application or operator workflow.
# Integration Patterns
Source: https://docs.backed.app/technical/integration-patterns
Recommended integration patterns for reading and acting on Backed state safely.
# Integration Patterns
This page is for teams building around Backed rather than only using the product interface.
The safest integrations are the ones that follow the same ordering discipline the platform itself relies on: select the environment, identify the project, read the state, then decide whether action is appropriate.
## Recommended read pattern
Start from the environment and factory:
1. resolve the deployment manifest,
2. resolve the factory address,
3. enumerate or fetch the target project,
4. resolve the sale address,
5. derive current state from the relevant contract reads.
This pattern minimizes the chance that your integration will treat a visible project as if it were already approved or a created sale as if it were already resolved.
## Recommended write pattern
For any privileged action:
1. bind the correct environment explicitly,
2. bind the correct signer explicitly,
3. read the relevant pre-state,
4. perform the write,
5. read the relevant post-state for confirmation.
## Anti-patterns
* assuming a UI label is equivalent to contract truth,
* assuming project creation implies approval,
* mixing testnet and mainnet assumptions in automation,
* reading only a single surface when sale state is required.
# Runtime and Data
Source: https://docs.backed.app/technical/runtime-and-data
How application surfaces resolve environment state, build clients, and render protocol state.
# Runtime and Data
Backed application surfaces resolve environment-specific manifests and read state from the deployed contracts.
That means the runtime has two jobs at once: it must point to the correct system, and it must present the resulting data clearly enough that humans can act on it.
## Runtime model
The runtime is responsible for:
* selecting the active deployment,
* resolving contract addresses from that deployment,
* building read clients,
* formatting contract outputs for the application and integration surfaces.
## Data model rule
The runtime can format, cache, and present state. It does not own lifecycle truth.
## Practical implication
When two sources disagree:
1. trust the deployed contract reads,
2. verify the environment,
3. verify the interface is pointing at the same manifest.
## Product data versus protocol state
Certain product surfaces may use offchain systems for discovery or catalog behavior. Those systems are useful for product experience, but they are not the authority for approval state, commitment state, or settlement outcomes.
# Curation and Disclaimers
Source: https://docs.backed.app/trust/curation-and-disclaimers
What Backed's review means, why launches are curated, and where platform responsibility stops.
# Curation and Disclaimers
Backed is intentionally curated.
It is not a permissionless venue where any agent can appear automatically and rely on the interface alone to create credibility.
That design choice is deliberate. If AAOs are going to become a serious category, the launch surface cannot be indistinguishable from an unfiltered listing board.
## Why curation exists
Backed uses curation to create a clearer publication boundary between:
* a project that has merely been created,
* and a project that has been reviewed and approved as a live raise.
That boundary matters for both participants in the market:
* **agents and launchers** need a disciplined standard for how a raise is presented;
* **investors** need to know whether the platform itself recognizes a launch as live.
## What approval means
Approval means that Backed has reviewed the launch and determined that it can be published as a live raise on the platform.
In practical terms, approval is meant to signal:
* that the launch has passed the platform's publication controls,
* that the raise is not being treated as merely draft or provisional,
* that the public presentation has reached an acceptable level of clarity,
* and that the platform is willing to expose the launch to participants.
## What Backed reviews
The review process is meant to evaluate whether a launch is suitable for publication on Backed, not whether it is guaranteed to succeed.
That usually includes review of:
* the coherence of the agent identity,
* the clarity and professionalism of the market-facing description,
* the presence of a responsible launcher or launching entity,
* the relevant KYC or KYB path,
* the consistency of the raise terms,
* and the basic legibility of the launch to a serious participant.
## What approval does not mean
Approval does **not** mean:
* that Backed is underwriting the raise,
* that Backed guarantees the future behavior of the agent,
* that Backed is taking over the launcher's legal obligations,
* that the raise is free from market, strategic, or technical risk,
* or that the category itself is already fully mature.
## The launcher's responsibility remains
Backed's curation model is meant to improve platform quality, not to erase accountability.
The launcher behind the agent remains responsible for:
* what is being represented to the market,
* what is implied about the agent's present and future autonomy,
* the truthfulness of the launch narrative,
* the coherence of the raise itself,
* and the legal perimeter of the launch.
## Why this distinction matters
Emerging categories often fail in one of two ways:
* they are too open, so the market cannot distinguish serious launches from noise;
* or they blur responsibility, so participants confuse platform review with platform liability.
Backed is designed to avoid both failures.
The platform is curated because the category needs structure. The platform is also explicit about its boundaries because curation is not the same thing as assuming legal or economic responsibility for every approved launch.
# Risk Boundaries
Source: https://docs.backed.app/trust/risk-boundaries
The risks that agents, launchers, and investors should keep in mind when reading a Backed raise.
# Risk Boundaries
The largest practical risks in Backed are usually not abstract. They are interpretive, organizational, and economic.
This page exists to make those risks legible before they are misunderstood as simple interface concerns. Most of them do not originate from deep protocol mechanics alone. They come from incorrect interpretation, rushed launch behavior, overstated autonomy, or weak accountability.
## Primary risks
| Risk | Description |
| ---------------------------- | ------------------------------------------------------------------------------------------ |
| Premature launch assumptions | A project exists or is visible, but has not been approved as a live raise |
| Autonomy overstatement | The agent is described as more autonomous than it actually is |
| Launcher opacity | The responsible founder or company behind the agent is unclear |
| Economics misread | Investors misunderstand soft cap, hard cap, refunds, or the 30-day lockup |
| Interface-state mismatch | A surface shows stale or incomplete information relative to contract state |
| Category risk | AAOs are still an emerging organizational form and should be read with appropriate caution |
## How to reduce these risks
* separate creation, review, approval, and settlement in your own reading of the raise,
* ask whether the launch description is precise about what is already autonomous and what is not,
* verify that a real launcher or launching entity stands behind the agent,
* read the economic terms before treating a raise as investable,
* trust contract-defined state over screenshots, cached interfaces, or second-hand summaries.
# Security Model
Source: https://docs.backed.app/trust/security-model
Security and trust assumptions behind Backed for agents, investors, and technical integrators.
# Security Model
Backed is contract-first, but it is not "trustless" in the simplistic marketing sense.
Its safety depends on both:
* the integrity of the deployed contracts,
* the discipline of the platform's review and approval controls.
This distinction matters because the platform does not claim that every important decision becomes safe merely because it touches the chain. Certain decisions remain procedural by nature, and the documentation should make those boundaries visible.
That honesty matters even more because Backed is exploring the AAO category rather than presenting it as a fully solved problem. The platform should be trusted to the extent that its state boundaries, operational controls, and disclosure standards are credible, not because the category is already complete.
## Core security boundaries
| Boundary | What it protects |
| ----------------------- | ---------------------------------------------------------------- |
| Onchain state boundary | Approval, commitments, settlement, claims, refunds |
| Review boundary | Separation between created launches and approved public launches |
| Accountability boundary | Separation between platform review and launcher responsibility |
| Treasury boundary | Restriction of treasury-controlled execution paths |
## Practical trust assumptions
Users should assume:
* the contracts define the current truth,
* Backed's approval means the launch has been reviewed for publication,
* the launcher remains responsible for the claims and legal perimeter of the agent,
* collateral and economic assumptions are correctly configured in the live contracts.
## What curation does and does not provide
Curation improves legibility. It can reduce obvious ambiguity, force clearer launches, and help keep the platform readable for investors.
What it does not provide is a blanket guarantee.
Backed's approval should not be read as:
* a promise of future performance,
* a transfer of legal responsibility from launcher to platform,
* or an assertion that an emerging AAO carries no execution or market risk.
## What this means in practice
Backed reduces ambiguity by moving critical lifecycle decisions onchain and by curating which launches are presented publicly, but it does not remove the need for disciplined reading by participants.
In short: Backed should be read as a serious platform for an emerging category, not as proof that the category is already frictionless, fully autonomous, or risk-free.