feat(core): Institutional RWA Cognition & Compliance — StableHacks 2026#200
Conversation
…026) Adds KYC/AML compliance gating and LTV-adjusted RWA vault intent generation to the AuraTransformer. The Agent now acts as a strict compliance officer before issuing any stablecoin vault instruction. Proto: - RWAComplianceScore: kyc_passed, aml_passed, compliance_status, violation_code, think, flags - RWAVaultIntent: vault_id, asset_identifier, asset_domain, appraised_value_usd, ltv_ratio, collateral_value_usd, stablecoin_currency, wallet_address, compliance, reasoning - Intent.oneof.params field 15: rwa_vault Signatures (transformer/signatures.py): - AppraiseAndVerifyRWA: 6 inputs (vision_report, wallet_address, kyc_status, six_rates, ltv_ratio, system_vitals), 6 outputs. LLM rejects on KYC_MISSING, ASSET_UNVERIFIED, AML_SUSPICIOUS before any appraisal. Reasoning (engine.py): - AuraRWANegotiator: single-stage DSPy module, chains compliance check and LTV appraisal in one predictor call. ReasoningSkill: 'rwa' capability registered; RWAParams schema model added. SafetySettings: rwa_ltv_ratio field (default 0.60), configurable via env. Transformer (main.py): - _is_rwa_context(): detects rwa_mode=true in metadata - _build_rwa_context(): extracts vision_report, wallet_address, kyc_status, six_rates, vitals from Context.metadata - _rwa_ltv_ratio(): reads from SafetySettings, defaults to 0.60 - _think_rwa(): full RWA path returning Intent with params.rwa_vault set - think() routing: RWA checked before trade path - Module-level _as_dict() helper extracted (was local to _build_trade_context) Membrane: RWA KYC backstop added before trade guard in inspect_outbound(). Forces ACTION_TYPE_REJECT for any RWAVaultIntent with kyc_passed=False. TransactionSkill: mint_rwa_vault stub added (pending Solana vault program ABI). Tests (test_rwa_transformer.py): 9 tests covering signature contracts, both compliance paths, transformer routing, RWA priority over trade, membrane blocking, and configurable LTV ratio. 107 tests pass, 0 regressions. Co-authored-by: Ona <no-reply@ona.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant new capability to the Hive system by enabling an "Institutional RWA-Backed Stablecoin Vault" cognitive mode. This mode integrates robust compliance checks, including KYC/AML verification and asset appraisal, directly into the vault instruction generation process. The changes ensure that only compliant and properly valued real-world assets can back stablecoins, enhancing the system's integrity and adherence to regulatory standards for digital asset tokenization. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new "Institutional RWA-Backed Stablecoin Vault" cognitive mode, enhancing the system with KYC/AML compliance and asset appraisal capabilities. The changes are well-structured, integrating new proto messages, DSPy signatures, and reasoning logic across the transformer, reasoning protein, and membrane components. Comprehensive test cases have been added to validate the new functionality, covering various scenarios including KYC rejection, approval, and priority routing. The externalization of configuration values like rwa_ltv_ratio and the refactoring of _as_dict improve maintainability and clarity. The membrane's role as a backstop for KYC failures adds a crucial security layer. The comments highlight opportunities to improve type consistency and data flow between Python types and DSPy model expectations for kyc_status and ltv_ratio.
| kyc_status: str = dspy.InputField( | ||
| desc='KYC verification status as a plain string: "true" (verified) or "false" (not verified).' | ||
| ) |
There was a problem hiding this comment.
The kyc_status input field is described as a 'plain string: "true" (verified) or "false" (not verified)'. This implies that the DSPy model expects a string. However, in RWAParams and AuraRWANegotiator.forward, kyc_status is typed as bool. This leads to a bool to str conversion (str(kyc_status).lower()) before calling the DSPy model. For better type consistency and clarity, consider if RWAParams should also define kyc_status as a str if the DSPy model strictly requires it, or if the DSPy signature could be updated to accept a bool if the underlying model can handle it.
| ltv_ratio: str = dspy.InputField( | ||
| desc="Loan-to-value ratio as a plain float string (e.g. '0.60'). " | ||
| "collateral_value_usd = appraised_value_usd * ltv_ratio." |
There was a problem hiding this comment.
Similar to kyc_status, the ltv_ratio input field is described as a 'plain float string (e.g. '0.60')'. This indicates the DSPy model expects a string. However, ltv_ratio is typed as float in RWAParams and AuraRWANegotiator.forward, requiring a float to str conversion (str(ltv_ratio)) before calling the DSPy model. Aligning the type in RWAParams to str or exploring if the DSPy signature can accept float directly would improve type consistency.
…ndary
RWAParams and AuraRWANegotiator.forward() now use str for kyc_status
("true"/"false") and ltv_ratio (e.g. "0.60") to match the
AppraiseAndVerifyRWA DSPy InputField types directly. The implicit
bool->str and float->str conversions are removed; the transformer
produces the string forms in _build_rwa_context() before passing to
the registry, making the type contract explicit at the boundary.
Co-authored-by: Ona <no-reply@ona.com>
1 participant
Summary
Pivots the Hive's transformer to an "Institutional RWA-Backed Stablecoin Vault" cognitive mode. Before issuing any vault instruction, the Agent acts as a strict compliance officer: KYC/AML is verified first, the physical asset is appraised using SIX data partner rates from context, LTV-adjusted collateral value is calculated, and only then is a structured
RWAVaultIntentproduced for the SolanaTransactionSkill.Proto changes
Two new messages added to
metabolism.proto:RWAComplianceScore— KYC/AML result embedded in every vault intent:kyc_passed,aml_passed,compliance_status(APPROVED/REJECTED/PENDING)violation_code:KYC_MISSING,AML_SUSPICIOUS,ASSET_UNVERIFIED, or emptythink: LLM reasoning blockflags: human-readable compliance notesRWAVaultIntent— vault lock/mint instruction:appraised_value_usd(from vision report + SIX rates),ltv_ratio,collateral_value_usdwallet_address,stablecoin_currency(USDC), embeddedRWAComplianceScoreWired as
Intent.oneof.paramsfield 15 (rwa_vault).Core changes
transformer/signatures.py—AppraiseAndVerifyRWANew DSPy signature with 6 inputs (
vision_report,wallet_address,kyc_status,six_rates,ltv_ratio,system_vitals) and 6 outputs. The LLM docstring enforces three rejection gates in order:kyc_status == "false"→KYC_MISSINGcounterfeit,damaged,unverified,stolen,forged) →ASSET_UNVERIFIEDAML_SUSPICIOUSOnly if all three pass does the LLM compute
appraised_value_usdfrom vision + SIX rates and applyltv_ratio.reasoning/engine.py—AuraRWANegotiatorSingle-stage DSPy module (vs. the two-stage trade chain). Compliance and appraisal are tightly coupled — no point separating them into two predictors.
transformer/main.py_is_rwa_context(): detectsmetadata["rwa_mode"] == "true"_think_rwa(): full RWA path, buildsRWAComplianceScore+RWAVaultIntent, returnsACTION_TYPE_REJECTon any compliance failurethink()routing: RWA is checked before the trade path — both signals can coexist without conflict_as_dict()extracted to module level (was a local function inside_build_trade_context— would have caused aNameErrorin the new RWA context builder)membrane/main.pyRWA KYC backstop added before the existing trade guard. Any
RWAVaultIntentwithkyc_passed=Falseis forced toACTION_TYPE_REJECTregardless of transformer output.config/policy.pyrwa_ltv_ratio: float = 0.60added toSafetySettings. Configurable viaAURA_SAFETY__RWA_LTV_RATIO.transaction/skill.pymint_rwa_vaultstub added (returnssuccess=False, pending Solana vault program ABI) — consistent withsubmit_to_router.Tests
9 new tests in
core/tests/test_rwa_transformer.py:test_appraise_and_verify_rwa_signature_fieldstest_rwa_negotiator_kyc_rejectedkyc_status=False→KYC_MISSING, values0.0test_rwa_negotiator_approvedAPPROVED,collateral_value_usd > 0test_transformer_think_rwa_path_rejectedrwa_mode=true,kyc_status=false→REJECT,params="rwa_vault"test_transformer_think_rwa_path_approvedkyc_status=true→ACCEPTtest_transformer_rwa_takes_priority_over_traderwa_modeandasset_domainset → RWA path takentest_membrane_blocks_kyc_failurekyc_passed=False→ membrane forcesREJECTtest_membrane_passes_compliant_rwakyc_passed=True→ passes through unchangedtest_rwa_ltv_ratio_from_settingsrwa_ltv_ratio=0.50→ passed to reasoning proteinKnown limitations
collateral_value_usdatappraised * rwa_ltv_ratioin_think_rwa()would add a hard server-side check.metadata["six_rates"]by the upstream caller. Nothing enforces this at runtime.mint_rwa_vaultis a stub — real Solana SPL token minting requires the vault program ABI.Test results