Skip to content

Releases: trisacrypto/trisa

v1.7.0

15 Jul 20:47
dbfd1ae

Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v1.6.1...v1.7.0

v1.6.1

28 Mar 16:30
e7120d4

Choose a tag to compare

What's Changed

Full Changelog: v1.6.0...v1.6.1

v1.6.0

08 Feb 23:51
d38e672

Choose a tag to compare

What's Changed

Full Changelog: v1.5.0...v1.6.0

v1.5.0

25 Jan 21:23
9c49294

Choose a tag to compare

What's Changed

Full Changelog: v1.4.1...v1.5.0

v1.4.1

09 Sep 12:05
f6924ea

Choose a tag to compare

Hotfix: fix JSON unmarshal for null values.

What's Changed

Full Changelog: v1.4.0...v1.4.1

v1.4.0

05 Sep 03:54
60aeda1

Choose a tag to compare

What's Changed

Full Changelog: v1.3.0...v1.4.0

v1.3.0

22 Jul 21:08
a5a9836

Choose a tag to compare

What's Changed

Full Changelog: v1.2.0...v1.3.0

v1.2.0

22 Jul 19:18
9cacc9b

Choose a tag to compare

What's Changed

New Contributors

  • @kshyun28 made their first contribution in #165

Full Changelog: v1.1.1...v1.2.0

v1.1.1

10 Jun 20:43
c9dfcda

Choose a tag to compare

What's Changed

  • Updates TRISA documentation with state workflows by @bbengfort in #164
  • Allows .local domains to be used in Travel Addresses

Full Changelog: v1.1.0...v1.1.1

v1.1.0

25 May 19:45
2899974

Choose a tag to compare

This release is intended to make things simpler for developers to implement Travel Rule compliance solutions on top of TRISA. Many of these tools will be used in the Envoy project. The big updates include:

Transaction States - you can now add a workflow state to a SecureEnvelope to indicate to the counterparty what state the envelope is in. E.g. is the transaction started, pending, accepted, in need of repair, rejected, or completed? These states hint at the expected response from the counterparty and make it easier to identify what is going on when messages are mirrored or echoed.

Address Confirmation - an alpha version of address confirmation has been added (just the protocol buffer definitions). It includes three trial methods: simple, key/token, and on-chain. In the simple method, the counterparty simply reports if they have control or not. In key/token a token is encrypted with the public key of the crypto address and the counterparty must return the decrypted token using the private key. In on-chain, the counterparty must post a transaction to a supplied beneficiary address with a very small amount that serves as a nonce value; once the originating party sees the transaction on the chain they know that the counterparty has control of the address. This protocol definition does not service as an official position from TRISA about how to conduct address proof-of-control (as it has been removed from the white paper) but provides an opportunity for counterparty peers to conduct such confirmation in an automated way.

Other changes include easier rejection envelopes, HMAC validation, and better documentation.

What's Changed

Full Changelog: v1.0.0...v1.1.0