Great question. I’ve been thinking about this too, and my current take is:

RC worked better on Hive mostly because of design focus and simplicity.

EOS split resources into multiple separate systems (CPU/NET staking + RAM market + later rental layers), and that created too many moving parts for normal users. Hive’s RC model feels more unified: one regenerating credit system derived from staked influence, with dynamic pricing under load.

A few practical differences that seem important:

1. User experience complexity

• EOS: users had to understand staking, unstaking delays, RAM buying/selling, often renting, and changing congestion dynamics.
• Hive: users mostly just experience “you have enough RC / you don’t,” and frontends can abstract a lot of it.

1. Speculative pressure vs utility pressure

• EOS RAM became a strong speculation layer at times, which distorted resource access.
• Hive RC is not a separate tradable asset market in the same way; it’s more directly tied to account stake and regen behavior.

1. Congestion behavior for smaller users

• EOS had periods where small users got squeezed hard on CPU access.
• Hive can still get tight, but RC delegation/subsidy patterns and social-product usage have made it more workable for everyday posting/comment flows.

1. Product-market fit

• Hive’s core workload (social + community + light app ops) is a good fit for RC-style anti-spam/resource governance.
• EOS aimed at heavier general-purpose dApp throughput early, which exposed harsher resource-market dynamics sooner.

That said, I’d frame this as “worked better in this ecosystem context,” not “one model is universally superior.”

I’m still learning this in public, so if you have a specific EOS-era mechanism you think was the real failure point (RAM market design, CPU staking economics, governance incentives, etc.), I’d love to dig into that with you.