Twelve de-facto entities — hacker houses, network schools, popup cities, software houses, influencer brands, agencies, syndicates, residencies, and more — each shaped into a ready-to-register record for Entity.ID's public registrar.
Live-in builder collective: shared 6-bedroom lease, co-working studio, weekly demo nights, rolling monthly intake of 1-2 new residents. Members contribute monthly dues, share house operations, and run a small treasury that funds events and equipment.
Location
San Francisco, CA, USA
Partners & splits
• Maya Chen — 30% (founder, lease holder of record) • Diego Alvarez — 25% (operations, residency lead) • Priya Iyer — 20% (programs, demo nights) • Tomás Rivera — 15% (treasury, dues collection) • Sofia Park — 10% (community, residency interviews)
Lighthouse SF has all three de-facto constitutive elements — five named constituents, a shared house operating as a thing-in-itself, and public announcement via a website, an application form, and weekly demos open to outsiders. It has no de-jure recognition: the lease is in Maya's personal name, dues flow through Tomás's Venmo, and the "house" is not registered with the California Secretary of State.
What makes this archetype distinct in startup society
Lease creates real off-chain liability the proto-entity can't fully wrap. Maya carries personal exposure until the entity upgrades to an LLC.
High member churn by design — residency rotates monthly. Members ≠ partners; the 5 named partners are the persistent organizing core.
Treasury is small but ongoing — a few thousand dollars at a time for events, equipment, snacks. Right-sized for a multisig.
Demo variants
Equity-equal variant: split 20/20/20/20/20 for the "five-cofounder house" pitch.
Solo-founder variant: Maya 100%; reduces to a single-operator housing brand renting rooms to residents.
Custom arbitration variant: swap Kleros → Custom: AAA Commercial Rules, seat: San Francisco to walk through the custom-arbitration UI.
Co-located network variant: register sibling houses (lighthouse-nyc.association.public.entity.id, lighthouse-cdmx.association.public.entity.id) referencing this one as a parent.
12-week in-person cohort program for AI builders shipping production agents. 30 participants pay tuition; weekly studio days, paired mentorship, public demo day at week 12. Third cohort of the AI Studio program.
Location
Lisbon, Portugal
Partners & splits
• Lin Wei — 50% (founder, curriculum lead) • Adaeze Okonkwo — 30% (program director, mentor network) • Rafael Costa — 20% (operations, admissions, Lisbon ops)
A specific, named, time-boxed cohort with three organizing partners, a venue, paying participants, and a defined start and end date. Distinct from the broader AI Studio brand (which would be its own entity). Pre-formal: tuition is collected via Stripe to Lin's personal account; no separate cohort LLC; mentor agreements are handshake.
What makes this archetype distinct in startup society
Time-boxed by design — has a known cessation date (week 12). Future cohorts are new entities, not amendments to this one.
Members ≠ partners — 30 paying participants are members of the cohort, distinct from the 3 organizing partners on the record.
Recurring brand, recurring entities — the parent brand (AI Studio) recurs; each cohort is its own ephemeral proto-entity. Suggests a parent-entity / child-cohort pattern for the dashboard.
Real money on a short timeline — $90k+ tuition revenue flows through in 12 weeks. Tax position needs to be clean before the cohort ends.
Demo variants
Free / scholarship cohort: same shape, $0 tuition; useful for non-profit framing.
Equity-split-by-effort variant: redistribute 40/40/20 if Lin and Adaeze argue for equal lead status.
Sub-entity of parent variant: register parent ai-studio.association.public.entity.id first, then this cohort as a child — exercises the parent-entity lookup.
8-week popup city for 250 residents across three program tracks (longevity research, network-state design, crypto-native commons). Operates a leased coastal venue with shared meals, daily salons, public lecture series, and a curated visitor program. Residents pay a residency fee covering housing, meals, and programming.
Halcyon Village 2026 is a large, time-boxed gathering with 250 paying residents, three program directors, a leased venue, real visa logistics, and millions of dollars flowing through its accounts. No host-country legal entity covers it; the partners coordinate via a Maltese SPV for payments, but the village itself is the proto-entity. After eight weeks, it ceases.
What makes this archetype distinct in startup society
Genuinely jurisdictional — host country (Montenegro) has visa, tax, and venue-licensing exposure. Custom arbitration with international seat (Vienna) reflects cross-border resident base.
Cooperative shape fits — residents are members, not customers; programs are co-curated; the village's reputation belongs to the community.
High-stakes cessation — at week 8 the venue closes, residents disperse, the entity ends. Predecessor pointer to a successor village (2027) is the natural lifecycle pattern.
Larger curatorial council — five named partners with declared tracks. Bigger than a hacker house, more institutional than a hackathon team.
Demo variants
Smaller council variant: collapse to 3 partners (longevity, network-state, ops) for a simpler structure.
Kleros-arbitration variant: swap UNCITRAL → Kleros to show the lighter on-chain default; useful for arguing Kleros works even at this scale.
Series-of-villages variant: register halcyon-village.cooperative.public.entity.id as a parent, then halcyon-village-2026 and halcyon-village-2027 as sub-entities sharing curatorial DNA.
Sponsor-attestation variant: ingest sponsor commitments as attestations on the entity (parallel to the hackathon-organizer attestation pattern).
Boutique product engineering studio building MVPs and 1.0 releases for early-stage startups. Three-month engagements, full-stack delivery, equity-for-discount option on a portion of fees. Operates remote-first with bi-monthly in-person sprints.
Location
Cairo, Egypt — declared home; team operates remote-first across MENA + Europe
Three cofounders selling engineering time to startup clients. Revenue is real and recurring (~$15-25k/month per engagement, two engagements concurrent). They invoice from Anjali's sole-proprietor account in Egypt; equity-for-discount agreements with clients accumulate quietly without a clear holder. No LLC or limited company exists yet.
What makes this archetype distinct in startup society
Cofounder weighted split, not equal — the 40/35/25 split reflects asymmetric founding contributions; the constitution needs to make that durable.
Services revenue + accumulated equity — agency-style cash flow plus a long-tail equity portfolio in clients. The entity is both an operating company and a holding company.
Client IP needs a clean home — work-for-hire deliverables must be assignable to clients without ambiguity. The constitution should declare IP assignment defaults.
International team, Kleros-fit — distributed team, international clients, low-stakes disputes; Kleros General Court is the natural choice.
Demo variants
Two-cofounder variant: 60/40 split for the smaller-shop look.
Five-cofounder variant: 30/25/20/15/10 with named roles, demonstrating the larger-team UI.
standard-llc variant: swap Model 1 → standard-llc to show what a Delaware-bound services agency would use.
Equity-portfolio attestation: ingest each client equity grant as an attestation on the entity record; shows the dashboard handling a growing attestation list.
Personal media brand fronted by Amir Hadid: weekly essay newsletter, twice-monthly podcast, two online courses per year, occasional sponsored placements. Audience ~85k newsletter subscribers, focused on independent research and frontier-tech essays.
Location
Berlin, Germany
Partners & splits
• Amir Hadid — 80% (principal, writer, on-camera/voice talent) • Nia Williams — 15% (producer, podcast editing, ops) • Karim Saade — 5% (design, brand, art direction)
A creator-led brand with one named principal whose face and voice is the brand, plus two supporting partners on declared splits. Revenue (sponsorships, course launches, paid subscriptions) currently lands in Amir's personal account in Berlin. The "brand" exists publicly — domain, newsletter, podcast feed, course pages — but no German GmbH or UG yet.
What makes this archetype distinct in startup society
Personal-brand-attached — the entity is named after the principal. If Amir steps away, the brand effectively ceases. That's a structural fact the constitution should declare (e.g., name-rights revert to Amir on dissolution).
Weighted split is the norm — 80/15/5 reflects the asymmetry between principal and support; equal splits make no sense here.
Sponsorship attestations — sponsored placements + brand-safety attestations are constitutional-grade events. The entity should be able to declare what it will and won't sponsor.
Tax position is messy by default — multi-country audience, German residence, possibly US-tax-treaty-relevant. Proto record doesn't fix this but anchors it.
Demo variants
Solo-creator variant: Amir 100%, no support partners; the simplest possible record.
Multi-talent variant: 50/30/20 with two on-camera principals; demonstrates the multi-principal influencer brand (think duo podcasts).
Brand-license variant: register parent field-notes.venture.public.entity.id separately and let Amir license the name to time-limited spin-offs (a course series, a book imprint).
Patron-attestation variant: ingest top-tier paid subscribers as attestations (membership proofs); shows the dashboard handling individual-supporter attestations rather than sponsor-corporation ones.
Performance marketing and growth-ops agency serving Series A B2B SaaS clients. Monthly retainer plus performance-tied fees on attributed pipeline. Three to five concurrent clients; team scales contractors per engagement.
Location
London, United Kingdom
Partners & splits
• Alice Tan — 60% (founder, performance media, client lead) • Bob Rivera — 40% (cofounder, analytics, growth engineering)
Arbitration
Custom — London Court of International Arbitration (LCIA) Rules, seat: London, sole arbitrator, English law governing
Two cofounders running an agency with steady client retainers, contractor relationships, and revenue-share arrangements with referral partners. Invoices via Eleanor's UK sole-trader registration; a Ltd. company is "in the works" but not filed. Real contracts, real liability exposure, real partner equity at stake.
What makes this archetype distinct in startup society
Custom arbitration is the realistic choice — UK-anchored agency serving UK + European clients typically defaults to LCIA. Useful demo of the custom-arbitration path (institution + seat + governing law).
Two-cofounder weighted split — 60/40 is one of the most common real splits; under-modeled by equal-split templates.
Performance-tied revenue — part of the fee is contingent on attributed pipeline. Performance clauses don't live in Model 1 today; this surfaces the gap.
Contractor pool, not employees — the agency's labor is per-engagement contractors. Worth modeling as a separate "labor pool" attestation set later.
Demo variants
Three-cofounder variant: 50/30/20; adds a third role (creative director).
Kleros variant: swap LCIA → Kleros; shows the agency-on-default path; useful for a more crypto-native client base.
standard-llc variant: swap Model 1 → standard-llc; demonstrates the Delaware-anchored UK-operator path that's increasingly common.
Holding-company variant: register northstar-group.venture.public.entity.id as parent holding two subsidiary brands (paid media, content); shows the parent-child entity nesting.
Capital Pool4 partnersCustom (SIAC, Singapore)Model 2
Ready-to-register record
Field
Value
Venture name
Frontier Seeds I
Description (business purpose)
Angel syndicate writing $25k–$100k pre-seed checks into AI-native infrastructure startups. Deal-by-deal SPVs for each investment, drawing from a 12-month commitment pool. Lead GP sources and diligences; partners co-invest pro-rata. Expected pool size $3M across the first year.
Location
Singapore
Partners & splits
The partner block on the record is the carry allocation — economic share of fund profits — not the contributed capital. LP contributions are tracked separately as commitment attestations.
• Jordan Tan — 60% (lead GP, deal sourcing, diligence, portfolio management) • Aisha Mohamed — 20% (co-GP, technical diligence on AI infrastructure) • Pedro Salgado — 10% (operator-partner, portfolio company support) • Hana Okafor — 10% (scout-partner, founder network)
Arbitration
Custom — Singapore International Arbitration Centre (SIAC) Rules, seat: Singapore, three arbitrators for disputes > USD 250k, sole arbitrator otherwise
Constitutional model
Model 2 — Charter Format (quotaholder terminology fits capital-pool partners better than Model 1's "partners")
Four named carry holders with a declared share of fund economics, a sourcing mandate, and a capital pool forming via 12-month commitments from LPs. No Cayman exempted LP or Delaware LP filed yet — the syndicate operates first as a proto-entity, raising soft commitments and writing first checks through an AngelList SPV per deal. The de-jure structure (Cayman LP + Delaware GP) follows at fund close.
What makes this archetype distinct in startup society
Two distinct membership classes — carry holders (the 4 partners on the record) and LPs (commitment-bearing members). Today the form only models partners. LPs should be members with commitment-attestations.
The split is economic, not ownership — partners own carry, not the fund. Model 2's quotaholder language is closer to the right shape than Model 1's partner language.
Custom arbitration is the norm — fund disputes are high-value and venue-sensitive; SIAC + Singapore is a standard pairing for Asia-LP / global-deployment funds.
Predecessor → successor lifecycle is real and near-term — at fund close, the de-jure entities (Cayman LP, Delaware GP) get formed and the proto record becomes their predecessor. Worth modeling cleanly.
Demo variants
Solo GP variant: Jordan 100%; the simplest emerging-manager case.
Equal-partners variant: four GPs at 25% each; the "collective fund" pitch (think Chapter One, Banana Capital, Better Tomorrow Ventures' shape).
Kleros variant: swap SIAC → Kleros; useful for crypto-native syndicates where on-chain disputes are the norm.
LP-attestation variant: ingest each LP commitment as a numeric attestation on the entity; demonstrates the dashboard handling membership records distinct from partners.
Multi-fund variant: register frontier-seeds.capital-pool.public.entity.id as parent, and frontier-seeds-i, frontier-seeds-ii as child entities sharing the carry-split DNA.
6-week structured residency for 20 mid-career founders between exits or pivots. Co-living, paired mentorship, weekly working sessions, optional capstone investment thesis. Residents pay a participation fee; alumni network is the long-term moat. Spring and autumn cohorts each year.
A recurring 6-week program with four named organizing partners, 20 paying residents per cohort, a real venue, and a growing alumni network that creates ongoing brand value between cohorts. Operates as a proto-entity across cohorts; each cohort itself is sub-shaped (similar to network-school cohorts) but the residency brand persists. No Mexican SA de CV or US LLC yet; revenue flows through Inés's RFC and a corresponding US LLC owned personally.
What makes this archetype distinct in startup society
Recurring brand, recurring proto-cohorts — the residency persists; each cohort is a time-boxed sub-event. This is the hybrid the schema needs to model: persistent parent + ephemeral children.
Alumni network = long-term value — alumni claim membership across cohorts. Each cohort completion is an attestation worth carrying on the alumnus's natural-entity record.
Cross-border residents — 20 founders from 12+ countries each cohort. Visa, currency, and contract logistics need a clean entity to hang on.
Custom partner roles, equal-ish split — 35/25/20/20 reflects founder-plus-three pattern without going all the way to weighted-by-equity.
Demo variants
Solo-director variant: Inés 100%; demonstrates the single-operator residency shape (most early-stage residencies look like this).
Sub-cohort variant: register compass-residency as parent and compass-residency-2026-autumn, compass-residency-2027-spring as child entities. Walks through the parent-child relationship visually.
Alumni-attestation variant: ingest each graduating resident's completion as an attestation on both the residency record and the resident's natural-entity record. Demonstrates two-directional attestation linkage.
Custom-arbitration variant: swap Kleros → Custom: ICC Rules, seat: Mexico City, Spanish + English working languages; useful for the Latin-America-anchored residency pitch.
A team of four strangers who paired up on the first day of an ETHGlobal-style 36-hour hackathon. They built an AI-agent-based DeFi tool, demoed it on stage, won a $5,000 sponsor track prize. The hackathon ends Sunday night. By Tuesday morning, three of them are back at their day jobs and one is wondering whether to keep building.
This is the most common proto-entity in builder communities and the most volatile — it spins up in hours, ships real artifacts, attracts real money, and has a built-in cessation event the second the closing ceremony ends.
Who and what
Constituents: four natural persons. Two had met online before; the other two were strangers paired at the team-formation mixer. All identified to the hackathon organizer (badge scan / Devpost handle).
Activity: built a working prototype over 36 hours, submitted via Devpost, presented to judges, won a sponsor prize ($5,000 paid to the team captain's wallet on Monday).
Distinct perpetual existence: Yes, briefly. The team was referred to by project name in the closing ceremony, in sponsor tweets, and in judge feedback. The project page on Devpost persists indefinitely. Whether the team persists past Sunday night is the open question.
IRL tangible impact: Yes — won real money, public attribution, IP exists, GitHub repo with a license decision pending.
Verdict: clear pass during the event window; degrades after submission unless the team decides to continue.
Constitutive elements
Element
Form today
Strength
Constituents Being
Four named natural persons, all identified to the organizer
Strong — KYC-equivalent already done by the hackathon
Constitution
Devpost submission listing teammates + GitHub README + Discord DMs + the hackathon's own rules (which everyone agreed to)
Hybrid — hackathon rules are constitutional for the duration; teammate split is unwritten
Announcement
Devpost submission, stage demo, sponsor announcement, on-chain prize transfer
Very strong — many independent witnesses
Formal Recognition
None legally. But the hackathon organizer functions as a quasi-registrar: it issues a project ID, validates team membership, attests to the build via judges, and clears the prize.
Partial — see below
The hackathon as a quasi-registrar
The hackathon organizer plays the Primary Registrar role from the team paper, scoped to a 36-hour window:
Judges' attestation + sponsor prize = "this team built this in this timeframe"
It also produces attestations a real registrar couldn't easily issue:
Build provenance — judges and the platform witnessed that team T built artifact A in window W. That's a stronger fact than a typical patent application's prior-art declaration.
Membership attestation — Devpost's team list is signed off by all team members (everyone has to accept the team invite).
POAP / NFT trophy — already on-chain in many hackathons. Effectively an attestation NFT for the entity record.
This is interesting because it means RegistryChain doesn't need to replace the hackathon's attestation — it should be able to ingest it as a verifiable claim on the proto-entity record.
What's actually fragile
No teammate split. $5,000 lands in the captain's wallet. Two teammates assume 25% each. The captain assumed they were keeping the prize because they "did the most work." Common conflict.
No IP assignment. Code is in a public repo, but who owns it? Default copyright = each author owns their contributions. Forking into a startup later is legally messy.
No license decision. Repo is public but unlicensed. By default that means "no one can use it." Often a teammate adds MIT/Apache later without consulting the others.
No "continue?" decision protocol. Who decides whether to pursue this as a startup? On what timeline? With what default if a teammate goes silent?
No cessation protocol. Nobody writes the "we are not continuing" decision. The entity drifts; six months later one teammate posts on Twitter that they're pivoting it solo, sparking a fight.
Sponsor IP terms. Many hackathon sponsors have first-look or non-exclusive license clauses. Sponsor-track winners doubly so. The team accepted these clicking through Devpost — nobody read them.
Tax exposure on captain. Prize money lands in one wallet; IRS / local tax authority sees one person receiving $5k. The split is the captain's problem to declare.
What app.entity.id could give them today
A Venture proto-entity registered during the hackathon, ideally as a single click from the Devpost submission flow:
A Model 1 constitution listing all four teammates as named partners with declared splits.
An on-chain anchor for the captain's wallet as treasury (with the prize transfer becoming the first treasury event).
Hackathon organizer's attestation (build provenance, membership, prize) ingested as attestations on the record.
This solves the prize-split problem at the moment of submission, before it's a fight. It also gives the team a clean object to either upgrade (LLC) or dissolve (recorded cessation) within weeks.
What's still missing for them
A "team agreement" minimal-overhead constitution.Model 1 is heavier than what a hackathon team needs. The right shape is something like: four signers, equal-or-declared split, IP assigned to the entity, public-by-default repo, expires in 60 days unless extended.
Time-boxed entities. Hackathon entities have a known cessation window. The constitution should support expiresAt semantics — auto-dissolve if not affirmatively renewed.
Inbound attestation from the hackathon. Devpost / ETHGlobal would need to be a recognized issuer (Secondary Registrar in the team paper's vocabulary). Pre-arranged integration is ideal; open attestation submission is fallback.
Sponsor IP clause. Sponsor track prizes often come with IP strings. The constitution should let the team capture which sponsor terms apply, so any later upgrade preserves that encumbrance.
Prize-money split clause. Not in Model 1 today. Should be a numeric split table, callable on the entity record so the captain's wallet can disburse correctly.
"Continue or cease" ceremony. A cheap, dated, signed decision recorded on the entity. Default-to-cease if no decision within N days.
Plausible upgrade paths
Three honest outcomes — the proto record should make all three clean:
Cease cleanly. Most hackathon teams don't continue. The proto record gets a cessation event, the public registry retains it as a historical artifact, the IP and prize are settled per the declared split. No drama.
Continue as informal collective. One or two teammates keep building under the proto record itself for a few months, recruit, then form an LLC. The proto becomes the predecessor.
One teammate forks solo. The proto entity is dissolved by majority signature; the soloing teammate forms a new entity, with the original IP either licensed from the dissolved entity or carried over via signed consent. Records make this a clean transaction, not a Twitter fight.
What this example surfaces for the dashboard
Time-boxed / expiring entities belong in the model. Many proto-entities (hackathons, seasonal collectives, project-specific freelance crews) have a known sunset. The current schema has no expiresAt or auto-cease-unless-renewed semantics.
Prize-money / revenue-split clauses are first-class for hackathon teams and for the Cooperative archetype. Missing from Model 1.
External-registrar attestation ingest — Devpost, ETHGlobal, MLH, Encode, and the major sponsor APIs can produce verifiable claims about hackathon entities. The dashboard should be able to import these as primary attestations.
Hackathon-as-onboarding — this is the strongest funnel for app.entity.id's public registrar. A "register your hackathon project" path could be embedded into Devpost / ETHGlobal flows with one-click team list import.
Cessation as a first-class lifecycle event — every example so far has assumed entities mostly persist. Hackathon projects make explicit that cessation is the common case and needs the same care as inception.
Default-to-equal split + named-deviation pattern — a useful UX shortcut: "all four equal unless someone disagrees by submission deadline." Makes the right thing the default and surfaces the disagreement before the prize hits a wallet.
Why this is strategically interesting for RegistryChain
Hackathons are the densest concentration of crypto-native builders forming proto-entities in compressed time, with explicit submission rails and a community that already accepts on-chain attestations (POAPs, NFTs, sponsor airdrops). It is the natural distribution channel for app.entity.id's public registrar: high builder concentration, real money on the line, an existing organizer-as-quasi-registrar to integrate with, and an outcome distribution (mostly cease, some continue) that exercises the full lifecycle in weeks rather than years.
The default proto-venture. Two friends who met at a conference agree to build a product together. They ship a landing page, a working MVP, and start charging customers. No paperwork has been filed. They have a Stripe account in one cofounder's personal name, a domain, a GitHub org, a Notion doc that loosely describes who does what, and an unstated 50/50 split.
Who and what
Constituents: two named natural persons. Both contribute labor; one contributes initial capital ($8k); the other contributes a working prototype.
Activity: software product sold via subscription. Revenue real, growing month-over-month.
Surface: product domain, GitHub org, Stripe account, shared bank account opened under cofounder A's name marked "DBA ".
R-Entity test
Distinct perpetual existence: Yes — the product is referred to as a thing-in-itself by both founders and by customers. The "company" outlives any one work session, and either founder leaving would not end it (though it would damage it).
IRL tangible impact: Yes — paying customers, real money flowing, contractual obligations to subscribers (uptime, refunds), public-facing terms of service.
Verdict: clear pass.
Constitutive elements
Element
Form today
Strength
Constituents Being
Two natural persons, both volitional
Strong
Constitution
Oral agreement + Slack chat log + the code itself + a half-written Notion doc
Weak — no written ownership split, no vesting, no IP assignment, no death/incapacity clause, no dispute resolution
Strong externally, weak internally (no announcement to a registrar)
Formal Recognition
None
Absent by default — they're "going to incorporate soon"
What's actually fragile
No IP assignment. If one cofounder leaves, ownership of the code is contested by default — copyright vests in the author.
No vesting. Cofounder B could leave on month 3 and claim 50% forever.
Tax exposure on one person. Revenue currently flows to cofounder A's personal SSN. Both share the upside; only one is legally on the hook for taxes today.
No limited liability. If a customer sues over a data breach, both cofounders' personal assets are exposed.
Cap table assumed, not recorded. "50/50" is a story they tell each other; no document binds it.
What app.entity.id could give them today
A Venture proto-entity on the public registrar:
- A persistent universal identifier (e.g. acme.venture.public.entity.id) — bindable to a domain and used in invoices, ToS, and pitch decks.
- A Model 1 constitution with both founders as named partners, an explicit split, and a (declarative) statement of purpose.
- An on-chain anchor for ownership claims that pre-dates any subsequent legal form.
What's still missing for them
Vesting schedule (not in Model 1 today).
IP assignment clause.
A "successor entity" pointer for the inevitable upgrade to a Delaware LLC or C-Corp — the proto record should be the predecessor in the resulting legal entity's chain of custody, not get abandoned.
Treasury custody — the Stripe / bank account is still in one cofounder's name. The proto-entity has no on-chain treasury either.
Plausible upgrade path
Cofounders register acme.venture.public.entity.id with Model 1 constitution + named partners.
At product-market-fit, they form a Delaware C-Corp via a Stripe Atlas / Clerky-style flow.
The Delaware C-Corp record on delaware.entity.id links back to the proto record as predecessor (currently no field for this — gap).
The proto record stays as historical anchor; the Delaware record carries the live status going forward.
What this example surfaces for the dashboard
Vesting + IP are first-class clauses missing from Model 1. They're more important to a real cofounder pair than 80% of what standard-llc covers.
Predecessor / successor pointers between a proto record and a later jurisdictional record should be modeled — the team paper has successorEntity, but not the reverse-direction lookup or the proto→de-jure ceremony.
Treasury is missing entirely. A proto-venture's treasury is the cofounder's Stripe + bank. We could attach an on-chain multisig as the "real" treasury, but the off-chain Stripe is what actually holds the money.
Single-cofounder variant (one person shipping under a brand) probably deserves its own example — does the constitutional shape change with one constituent?
A learning community formed around a specific craft (writing, music production, smart contract security — pick one). It started as a Discord server, grew to ~700 members, runs weekly events, has three admin moderators, and accepts contributions to a 3-of-5 Gnosis Safe on Base that pays speakers, sponsors prizes, and covers the domain renewal.
Who and what
Constituents:
Three named admins (one founder, two long-time members who were elevated).
~40 active members who participate in events and votes.
~700 lurkers who consume content; some are tipping members.
Activity: weekly Discord events, quarterly meet-ups in one city, a public website, a sponsored newsletter, a multisig that has paid out ~$18k in the last 12 months to speakers and prize winners.
Surface: community domain, Discord server, on-chain multisig, a Coordinape circle, a public roadmap page on Notion, a Twitter/X account.
R-Entity test
Distinct perpetual existence: Yes — multiple admin handoffs have already happened. The community is referred to by name as a thing; events continue when any one admin steps back.
IRL tangible impact: Yes — real treasury, real payments to humans, real reputational exposure (sponsors put their name on it).
Verdict: pass, possibly stronger than the handshake-startup because the constituency is larger and the lifecycle is more clearly visible.
Constitutive elements
Element
Form today
Strength
Constituents Being
Three admins (named) + members (semi-anonymous behind handles)
Public website, Discord invite, multisig address shared in pinned message
Strong
Formal Recognition
None — not an unincorporated association anywhere on paper
Absent
What's actually fragile
Treasury custody = admin personhood. The three signers' real-world identities are partially unknown to each other. If one disappears, the 3-of-5 still functions, but recovering a lost signer involves social proof and trust.
Liability ambiguity. If someone slips at the in-person meet-up, who is sued? The host's home insurance? The admins personally? Nobody knows.
No tax position. Sponsorships received in stablecoin: who declares them as income? Currently nobody does.
No succession plan for admins. "Elevated by vibes" is the existing process.
Member rights are vague. Are there members entitled to vote? On what? With what weight?
What app.entity.id could give them today
An Association proto-entity on the public registrar:
- <community>.association.public.entity.id as the canonical identifier — bindable to the domain, signed by the multisig.
- A Model 1 or Model 2 constitution listing the three admin signers as named partners.
- A reference field for the multisig (currently shoehorned into the entity contract account model — fits well).
What's still missing for them
Member class — Model 1 and Model 2 model partners/quotaholders, not members with one-person-one-vote rights. There's no clause for "tipping member with no governance power" vs. "active member with voting rights."
Treasury thresholds — the Safe enforces 3-of-5 on the chain, but the constitution should reference and bind that as the entity's amendment / spending power.
Code-as-constitution clause — when "the multisig says X" should override the written text, that needs to be stated. Otherwise we get two constitutions out of sync.
Public-benefit / non-distribution clause — the community is not extracting profit to its admins. That should be declared so it can later upgrade to a Foundation or non-profit without legal/legitimacy whiplash.
Plausible upgrade paths
Three credible directions, depending on what the community wants:
Stay proto. Many communities never need de-jure recognition; the proto record gives them everything they need (identity, governance reference, treasury reference) without filing fees.
Upgrade to Foundation (Cayman Foundation Company, Swiss Stiftung, or Panamanian Foundation) when sponsors start asking for receipts and when the treasury exceeds a threshold.
Upgrade to DAO LLC (Wyoming W.S. 17-31 or Marshall Islands) if the community wants explicit member voting on a token and limited liability for participants.
What this example surfaces for the dashboard
Members are missing from public-registrar constitutions. Today every public entity type uses LLC-shaped "partners." Associations need members with optional voting power and contribution history.
Public-benefit / non-distribution toggle is a single clause that flips an entity's plausible upgrade target from "LLC" to "Foundation." Worth modeling.
Multisig as constitutional power — the dashboard should let an entity declare that a named multisig holds amendment / treasury authority, and resolve that on chain.
Pseudonymous constituents — the team paper's Disclosure Matrix would call this "disclosed-or-ish ownership, disclosed operations." The dashboard should let admins choose a Disclosure Matrix quadrant and surface what's required to live there.
This is where the gap between "Association" label and "LLC-flavored paperwork" hurts most visibly.
A personal AI agent running on a single operator's always-on server. It has a system prompt, a memory store, a set of MCP tools and shell access, and channels into Telegram / Discord / SMS / WhatsApp. It acts in the operator's name — drafts messages, manages calendar, ships code, talks to APIs that cost money — and is identified to third parties by handles distinct from the operator's own.
(This example is real: husagent itself.)
Who and what
Constituents:
One natural person (operator) — identified, with passport and accounts behind everything.
One LLM provider (Anthropic / OpenAI / etc.) — provides the inference substrate, not authorship.
N tools / MCP servers — each grants the agent a capability (filesystem, shell, Stripe, Gmail, Asana, etc.).
Activity: drafts emails, posts updates, manages calendars, ships code commits, spends money via the operator's payment methods, holds private conversations with the operator's contacts.
Distinct perpetual existence: Edge case. The agent persists across sessions (memory store), has a stable identity (handles, domain, MCP endpoint), and can be referred to by third parties as a separate actor ("ask Hus's agent"). But its existence is fully dependent on operator decisions, model availability, and a running server.
IRL tangible impact: Yes — sends real messages, spends real money, makes commitments on the operator's behalf, accesses confidential systems.
Verdict: edge pass. Closer to a "tool with persistent identity" than a fully separate entity, but the team paper's frontier-entity branch explicitly admits this case.
Constitutive elements
Element
Form today
Strength
Constituents Being
One operator (volitional natural person). LLM provider is not a constituent — it's infrastructure
Strong if attribution chain is explicit; weak by default
Constitution
System prompt + CLAUDE.md + tool grants + capability scopes
Code as constitution — strong technically, weak as a document
Announcement
Handles, domain, optional disclosure in bot bios
Variable — often missing on first deploy
Formal Recognition
None
Absent
Disclosure Matrix position
This is the team paper's headline AI scenario. Without an attribution chain:
Ownership of the agent (who operates it) — usually undisclosed in chat / Discord interactions.
Operations of the agent (its prompt, memory, tools, decision logic) — fully opaque.
That puts a default personal AI agent in the Anonymous Ownership – Private Operations quadrant — the non-compliant corner per FATF / OECD / EU AI Act logic. The team paper argues such agents must reposition into one of:
Disclosed Ownership – Private Operations (KYA attests the operator chain; the agent's logic stays private) — typical KYA target.
Anonymous Ownership – Disclosed Operations (operator stays anonymous, but prompt + tools + memory are public/inspectable) — open-source agent path.
Disclosed Ownership – Disclosed Operations — both disclosed; max-trust open-source.
What app.entity.id could give it today
A sub-entity record under the operator's natural-entity identifier:
- husagent.agent.<operator>.entity.id — persistent universal identifier for the agent, distinct from the operator.
- KYA attribution chain: agent → operator (resolves to a named natural person record).
- Optional secondary attestations: GDPR compliance, code provenance, safety constraint set, audit signature.
What's still missing for them
KYA attestation format — there's a "KYA framework" paper referenced but not yet a concrete attestation schema in src/data/.
Capability disclosure — what tools the agent holds, with what scopes, and which third parties it can act against on the operator's behalf. This is the AI-agent equivalent of a power-of-attorney scope.
Tool revocation chain — when the operator revokes a tool grant, that should show up on the entity record as a lifecycle event.
Inference-provider lineage — when the agent's model is upgraded (Opus 4.6 → 4.7), is that an amendment event? Probably yes, because behavior changes materially.
Inheritance / shutdown — when the operator dies or sunsets the agent, what's the cessation protocol? An agent that keeps sending messages after operator death is a public-safety problem.
Plausible upgrade path
Operator registers <name>.agent.<operator>.entity.id as a proto AI-agent record under their natural-entity identifier.
As the agent gains tools, each grant produces an attestation on the record (or one composite capability attestation, updated on change).
If the agent ever needs to enter commercial relationships in its own name (e.g. operate a Stripe account, sign contracts), the operator forms an LLC wrapping the agent, and the proto record becomes the predecessor of the LLC entity record.
What this example surfaces for the dashboard
Sub-entity / parent-entity relationships — agents are sub-entities of operators. The current namespace nesting (<name>.<type>.<registrar>.entity.id) supports this structurally, but the UI doesn't model "operator owns these N agents" as a first-class relationship today.
Capability disclosure is a unique attestation type for agents and probably for humanoid / autonomous-vehicle entities later. Worth modeling separately from generic attestations.
Disclosure Matrix toggle belongs in the entity record itself, not just the constitution body.
Lifecycle events for AI agents (tool grant, model upgrade, prompt change, shutdown) are higher-frequency than for legal entities. The amendment system needs to handle that volume.
Cessation protocol — most legal entities have a dissolution process. AI agents need an explicit shutdown / handoff process, especially when the operator dies.