For a growing number of investigations, there is a need to represent cryptowallets and the account(s) they contain.
Crypto wallets can be hosted by an online service, or stored in a software wallet application, or secured using a hardware wallet.
Requirements
Requirement 1: CASE must be able to represent what cryptoaddress(es) were stored in a given cryptowallet.
Requirement 2: CASE must be able to represent how much cryptocurrency was stored in a given cryptoaddress at a point in time.
Requirement 3: CASE must be able to represent multiple measurements of the balance of a crypto wallet.
Benefits
Representing cryptowallets and cryptoaddresses is necessary for various cyber-investigations, including Dark Web activities and cryptocurrency transactions.
(Noted during administrative review) QUDT employs owl:versionIRI, giving CDO a chance to try versionIRI practices under consideration for CASE's and UCO's versioning.
Risks
(Noted during administrative review) Some proposals under draft are considering importing ontologies outside of the UCO/CASE ontologies. None have been accepted yet. This proposals includes incorporating QUDT. (It remains to be reviewed whether this would be adoption of certain provided classes, or importing QUDT.)
(Noted during administrative review) One logistical risk pertaining to usage of QUDT is that its ontology resources only transmit from their namespace IRIs via plaintext HTTP. TLS fails with a 404 message. Transmission risks can be mitigated by CASE tracking the QUDT public Github repository as a Git submodule.
(Noted during administrative review) Usage of QUDT for unitary measurements introduces a design a pattern to CASE that is not used elsewhere in UCO-housed concepts. One concept where unitary measurement could be applied is the UCO property observable:storageCapacityInBytes - that property could reduce its name to storageCapacity and use the unit:BYTE unit of measure. In short, adoption of this proposal induces a need in CASE to explain why some numeric properties are represented with qudt:unit and others aren't.
Competencies demonstrated
Competency 1
The cryptoaddress(es) that were stored in a given cryptowallet, and how much cryptocurrency they had.
Admin. note - For this proposal, the competencies should include a sample JSON-LD snippet and two SPARQL queries demonstrating satisfaction of the above competency statement, i.e. SELECT ?nCryptoWallet ?xCryptoAddress and SELECT ?nCryptoWallet ?xQuantity, with the latter demonstrating something similar to usage of http://qudt.org/vocab/unit/AUD. (?x prefix is where the admin. review was unclear on what value(s) or value form(s), node or literal, should be returned.)
Solution summary
1) Add CryptoWalletFacet with the following properties:
cryptoWalletIdentifier (string): the identifier of a wallet
cryptoWalletName (string): the name assigned to a wallet
cryptoWalletCreatedTime (date): when the wallet was created
cryptoWalletSeed (string): a series of words for accessing crypto associated with the wallet.
2) Add CryptoAddressFacet with the following properties, using qudt.org ontology to represent currency:
cryptoAddress (string): reference to CryptocurrencyAddress containing the value of the cryptocurrency address
cryptoCurrencyType (string): the type of cryptocurrency in the wallet
cryptoAddressFormat (string): P2SH (BASE58)
cryptoAddressName (string): the name assigned to the cryptocurrency address
cryptoAddressCreatedTime (date): when the cryptocurrency address was created
cryptoAddressBalance (currency - qudt): the total amount of cryptocurrency in the cryptocurrency address
cryptoAddressCompletedTransactionCount (integer): how many transactions have been completed using the cryptocurrency address
cryptoAddressTotalSent (currency - qudt): the total amount of cryptocurrency sent by the cryptocurrency address
cryptoAddressTotalReceived (currency - qudt): the total amount of cryptocurrency received by the cryptocurrency address
cryptoAddressPendingTransactionCount (integer: how many transactions are pending for the cryptocurrency address
Background
For a growing number of investigations, there is a need to represent cryptowallets and the account(s) they contain.
Crypto wallets can be hosted by an online service, or stored in a software wallet application, or secured using a hardware wallet.
Requirements
Requirement 1: CASE must be able to represent what cryptoaddress(es) were stored in a given cryptowallet.
Requirement 2: CASE must be able to represent how much cryptocurrency was stored in a given cryptoaddress at a point in time.
Requirement 3: CASE must be able to represent multiple measurements of the balance of a crypto wallet.
Benefits
owl:versionIRI, giving CDO a chance to tryversionIRIpractices under consideration for CASE's and UCO's versioning.Risks
observable:storageCapacityInBytes- that property could reduce its name tostorageCapacityand use theunit:BYTEunit of measure. In short, adoption of this proposal induces a need in CASE to explain why some numeric properties are represented withqudt:unitand others aren't.Competencies demonstrated
Competency 1
The cryptoaddress(es) that were stored in a given cryptowallet, and how much cryptocurrency they had.
Admin. note - For this proposal, the competencies should include a sample JSON-LD snippet and two SPARQL queries demonstrating satisfaction of the above competency statement, i.e.
SELECT ?nCryptoWallet ?xCryptoAddressandSELECT ?nCryptoWallet ?xQuantity, with the latter demonstrating something similar to usage ofhttp://qudt.org/vocab/unit/AUD. (?xprefix is where the admin. review was unclear on what value(s) or value form(s), node or literal, should be returned.)Solution summary
1) Add CryptoWalletFacet with the following properties:
cryptoWalletIdentifier (string): the identifier of a wallet cryptoWalletName (string): the name assigned to a wallet cryptoWalletCreatedTime (date): when the wallet was created cryptoWalletSeed (string): a series of words for accessing crypto associated with the wallet.
2) Add CryptoAddressFacet with the following properties, using qudt.org ontology to represent currency:
cryptoAddress (string): reference to CryptocurrencyAddress containing the value of the cryptocurrency address cryptoCurrencyType (string): the type of cryptocurrency in the wallet cryptoAddressFormat (string): P2SH (BASE58) cryptoAddressName (string): the name assigned to the cryptocurrency address cryptoAddressCreatedTime (date): when the cryptocurrency address was created cryptoAddressBalance (currency - qudt): the total amount of cryptocurrency in the cryptocurrency address cryptoAddressCompletedTransactionCount (integer): how many transactions have been completed using the cryptocurrency address cryptoAddressTotalSent (currency - qudt): the total amount of cryptocurrency sent by the cryptocurrency address cryptoAddressTotalReceived (currency - qudt): the total amount of cryptocurrency received by the cryptocurrency address cryptoAddressPendingTransactionCount (integer: how many transactions are pending for the cryptocurrency address
3) Add CryptocurrencyAddress observableObject (subClassOf observable:DigitalAddress)
4) Create example using public data: Wallet Explorer (https://www.walletexplorer.com/wallet/335f3892f622984f
5) Add unit test showing potential errors in property usage and how to avoid them
Coordination