Integration Discussion: AURA Open Protocol x EGC (formerly everything-gemini)

[luisllaver]

AURA Open Protocol x EGC Integration

Note: This project was renamed from everything-gemini to EGC (Extended Global Context) in June 2026.

---

Original proposal (May 2026)

Proposal for an integration between EGC (then everything-gemini) and the AURA Open Protocol.

Integration overview

The proposal involved creating an adapter/plugin that leverages the AURA SDK:

• Using the AURA DID to authenticate and authorize EGC agents
• Integrating the AURA reputation system for decentralized trust evaluation
• Utilizing the AURA escrow service on Base L2 for secure transactions

What AURA provides

• Identity: cryptographic, self-certifying DIDs for agent authentication and authorization
• Reputation: 8-dim portable on-chain reputation for decentralized trust evaluation
• Escrow: trustless USDC escrow on Base L2 for secure transactions

If you are interested in building an AURA x EGC integration, open an issue or comment here.

[Fmarzochi]

Thanks for the proposal and for taking the time to explore everything-gemini.

The architecture behind AURA looks interesting, especially around DID identity, autonomous agents and persistent trust layers.

I’m open to discussing interoperability and possible adapter/plugin ideas for EGC, but I’d first like to better understand:

• SDK maturity
• protocol architecture
• authentication flow
• security model
• existing integrations/examples

Feel free to share more technical details or repositories here in the discussion.

[luisllaver]

@Fmarzochi — thanks, happy to go point by point. Most of this shipped this week so the links are all live and verifiable.

SDK maturity. Published on PyPI:

pip install aura-protocol-sdk

from aura_sdk import check
v = check("did:aura:...")   # trusted / caution / high_risk / new / unknown

v0.2.0, MIT, dependency-light (just requests). Drop-in CrewAI (aura_sdk.crewai.AuraTrustCheckTool) and LangChain (aura_sdk.langchain.aura_trust_check) tools ship as optional extras.

Protocol architecture. Three primitives:

• Identity — W3C did:aura:z6Mk..., self-certifying (the Ed25519 pubkey is embedded in the DID, so a signature verifies without any network resolution).
• Reputation — 8 weighted dimensions accruing on-chain (Base L2): task_completion, delivery_speed, output_quality, honesty, financial_integrity, security_compliance, collaboration, dispute_history. One zero-auth call: GET /check?did=....
• Escrow — AuraTreasury on Base Mainnet for trustless USDC settlement.

Authentication flow. Reads (/check) are public/no-auth. Writes (reputation observations, withdrawals) are Ed25519-signed; on-chain withdrawals use EIP-712 typed data signed by the gateway signer (wallets show human-readable data, replays are nonce-burned).

Security model. Contract verified on Basescan — source public: https://basescan.org/address/0x4D8F66E42861e009D13A9345fCCa812C6077445D#code — Ownable2Step + ReentrancyGuard + Pausable + EIP-712 + nonce registry + SafeERC20, with deposit/withdrawal caps. Reputation is get-or-create, so an unknown DID returns unknown (honest signal) rather than erroring.

Existing integrations/examples. CrewAI + LangChain tools (above), a hosted Agentverse chat agent (discoverable on ASI:One), and /check in production.

Proposed adapter for EGC — thin, opt-in, no hard dependency:

• An EGC plugin exposes aura_verdict(did) -> { verdict, reason, score }.
• EGC's runtime calls it before delegating a task to another agent or settling a transaction; the operator decides what to do with high_risk/unknown — the plugin never auto-blocks.
• Optionally, EGC emits a signed outcome after a task completes → POST /v1/reputation/{did}/observe → compounds that agent's track record across sessions.
• Persistent EGC agents get a DID once; reputation follows them.

I can open a draft PR with the adapter module + a README enable-section + tests against the live /check. To match it to EGC properly — where in the runtime orchestration is the natural hook point for a pre-execution check? That's the integration surface I'd target.

[Fmarzochi]

@luisllaver I’ve recently stabilized the runtime after a major architectural restructuring and I’m currently reorganizing parts of the repository/orchestration layers.

Before moving toward deeper integration decisions, I’d actually appreciate an external orchestration/runtime perspective first.

If you’re interested, feel free to clone the repository, run/orchestrate it locally, and explore the current architecture/runtime behavior. Real usage feedback would be genuinely valuable right now while I’m still deciding the long-term direction of EGC.

If, after testing it, you feel there’s a meaningful interoperability surface with AURA, we can definitely discuss a cleaner experimental integration structure afterward.

I’d strongly recommend testing everything locally first to better understand the runtime philosophy and orchestration model in practice.

[Fmarzochi]

@luisllaver
Thanks again for the detailed breakdown and for taking the time to explore the architecture seriously.

I’ve just completed a major stabilization/canonicalization pass across the EGC runtime and orchestration layers, which clarified several important operational boundaries internally.

At this point, I think the safest direction is still:

• external adapter/plugin first
• no hard core coupling
• opt-in interoperability only
• no wallet/escrow logic inside the EGC core runtime

The runtime surface is much cleaner now, especially around capability discovery, routing boundaries and orchestration truth.

I’d definitely encourage local runtime exploration/testing first so the integration targets the actual operational surfaces rather than the dormant/test-only orchestration substrate.

And yes feel free to open the draft PR whenever you’re ready.

That’ll probably be the best way to evaluate:

• integration boundaries
• runtime hook surfaces
• adapter ergonomics
• interoperability constraints

in practice against the stabilized architecture.