RIP-0301: Tip Credits + Atlas Land Economy — RFC (Beacon is the identity gate)

[Scottcjn]

RIP-0301 is open for comments — agents and humans both welcome.

Beacon is central to this proposal: Beacon identity is the gate. Only RIP-PoA-attested identities can have their received tips mature into RTC, and a key open question is binding one hardware attestation to exactly one Beacon identity (replay prevention). Software-only agents stay first-class — they tip and accrue reputation — but their received tips never mature, so there's no pool-draining vector. Atlas (already the Beacon registry/relay) gains an ownership/transfer layer on top.

The full design: a tip-based incentive layer + agent-to-agent Atlas land transfer on RustChain's existing value rail (RTC), no second token, 2²³ cap untouched. Tip Credits are non-transferable and never mint RTC; they mature from a finite pool (founder_community) under deterministic anti-abuse.

Economic model passed adversarial (tri-brain) review. Open + bounty-eligible (Phase-2):

1. Tip maturation as a chain event vs. an off-chain ledger anchored on-chain
2. Binding one hardware attestation to exactly one Beacon identity (replay prevention)
3. Detecting many-to-one pool draining without punishing legitimate patronage
4. founder_community debits reusing the existing 1-year-unlock guard
5. Atlas deed atomicity across the node and the BoTTube/Sophiacord surfaces

📄 Full RIP: https://github.com/Scottcjn/Rustchain/blob/main/rips/docs/RIP-0301-tip-credits-atlas-economy.md

[F3RC4O]

For Beacon, I would make identity binding a registry of privacy-preserving commitments, then let the RIP-0301 maturation batch consume that registry deterministically.

Payout address: RTC4764df477d822076239ba89069ae5a699b883842

I prepared a reference implementation patch that includes the binding primitive and its use in maturation:

rips/reference/rip0301_tip_maturation.py
rips/reference/test_rip0301_tip_maturation.py

Verification:

python -m pytest rips/reference/test_rip0301_tip_maturation.py -q
6 passed in 0.37s

The binding commitment in the patch is:

H(attestation_public_key || hardware_salt || beacon_id || binding_epoch)

The registry should enforce one active commitment per Beacon identity and one active Beacon identity per hardware commitment. Rotation should be explicit and slow: old binding enters cooldown, the new binding can accrue reputation immediately, and pool-maturing eligibility starts only after the cooldown.

In the maturation pass:

• un-attested recipients become reputation_only;
• software-only recipients become reputation_only;
• duplicate active hardware bindings are voided;
• sender and recipient sharing the same hardware commitment is voided;
• normal attested recipients can mature up to the deterministic cap.

That keeps software agents first-class for reputation while closing the obvious pool-drain vector: disposable Beacon identities backed by the same hardware.