In DEP 3, two kinds of intellectual property meet: the working solution a project brings in, and the new work a DAO creates while scaling it. This page sets out how both are handled — simply, and fairly to everyone whose work and knowledge is involved.

The starting principle: the project keeps its IP

A participant-proposed DAO is built around a project that already has a working solution. That solution — its code, its brand, its method — is, and stays, the project's own intellectual property.

DEP 3 does not require a project to transfer, license, or co-own its solution's IP in order to take part. An earlier concept explored co-ownership — the project opening its codebase, the DAO reimbursing development, the product tokenised and licensed to production partners. DEP 3 deliberately does not run that model. It keeps things simple: the project keeps its IP, and the DAO collaborates on service and amplification, not by taking ownership of the solution.

The DAO is a channel that scales the project's solution — through community, reach, and business development. It is something the project gains, not a vehicle that acquires what the project built.

The DAO’s own work: authorship and credit

While scaling a project, a DAO produces new work of its own — documentation, content, recipe or story collections, creative outputs, guides. This work has its own IP, and DEP 3 handles it on two principles:

• Contributors are credited. The members who create the work are recorded as its authors.
• The originating community is credited as originator. Where the work draws on a community's knowledge or heritage — a cook's recipe, a weaver's technique, an elder's story — that community is credited as the source. The DAO amplifies; it does not claim authorship of a community's heritage.

This is why, in the participant-proposed example, the Sourcing lane pairs a keeper's consent with an on-chain authorship credit to the source community: the work travels further, and its origin travels with it.

Consent comes first

Work that documents or draws on a community's knowledge is created with that community's consent — gathered at sourcing, not assumed afterwards. Nothing is published or anchored without the community's agreement, and specific material a community doesn't want used stays unused. A DAO working with a community sets its consent and credit terms as part of its plan. (See the Sourcing lane in the participant-proposed example, and clauses 3 and 5 of the Terms & Conditions for Projects.)

Anchoring authorship on-chain (optional)

For DAOs whose work produces IP worth protecting, the framework can anchor authorship on-chain, so it is verifiable later.

What counts as "work worth protecting"? A food-heritage DAO that assembles a recipe, technique and story collection; a creative DAO that produces original artworks or designs; a cultural DAO that documents a craft technique or a body of oral histories — each creates a distinct work whose authorship (its makers', and the source community's) is worth recording. By contrast, an operator DAO like CED, which runs sessions rather than producing a standalone work, has no such artifact to anchor, and simply doesn't use this.

For a DAO that does produce a work, anchoring is two steps:

• The DAO writes an IP Declaration — a structured description of the work (a canonical JSON manifest) naming the work, its contributors, and the originating community.
• The framework takes a cryptographic fingerprint (a keccak256 hash) of that declaration and anchors it on-chain. The declaration itself stays with the DAO; the fingerprint on-chain is enough to prove, later, that a given declaration existed and hasn't been altered.

For how it works step by step, see NFT IP Anchoring in the Kambria DAOs Framework section.

Platforms and development partners

Some DAOs run a service on a platform someone else built and maintains — as CED runs on the platform Kambria built. That partner keeps its platform IP; the DAO operates a service on it. DEP 3 does not tokenise or license a platform's codebase into a DAO this cohort.

How a development partner shares in revenue is a question for the split, not for IP ownership — see Categorisation & Revenue Split. For CED in DEP 3, Kambria keeps CED's IP (the DAO isn't yet set up to co-own it), so the Dev Partner share is directed to the DAO Treasury rather than paid as a licence.

What a DAO records

At proposal time, a DAO notes briefly, in its master plan (and, for community work, in the Sourcing lane's plan):

• what IP it expects to produce during the cohort,
• how the originating community is credited, where relevant, and
• whether it will anchor that work on-chain.

This framework builds on the DEP 2 IP framework, simplified for DEP 3: the project keeps its IP, and the DAO's own work credits both the people who made it and the communities it draws on.