You seem to be confusing between transaction and token-transfer, so I'll give you a short introduction of the technical terms that you need to understand IMO.
Transactions
There are 4 basic types of transactions:
- Transferring ether to an account
- Transferring ether to a contract
- Deploying a contract
- Executing a function of a contract
#2 is essentially a special case of #4:
It triggers a designated function of the contract, aka fallback or receive.
In #4, it's a state-changing function of course, otherwise mining is not required.
We can also program our transaction to transfer ether to the contract right before the execution of the function.
Ether
Ether is the basic payment unit on the Ethereum blockchain.
Using the private key of a given public address, we can transfer ether from this address to any other Ethereum address, even if no account or contract with that address has been created.
The only exception to this is that if a contract does exist on the destination address, then it must implement a designated function to receive the funds, otherwise the transfer will revert.
Tokens
Using the basic payment unit (ether) along with contract-programming, we can implement other types of payment units.
These payment units are commonly known as Tokens.
As with ether, we’d like to be able to transfer tokens from one address to another.
But in contrast with ether, this functionality is not "embedded into the system".
We need to deploy a contract which implements token-transferring infrastructure.
A good analogy for this:
- Ether-transferring is already supported at the hardware-level
- Token-transferring should be supported at the software-level
Ether-Transfer
Recall that 2 (out of 4) types of transactions are:
- Transferring ether to an account
- Transferring ether to a contract
For these, all we need is:
- The private key of our account
- The public address of the destination (account or contract)
Token-Transfer
Recall that in contrast with ether, token-transferring infrastructure is not "embedded in the system"; we need to deploy a contract which implements it.
The typical implementation is a simple table which maps for every address, the number of tokens owned by that address.
So in essence, when we say that account X has Y tokens, it means that in our token-contract, there is a table which maps address X to amount Y.
Conclusion
With this introduction fully understood, we can go back to your transaction, which according to your description is a token-transfer transaction, and analyze its receipt:
from: '0xa7a82DD06901F29aB14AF63faF3358AD101724A8'
This is the address of the account used for sending the transaction.
input: '0xa9059cbb0000000000000000000000005e6b735c855cf7f44f179c25c98195ace9eb972b0000000000000000000000000000000000000000000000056bc75e2d63100000'
This is the concatenation of the input parameters passed to the token-transfer function in the LINK token contract.
to: '0x01BE23585060835E02B77ef475b0Cc51aA1e0709'
This is the address of the LINK token contract.
value: '0'
This is the amount of ether passed to the token-transfer function in the LINK token contract.
Note that I slightly cheated on the "contract/account" terminology.
In fact, both are considered Ethereum accounts, where:
- A smart-contract account is created when you deploy a smart contract to the network, and its private key remains unknown
- An externally-owned account is created directly by choosing a private key and hashing it, so its private key is known to the creator
to
andvalue
respectively!value
field indicates the amount of ether passed in the transaction, not the amount of some token (a transaction doesn't even have to be a token-transfer).to
fields indicates the smart-contract account (in the case of a function call) OR the externally-owned account (in the case of a pure ether-transfer) that the transaction was sent to. Not some token-transfer destination address (as I said on the previous comment, the transaction doesn't even have to be a token-transfer).