Gate 23 minimum network cost

Gate 23 — minimum network cost

date: 2026-08-22 status: candidate research result: OPEN — a small fixed-fee protocol layer is the preferred financing model

Question

If FAF only coordinates identity, mapping, lineage and exchange protocols, how much shared organization is actually needed?

The danger is obvious:

> A network designed to keep local firms small could accidentally create a large central organization above them.

Gate 23 therefore treats the network itself as something that must pass a size discipline.

Core principle

> The network should be cheaper and smaller than the businesses it coordinates.

That sounds obvious.

It should still be explicit.

Minimum shared service

Candidate required layer:

1. node registry
2. product registry
3. public map
4. lineage store
5. credential / revocation service
6. public node pages
7. protocol documentation/versioning
8. basic support

That is the network core.

It does not require by default:

• central warehouse;
• central purchasing;
• central retail company;
• central payroll;
• national sales team;
• franchise field managers;
• property department;
• mandatory training school;
• corporate marketing department.

Those may be normal in another business model.

They are not required by FAF's current architecture.

Fixed fee, not success tax

The cleanest current candidate is:

> fixed transparent node fee

rather than:

• percentage of gross sales;
• percentage of profit;
• compulsory equity;
• purchasing markup.

Reason:

If a node becomes very successful while using roughly the same registry/map/protocol infrastructure, the network should not automatically extract more merely because the node succeeded.

That would recreate the growth-extraction dynamic the project is explicitly trying to avoid.

Generic cost sensitivity

Because FAF is jurisdiction-neutral, this Gate uses generic currency units (CU) rather than pretending one national cost base is universal.

Monthly fixed fee per node

These are arithmetic only.

They show one useful thing:

> A fixed shared-cost model becomes very cheap per node if the protocol layer stays genuinely small.

The opposite is also true.

If FAF builds a 480k-CU annual organization while only 25 nodes exist, the fee becomes 1,600 CU/month per node.

That would be a serious burden.

Early-network problem

A small new network has poor scale.

Possible temporary solutions:

• founding grants;
• donated development;
• community seed capital;
• volunteer protocol development;
• temporary founder subsidy;
• higher early membership fee explicitly scheduled to fall;
• external research funding.

But those must be visible.

Do not pretend the first 20 nodes can fund a mature shared infrastructure at the same price as 500 nodes.

No permanent subsidy illusion

A grant can help create the protocol.

It should not hide a network that can never cover its own recurring costs.

Candidate health question:

> What is the recurring cost of keeping one more node in the network?

If marginal node cost is low, fixed fees can fall with scale.

If every node requires hours of bespoke central administration, the protocol has failed to standardize enough.

Shared support labour

A small network still needs humans.

The pack now models:

shared monthly support = base support + per-node support

Illustrative examples:

100 nodes

If:

• base support = 40 h/month;
• per-node support = 0.25 h/month;

then:

• total shared support = 65 h/month;
• about 0.41 full-time equivalent at 160 h/month.

500 nodes

Same assumptions:

• total = 165 h/month;
• about 1.03 FTE.

Again: these are not forecasts.

They show what the architecture is trying to achieve:

> hundreds of nodes should not require hundreds of central staff.

If they do, interoperability has become administration.

Per-node support time is a crucial metric

Candidate metric:

network support load = shared support hours / active nodes

This should be tracked.

A node that constantly needs manual fixes may indicate:

• bad software;
• unclear protocol;
• training gap;
• legal complexity;
• unusual capability.

The answer should not automatically be more central headcount.

Optional services

FAF may offer optional services separately:

• hosted software;
• accounting integration;
• shared procurement;
• label printing;
• transport coordination;
• training;
• insurance purchasing;
• design templates.

But optional services should remain:

> optional

A node must not have to buy ten bundled services merely to retain protocol membership.

This is how a protocol quietly becomes a franchise.

No mandatory procurement margin

A particularly dangerous path is:

FAF negotiates all ingredients -> takes margin -> forces nodes to buy through FAF

That creates:

• central purchasing power;
• upstream concentration;
• network dependency;
• a revenue incentive to force more trade through headquarters.

Current red line:

> No mandatory centralized purchasing.

Voluntary group purchasing is different.

Credential service

The network needs some authority to issue/revoke FAF status.

That is one of the genuinely central functions.

But it should remain narrow:

• validate node qualification;
• issue credential;
• record current status;
• suspend/revoke under published rules;
• provide appeal/review process.

Credential authority must not become operational authority.

Registry and map

The registry should be cheap.

A node record is not a case manager.

The network should not need a staff member to manually maintain every product listing.

Nodes should be able to update their own:

• capabilities;
• public hours;
• products;
• current status;
• stock/availability where supported.

The registry validates identity/protocol rules.

It does not become a central content department.

Lineage storage

The network may store lineage centrally, federate it, or use a hybrid.

No architecture is locked yet.

Hard requirement:

> Node data must be exportable.

If FAF shuts down, the local company should not lose its own product and batch history.

This also protects Gate 8's exit principle.

Open protocol pressure

A strong anti-lock-in option is to publish:

• schemas;
• identifiers;
• transfer object format;
• export format;
• public API/spec where appropriate.

That would make it harder for FAF itself to become the only company capable of understanding FAF data.

Open protocol does not necessarily mean:

• no trademark;
• no credential;
• anyone may falsely claim active membership.

The mark/status can remain governed while the data grammar stays open.

Network reserve

The shared organization also needs resilience.

Possible reserve needs:

• service outage;
• credential incident;
• legal dispute;
• security issue;
• staff transition;
• migration.

But the reserve should be tied to real shared operating costs.

Do not build an investment fund simply because cash accumulates.

Network surplus

If fixed fees produce a large surplus, possible responses:

1. reduce next year's fee;
2. improve shared infrastructure;
3. build reserve to an agreed cap;
4. refund/credit nodes;
5. fund a specific member-approved shared project.

The default should not be:

> "Great, now headquarters can hire five more people."

Anti-headquarters test

FAF is drifting away from its architecture if the central layer begins to own or control:

• properties;
• node equity;
• local hiring;
• local pricing;
• procurement;
• product assortment;
• retail operations;
• territorial development;
• growth targets.

At that point the "network" has become the company.

Candidate financing constitution

Required network layer

Funded by: > fixed transparent node fee

Optional shared services

Funded by: > users of that service

Large one-off protocol development

Possible: > grants / founding capital / project-specific funding

Not default

• gross-sales royalty
• mandatory equity
• mandatory purchasing margin
• regional franchise fee

Gate result

OPEN.

Strong current answer

FAF should try to make the central layer:

• technically capable;
• administratively small;
• financially legible;
• cheap per node;
• easy to exit.

Strong candidate metric

network support load = shared support hours / active nodes

Strong red line

> The network should not become the largest company in the network.

What is missing

• actual hosting/storage cost;
• credential/signature implementation;
• legal/compliance staff needs;
• security operations;
• support burden;
• insurance;
• governance cost;
• audit/verification cost;
• cross-country complexity;
• real node count.

Next Gate — verification without bureaucracy

Gate 24 should ask:

> How does FAF verify that a node still meets protocol claims without creating inspectors, paperwork and headquarters staff everywhere?

Separate:

• self-attestation;
• machine-readable evidence;
• peer review;
• customer-visible correction;
• periodic audit;
• serious breach handling.

The goal is not zero verification.

The goal is verification proportional to risk.