Operator Economics

How operators monetize within the Open Crown Standard.

Standard Reference: Open Crown Standard v1.0.0 Sections: 1.4 Protocol vs Operator Model, 7.5 Deal Constraints, 7.6 Fee Structure

1. Overview

The Open Crown Standard separates protocol (on-chain registry, immutable rules) from operators (services, UX, facilitation). Operators provide value-added services and earn fees for their work. The protocol defines fee caps; operators set their own rates within those caps.

This document describes the fee types available to operators, the marginal bracket system for deal facilitation, governance constraints on fee parameters, and practical guidance for configuring an operator instance.

2. Fee Types

Operators earn revenue from two primary sources: crown claim fees and deal facilitation fees. Both are subject to protocol-level constraints enforced on-chain.

2.1 Crown Claim Fees

When a verified token owner mints a Crown, they pay a one-time claim fee.

Anti-squatting is handled by first-claim-wins plus the heartbeat reclaim mechanism. Operators MAY layer additional off-chain pricing or rate-limiting in their own policy, outside the protocol envelope.

2.2 Deal Facilitation Fees (Tiered)

Operators facilitating crown deals (buyouts, migrations, project transfers) earn facilitation fees. The Open Crown Standard permits a marginal rate schedule with the following maximum rates:

Operators MAY set rates lower than the schedule above. The schedule represents the maximum rates the registry permits.

Hard caps:

2.3 Protocol Tax

Every completed deal incurs a 2% protocol tax (capped at $10,000) directed to the DAO treasury. This tax is separate from the operator's facilitation fee and is not configurable by operators. The protocol tax applies regardless of the operator's rate configuration.

3. Fee Calculation: Marginal Rate Brackets

Bracket rates apply marginally -- like tax brackets. Each rate applies ONLY to the deal value within that range, not to the entire deal.

3.1 Bracket Arithmetic

For a deal of value V at maximum operator rates:

bracket_1 = min(V, 25,000) * 0.05
bracket_2 = min(max(V - 25,000, 0), 75,000) * 0.03
bracket_3 = min(max(V - 100,000, 0), 400,000) * 0.02
bracket_4 = max(V - 500,000, 0) * 0.01

facilitation_fee = min(bracket_1 + bracket_2 + bracket_3 + bracket_4, 20,000)
protocol_tax     = min(V * 0.02, 10,000)
total_fees       = facilitation_fee + protocol_tax

The 10% hard ceiling is enforced as a final check: total_fees <= V * 0.10.

3.2 Worked Examples

3.3 Detailed Walkthrough

On a $100,000 deal at maximum rates:

1. First $25,000 at 5% = $1,250
2. Next $75,000 at 3% = $2,250
3. Total facilitation fee = $3,500 (3.5% effective rate)
4. Protocol tax = $2,000 (2% of $100K)
5. Total fees = $5,500 (5.5% effective rate)

On a $2,000,000 deal at maximum rates:

1. First $25,000 at 5% = $1,250
2. Next $75,000 at 3% = $2,250
3. Next $400,000 at 2% = $8,000
4. Remaining $1,500,000 at 1% = $15,000
5. Subtotal = $26,500, but the $20,000 cap applies: facilitation fee = $20,000
6. Protocol tax = 2% of $2M = $40,000, but the $10,000 cap applies: protocol tax = $10,000
7. Total fees = $30,000 (1.5% effective rate)

4. Fee Parameter Governance

Operators have full control over their fee schedule within the protocol-defined envelope. The DAO can adjust the envelope through governance proposals (see OCP Process), but cannot retroactively alter fees on pending deals.

5. Fee Snapshots

Fee parameters are snapshotted at deal announcement time. When initiateDeal() is called (see Standard 7.8.1), the registry records the operator's current fee configuration for that deal. If the operator subsequently changes their fee schedule, the change applies only to NEW deals. Existing deals execute under the rates that were in effect at announcement.

This design protects deal participants from mid-deal fee changes during the mandatory 7-day announcement period and up to 30-day deal window.

6. Operator Revenue Projections

The following scenarios illustrate operator revenue under different activity levels, assuming maximum rates.

6.1 Claim Revenue

At the default $15 base fee, monthly claim revenue scales linearly with claim count:

6.2 Deal Revenue

Revenue scales with deal volume and size. Operators who build strong deal-matching capabilities and facilitate larger transactions capture disproportionately more value.

7. Operator Onboarding Checklist

1. Register as an operator in the OpenCrown registry contract.
2. Configure fee brackets and caps via setFeeBrackets().
3. Set treasury address to receive facilitation fees.
4. Build deal facilitation UX (see Appendix F: Operator Resolution Guidance in the standard).
5. Test on devnet/testnet before going live.
6. Monitor fee parameter governance proposals that may affect rate caps.

8. Reference Implementation

Chain Daddy operates as the reference operator with the following default configuration:

Other operators are free to set different rates within the registry caps. Operators competing on price may set lower brackets, while operators offering premium services (legal coordination, multi-party escrow, cross-chain migration support) may charge at or near the maximum rates.

9. Comparison to Traditional Alternatives

The OpenCrown deal structure provides a cost ceiling that traditional services cannot match at scale. The on-chain enforcement of fee caps, announcement periods, and buyer protections replaces the overhead of legal negotiation and escrow administration.

10. Key Takeaways for Prospective Operators

1. Predictable revenue model. Claim fees provide steady baseline income; deal fees provide upside.
2. Protocol-enforced caps protect users. With the maximum rates fixed on-chain, operators differentiate themselves on service quality (deal-matching, UX, support, integrations).
3. Marginal brackets reward larger deals. Effective rates decrease as deal size increases, aligning operator incentives with facilitating meaningful transactions.
4. Fee snapshots prevent gaming. Neither operators nor governance can alter fees on in-progress deals.
5. Low barrier to entry. Registering as an operator requires only a contract call and treasury address configuration. The protocol handles verification, escrow, and enforcement.