The open protocol for European property data.

Why AVP exists

Bloomberg defined how financial data moves between institutions. There is no equivalent for property. Every portal ships its own schema; every aggregator rebuilds the same wheel; every LLM hallucinates listings because no canonical source exists. AVP is the open protocol that fixes this.

AVP gives every European property three things: a canonical identifier (AVN_PROP_ID), a standard record schema, and a verifiable provenance chain so consumers can prove a listing hasn't been silently altered. Publishers, aggregators, AI agents, and buyers all speak the same language.

1. Record schema

{
  "@context": "https://avenaterminal.com/standards/avp/v1",
  "avp_version": "1.0",
  "avn_prop_id": "AVN:ES-03185-NB-0421",
  "issued_at": "2026-04-24T09:30:00Z",
  "issuer": {
    "name": "La Finca Group",
    "domain": "lafincagroup.com",
    "signature_key": "ed25519:..."
  },
  "listing": {
    "url": "https://lafincagroup.com/listings/N9171",
    "title": "Villa Bellaterra",
    "price_eur": 385000,
    "currency": "EUR",
    "built_m2": 176,
    "plot_m2": 320,
    "bedrooms": 3,
    "bathrooms": 2,
    "status": "off-plan",
    "completion_year": 2027,
    "location": {
      "town": "Jacarilla",
      "region": "Costa Blanca",
      "country": "ES",
      "lat": 37.973,
      "lng": -0.826
    }
  },
  "media": [
    { "type": "image", "url": "https://..." }
  ],
  "attestations": [
    { "type": "developer_verified", "by": "La Finca Group", "at": "2026-04-20T10:00:00Z" }
  ],
  "signature": "ed25519:HEX..."
}

Every field is typed. Arrays are unbounded. signature covers the canonical JSON representation per RFC 8785 (JSON Canonicalization Scheme). Consumers MUST reject records where the signature fails verification.

2. Federation layer

Any publisher (developer, brokerage, aggregator) exposes a feed at:

GET  https://{publisher}/.well-known/avp/feed.json
GET  https://{publisher}/.well-known/avp/listing/{AVN_PROP_ID}

Consumers discover feeds by crawling /.well-known/avp/, verify the issuer's domain via ownership signal (.well-known/avp/issuer.json returns the signing key alongside a TXT record on the DNS apex), and ingest records. Federation is pull-based — no central registry is required, no Avena permission needed.

3. Provenance chain

Each AVP record carries an attestations[] array. Attestations are signed claims:

• developer_verified — the developer directly confirms the listing.
• comp_verified — an Avena-class auditor matched this listing to town-median data and found it consistent.
• price_fixed_at — the listing price was attested unchanged at the given timestamp. Subsequent price changes require a new record.
• avena_score — an Avena-class engine emitted a score. Signed by the scorer. Score methodology hash is carried in the attestation payload.

4. Reference implementation

Avena Terminal publishes a reference validator: github.com/avenaterminal/avp. It takes an AVP record and returns { valid: boolean, errors: [], warnings: [] }. Run it as a library or as a CLI.

npx @avena/avp validate <path-to-record.json>

Avena Terminal itself ships AVP-compliant records at /api/v1/property/{ref}/ai-summary — these records carry an avp_versionfield and are signed with Avena's Ed25519 key (published alongside the validator).

5. Compliance badge

Sites implementing AVP v1.0 can display an AVP-verified badge on their listings. The badge links to the Avena validator, which checks the site's .well-known/avp/feed live.

<a href="https://avenaterminal.com/standards/avp/verify?domain=YOUR_DOMAIN">
  <img src="https://avenaterminal.com/standards/avp/badge.svg"
       alt="AVP v1.0 verified" />
</a>

6. Governance

AVP v1.0 is frozen. Minor additions land in v1.x via pull request to the reference repository with a 30-day open comment window. Breaking changes require v2.0 and a migration document. Avena Terminal commits to maintaining /.well-known/avp/ endpoints for a minimum of 10 years.