The authors of the Open Digital Asset Protocol posted revision 01 as an Internet-Draft on November 1, 2020, turning an early interoperability proposal into a much more detailed gateway blueprint for moving digital assets between unlike distributed ledgers.
The IETF Datatracker records Thomas Hardjono’s upload, system approval and publication of the new revision on November 1. The document was authored by Martin Hargreaves of Quant Network and Hardjono of MIT. Its central idea was not a new blockchain or token. It was a common protocol through which a sender gateway and a recipient gateway could coordinate a one-way asset transfer across systems that did not share the same ledger technology.
That was a meaningful protocol-development record for November 1, but it came with an important boundary: an Internet-Draft can be submitted by anyone, is explicitly a work in progress and is not endorsed by the IETF. Revision 01 documented a proposal; it did not establish an adopted internet standard, a deployed network or a completed production implementation.
From a common interface to a transfer model
Revision 00, dated October 10, 2020 in its document header, concentrated on common addressing, client identification, security negotiation, discovery and access to resources behind DLT gateways. Revision 01 retained those elements while defining ODAP more specifically as a gateway-to-gateway asset-transfer protocol. The revised document expanded from 11 numbered pages to 22, a page-count comparison that indicates added specification detail but says nothing by itself about code quality or adoption.
The November 1 model separated three interfaces. A Type-1 API connected an application to its local gateway. Type-2 linked peer gateways conducting a transfer. Type-3 let a gateway consult resources outside the ledgers, such as evidence needed to validate a transaction. It also described direct modes, in which an application contacted one or more gateways, and a relay mode, in which a local gateway communicated with a remote one.
The draft organized a transfer around three flows: initiation, validation of evidence that an asset had been locked or placed in escrow, and commitment between the two gateways. Message fields included identities for the sender and recipient gateways, public keys for the originator and beneficiary, identifiers for the source and destination DLTs, an asset-profile hash and a transfer quantity. Certain messages were to be signed so they could serve as evidence beyond the protected communications channel.
The security problem moved to the gateways
ODAP’s architecture sought interoperability without requiring every ledger to adopt the same internal design. That abstraction also concentrated responsibility at gateway boundaries. The draft required TLS 1.2 or higher and recommended TLS 1.3 where supported. It described negotiated credential schemes, sequence numbers and signed transfer messages, while warning that gateways would be attractive targets because they could initiate transfers out of one system and into another.
The design did not eliminate trust. Gateways asserted conditions about assets and ledger state, applications still had to judge responses in context, and revision 01 left important sections incomplete. Asset-profile negotiation and the commitment-establishment phase were marked “TBD,” as was the IANA section. The draft therefore established vocabulary, roles and a message-flow direction—not a complete recipe proving atomic settlement across arbitrary chains.
Why the November 1 record mattered
Blockchain interoperability in 2020 was often presented through project-specific bridges or connector networks. ODAP revision 01 framed the problem as a protocol between gateways, with identifiers, evidence and audit-oriented messages independent of any single DLT. That approach was especially relevant to institutions operating permissioned networks or legacy systems alongside blockchains.
The verified event-day conclusion is narrow: a substantially expanded, precisely dated technical proposal entered the IETF Internet-Draft archive on November 1, 2020. No event-day evidence establishes deployment, interoperability between named production networks, transaction volume or regulatory acceptance.
Later context
On September 29, 2021, the Hyperledger Foundation described a completed mentorship project that implemented ODAP as a Hyperledger Cactus business plugin for cross-chain transactions. That later implementation supports the proposal’s continuing technical relevance, but it does not retroactively turn the November 1, 2020 draft into a standard or a working production service.
The complete source packet and revision history are retained with the newsroom record.
Automated systems may have assisted with source organization and drafting. Coinburn is accountable for the published text and maintains a revision record.
This article provides news and analysis, not investment, legal or tax advice. Digital assets are volatile and may result in total loss.