Pablo, thanks for the response. A note up front: what follows are my working positions on the open questions you raised, still subject to co-author review before anything lands in a v2 PR. Sharing early to get community feedback on the direction.
1. RoleCollusion as a distinct CoverageType
Your framing nails it: EvaluatorDispute presupposes a dispute was raised, RoleCollusion is the case where no dispute exists because the collusion succeeded cleanly. Same recovery mechanism, semantically distinct triggers. This framing will shape how we approach the v2 discussion on whether to separate them.
2. The evidence object deserves to be promoted to the interface layer
Your point about RNWY’s evidence object carrying signals that a Resolver can threshold on its own made me realize this pattern should be formalized at the interface layer rather than bound to any specific schema. Any trust layer implementing the same interface shape would then be drop-in compatible with any AAP Resolver that consumes independence evidence.
From first principles, independence assessment needs roughly these signal categories:
- Funding origin overlap: do the addresses share a funding source (direct match, or cluster membership under a common funder)
- Temporal proximity: how close are they on the timeline (creation time, first interaction, activity rhythm)
- Relationship density: direct or indirect on-chain interaction strength (tx count, graph distance, shared contract usage)
- Ownership signals: other evidence of same-entity control (funder-to-owner match, shared metadata, declared ownership)
And one open category worth discussing:
- Behavioral similarity: independently of the above, do the addresses exhibit similar fingerprints (gas price preferences, tx timing distribution, contract interaction patterns)? This catches same-operator cases that slip past the first four.
Your RNWY evidence object concretely covers 1, 2 (via wallet age at review), and 4, and extends 1 with cluster size. Three of the four core categories already landed in production is a large part of why this abstraction feels implementable rather than theoretical. Categories 3 and 5 remain open design space.
Draft interface (open for community discussion):
solidity
interface IIndependenceSignal {
function assessIndependence(
address addrA,
address addrB
) external view returns (
bool independent,
uint8 confidence,
bytes memory evidence
);
}
Three design requirements the rationale needs to spell out:
Partial signals must be legal. Not every trust layer provides all four categories. The evidence payload must let implementations populate only what they can, with explicit markers for what’s available vs missing. confidence reflects certainty given available data, not data completeness.
No data at all must also be legal. A new trust layer on a new chain will encounter addresses it knows nothing about. Forcing it to fake data or revert would push implementations toward dishonesty. The cleanest expression of “I was asked but I have nothing to say” is to allow empty evidence under a strict two-way convention: empty evidence requires confidence == 0, and non-empty evidence requires confidence > 0. Either violation is an invalid state. Resolvers get a single clean check (confidence == 0 means no usable signal) without parsing the payload. This maps directly to your “Transparency, Not Judgment” principle: having nothing to say is itself a transparent answer.
The independent field is undefined when confidence == 0. My earlier instinct was to pin a fail-closed default (return false), but that conflates “no data” with “judgment that they’re linked”, which is in tension with the Transparency principle. Cleaner to state that consumers MUST NOT rely on independent when confidence is zero. Implementations can return any value, consumers are expected to branch on confidence == 0 first. Open to pushback on this.
One deliberate design choice worth flagging: the draft above defines assessIndependence as a view function, which assumes the trust layer has an on-chain oracle. This matches the deployment shape of some scoring layers but excludes pure off-chain ones (REST API only, no on-chain contract). An alternative would be a signed-attestation pattern where the Resolver submits a signed claim from an off-chain source as part of fileClaim evidence. Both have real use cases. I don’t have a strong opinion yet on whether IIndependenceSignal should pick one or support both. Would be good to hear from anyone building off-chain scoring layers in this thread before the shape gets fixed.
On RNWY’s positioning in v2: the spec text stays protocol-neutral per ERC conventions, but RNWY will be explicitly credited in two places:
- Spec Acknowledgments, crediting the evidence-shipping design direction as informed by RNWY’s multidimensional scoring methodology
- AAP reference implementation repo (planned Integration Examples doc), showing how to consume RNWY’s trust oracle through the IIndependenceSignal interface (oracle address, methodology link, integration code)
Push back in this thread on anything: the interface shape, the signal categories, partial availability, the empty-evidence convention, the view-vs-attestation question. Much easier to adjust now than after v2 PR goes up.
3. Nullification vs penalization
The principle lines up with AAP’s own ethos: parties without fault shouldn’t bear system failure costs. Different layer, same philosophy.
To stay stable across your methodology changes, the reference implementation’s Integration Examples will reference your methodology document by version, not by specific score values.
Thanks for this level of collaboration.
Jacky
